[time-nuts] looking for good description/generalized model for time adjustments

Lux, James P (337C) james.p.lux at jpl.nasa.gov
Wed Jul 29 22:31:39 UTC 2009



-----Original Message-----
From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On Behalf Of Hal Murray
Sent: Wednesday, July 29, 2009 2:51 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] looking for good description/generalized model for time adjustments


> >> Precisely so. And NTP may actually be the best model here. Does
> NTP's "corrected output" meet the "must be monotonic and not
> discontinuous" criteria (being too lazy to just go read the NTP docs,
> which I have, and which I'll take a look at after lunch). 

There is a lot of info available about ntp, you may have troubles finding 
what you want, especially if you don't already know what you are looking for.

I'm being sloppy when I say "ntp".  It's both a protocol spec (RFC-whatever) 
and a reference implementation (ntpd) that is widely deployed.

>>>><snip about ntp>


What OS are you using?  FreeBSD is very good.  Linux is not--so-good.


>>> RTEMS and/or VxWorks (I'm using RTEMS, others with whom we communicate use a variety of other things. And we don't have network connections per se.. That's why I'm looking for more generic descriptions that aren't tied to things like packet definitions or peculiarities of IP routing.   Basically, all of these things should be able to be boiled down to two things: a synchronization signal and a synchronization message. 

The other mode is using a refclock.  ntpd includes support of over 20 
different types of clocks, many are no longer interesting.  The key to 
getting good time is something like a PPS pulse and kernel support to grab a 
timestamp in the interrupt routing.  There is also a batch of PLL code in the 
kernel that I don't understand.

>>>> and it is that PLL code that is particularly interesting (Poul-Henning has useful information in kern/time_tc.c, etc.)


For network traffic, ntp assumes the delays are symmetric.  <snip>


>>> In my application, we don't need to "probe the network" to figure out the latencies. We know them apriori, and they are also "very small" compared to the required time precision.  The part I'm interested in is the automated reconciliation of the always varying clocks/oscillators on the platforms, essentially trying to predict a bad clock with a good one.

> ---> But it *is* the master, by fiat.   Here's a scenario: A schedule
> is published that says: (MT = Master's time)
> At 12:00.001MT Box A puts out a pulse
> At 12:00.002MT Box B puts out a pulse
> At 12:01.001MT Box A puts out a pulse.

> Box A and Box B MUST follow Master Time, no matter how crummy it is.  

ntp is trying for UTC, the one great time.  But that comes from outside ntp.  
You can simplify things a lot if you tell it (config file) to only use one 
server.

For example, you could setup box A as the master and tell B to sync to it.

It may be better to setup another box in a stable environment and sync both A 
and B to it.  That gives B a stable target.

-->  Can't do that in this environment. The master is the master, and all the slaves are fore-ordained and must follow it as best they can.  What I need to do, really, is figure out what "best they can" is.





> A Single board computer with non TCXO clock (on order of 10ppm
> variability over short term) is the "system controller" and sets the
> time schedules.  It sends commands to devices which have TCXO clocks
> (on order of 1ppm short term variability) saying "at time X do action
> Y".  It also periodically sends messages to the devices saying "At the
> tone, my time is Z".

How good is your netework connection? 

>>>> Negligible latency (at least in the context of the required time precision). In reality, it has a worst case jitter of about 1 microsecond and a mean latency of 0.5 microsecond (that is, a "tick" on one end of the link appears at the other end of the link with a uniformly distributed delay of 0-1 microsecond) 

>>>> Think of it as if I had a piece of wire connecting the boxes, to do with whatever I want.  And then, on the side, I have a way to transmit messages among boxes (which has greater latency and jitter)



10 ppm short term variability seems huge.  The crystals I've looked at (in 
PCs) are ballpark of 1 ppm per C.  Do you have wide temperature changes short 
term or nasty crystals?  (or am I lucky?)

>>> wide temperature ranges: The environment where you go from full sunlight (at 1.3kW/square meter) to full darkness, radiating to 3K blackbody (about -400W/sq meter), and back to sun every 90-100 minutes).  A cyclical variation of 10-20 degrees wouldn't be unusual, and it's not sinusoidal.. more like a low pass filtered square wave.




It sounds a little backwards to have the machine with the lousy clock be the 
one in charge.  Can it get the time from any of the devices with better 
clocks?

>> sadly, no.. that's one of the problems to solve. 


> What we would like is a) some algorithms to do this (and NTP type PLLs
> are a decent way) and b) some formalism and rigor to choose operating
> parameters (e.g. update every 1 second or every day or whatever) 

There is a lot of formalism with ntp.  I'm not familiar with most of it.

Picking parameters is a black art.

>>> precisely so.. Lots of papers and presentations by Mills (and heck, he's been out here to JPL, too), but there's a lot of empiricism in those filter tuning parameters, I suspect.

>>> Turns out that there are lots of applications in spaceflight where you need to synchronize things that have different clocks (with relativistic effects, as well as just long and varying propagation delay). For instance, NTP, by itself, doesn't do a very good job synchronizing a clock on something orbiting the moon.  That's because the propagation delay properties are very different from what NTP was originally designed for (network traffic through a bunch of routers). You have a large, but systematic and predictable, range and range rate variation on top of a 1 second delay.



More information about the time-nuts mailing list