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

[Hal Murray]

> >> 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.

ntp tries to keep the local machine in sync with UTC.  The model is that the 
world is a forest of trees.  Each tree starts with a local source of time 
that claims to be UTC.  ntp calls them refclocks.  Each tree is a collection 
of servers.  The refclocks are stratum 0.  The root of each tree is stratum 
1.  The next layer of servers is stratum 2...

A lot of the code in ntp is figuring out which trees to believe and then 
selecting the best one to sync to.

ntpd is both a client and server.  It's a server distributing time to clients 
at a higher stratum and a client getting time from servers at a lower stratum.


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

ntp runs in two modes.  Normally, it gets the time over the net.  Ballpark 
accuracies are 1 ms if you have a good local system to talk to and a lightly 
loaded network and 10s to 100 ms if you go out over the big bad internet.

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.


For network traffic, ntp assumes the delays are symmetric.  You can confuse 
it with something like a big download over a DSL link.  Delays are not a 
problem.  It's jitter and asymmetry.  After a packet exchange, you end up 
with 4 time stamps.
  When the request left the client.
  When it arrived at the server.
  When the response left the server.
  When it arrived back at the client.
(The packet can sit on the server for a while, say if it is busy doing other 
things.)

If you subtract off the time the packet sat on the server you have the round 
trip time.  If you assume symmetry you can get the offset.


> ---> 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.



> 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?  You can get better data by sending 
several packets and picking the best one.  In this context that probably 
means the one with the lowest round-trip-time.  Lowest time means lowest 
queuing delays.  That assumes no-queuing would be symmetric.

ntp is trying to minimize network load.  You may do better by sending more 
packets.  (there is a maxpoll and a burst mode in the config file)

If I was working on something like that, I would setup a testbed and collect 
some data.

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?)

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?


> 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.

The ntp problem is the same as a GPSDO: you get good long term stability.  
Short to medium is where things get interesting.




-- 
These are my opinions, not necessarily my employer's.  I hate spam.