-----Original Message----- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@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. _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
