[time-nuts] Low-long-term-drift clock for board level integration?

Hal Murray hmurray at megapathdsl.net
Mon Feb 20 05:26:30 UTC 2012


> From that point forward (and we hope the devices will have an operational
> life of at least ten years) they'll be dependent on their internal clock and
> NTP, but we really need them to stay synchronized to within 100
> microseconds. 10 microseconds would be ideal, but 100 would be acceptable.
> And in order to be useful, they need to stay synchronized at that level of
> precision essentially forever.  

It's going to be "interesting".  I suggest you start experimenting.


How good a crystal do you need if you run without NTP?

Note that you don't need accuracy, just stability.  Software can correct for 
a frequency that is slightly off.  NTP calls it drift.

Let's play with some numbers.

Let's talk about 3 years.  That's 94608000 seconds, or 1E8, a handy round 
number.

So if your clock is off by 1 part in 1E8, it will drift 1 second in 3 years.  
You need 100 microseconds, or 1E-4, so you need a clock good for 1E-12.

Here is a typical high end OCXO.  (It may blow your budget, but we can use it 
as an example.)
  http://www.mti-milliren.com/ocxo_270_ocxo.html
  The typical 5 MHz aging performance is 5E-10
  per day and 5E-08 per year.

That's not in the right ballpark.


So, can you do it in software?

After the typical NTP packet exchange, you have 4 time stamps.  The (local) 
time the request left the client, the time it arrived at the server, the time 
the response left the server, and the time it got back to the client.

You have 3 unknowns: transit time out, transit time back, and clock offset.  
>From the timestamps, you get two equations: the transit times fudged by the 
clock offset.

NTP assumes that the network is symmetric.  That's the 3rd equation that lets 
it compute the clock offset which it uses to correct the local clock.  If you 
assume the local clock is accurate, you can compute the network delays.  
There is a chicken-egg problem.  You can't do both at the same time.

If you have a lot of NTP data and everything goes right, you get a picture 
like the one here:
  http://www.eecis.udel.edu/~mills/ntp/html/huffpuff.html

You need to know how sharp the point on the left is.  That depends on the 
network path between your box and the NTP servers you are using.  The traffic 
pattern on the last hop (from your site to your ISP) is likely to be the 
nasty part.

In my experience, getting to 100 microseconds is going to be hard.  I 
wouldn't call it impossible, but it sure won't be easy.

Suppose you can find good NTP servers with a stable network path.  If you 
collect a bunch of data the packets with the minimum total network delay will 
be the ones that didn't encounter any queuing delays in the network.  If you 
cross your fingers and assume the network path is symmetric, you now have a 
good measure of the clock offset.  If you remember that transit time and only 
use packets with similar transit times, you should be able to get good 
results.  There are a lot of loose ends in there.

The reference version of ntpd used by most Unix like OSes is setup to run on 
typical PCs and servers.  Their crystals are actually a pretty good 
thermometers.  :)
  http://www.ijs.si/time/temp-compensation/

If you have a good crystal (good, not great) it should be possible to ride 
over busy periods when you don't get any packets with short delays.


> That would be nice, of course, and we'll get the best GPS antenna we can
> afford and fit, but we can't have an externally-cabled antenna, or require
> that people put these on windowsills, or anything like that…  There will be
> too many of them, and the level of clue of the people plugging them in out
> in the field is likely to be too low. 

How are you going to find good NTP servers for all your boxes?

Are you targeting homes, offices, or machine rooms?
  GPS works inside my house.  (Not great, but good enough.)

Are you trying to measure arrival times of packets you control, or get 
accurate times from tcpdump/wireshark on arbitrary traffic?

Can you post-process the data?  I'm thinking of something like get a 
reasonably good crystal and let your system run off that crystal without 
trying to get time from the network.  The idea is to keep NTP from doing 
something stupid.  You can poke it occasionally from a central server to 
track the long term drift.  Or setup nearby servers in noselect mode, turn on 
logging, and get the info out of the log files.




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






More information about the time-nuts mailing list