[time-nuts] Designing an embedded precision GPS time

Leo Bodnar leo at leobodnar.com
Tue Oct 31 21:03:05 UTC 2017

> From: Attila Kinali <attila at kinali.ch>
> True. An NTP server does not need to measure time better than 100ns or so.
> 10ns is probably more than good enough. But then, this raises the question
> what your performance metric is that you optimize for?

The goal was maximum throughput with minimum time offset.
Maximum throughput eventually ended up as "fully saturated full-duplex 100BASE-TX" and minimum time offset as "below 1 microsecond"
There was nothing on the market below £2-3k that could do that.  I think Microsemi has recently made a server that can do 100kpps+ but I don't know its price.

> If it is hold-over, then this will be limited by the TCXO and how well
> you can measure its frequency, which in turn depends on how well you
> can measure the PPS pulse. You say that your device is typically within
> 4-5ms in 24h of hold-over. That translates to frequency uncertainty
> of approximately 5e-8. That's not that good.
> To put this into perspective have a look at the two attached plots.
> These are the PPM values that ntp reports for a standard server (HP DL380G7).
> The first plot shows the long term variation of all the data I currently have.
> The three jumps coincide with days when we restarted ntpd. As you can see,
> the long term variation of the crystal frequency is well below 0.5ppm. The
> second plot zooms in into one of the day with large variations. The worst
> of these being about 10ppb. Lets assume for simplicity, the 10ppb step happens
> instantaneous, then this would result in a hold over performance of ~0.9ms
> in 24h. Yes, this is not a fair comparison. The sever is in a room where
> temperature is pretty much constant (sorry, I don't have any data on that,
> but assume less than 5°C  variation within a day). And it's not true hold
> over performance, but a guestimation from the ntp provided loop data. But
> even if we add a factor of 10, this simple, unstabilized, unsophisticated
> PC comes pretty close to the performance your device claims. And that's not
> even a PC with a good crystal (I have measurements of others, that showed
> variation of less  than 2ppb over months in rooms without air conditioning).
> Or to put it differently: If i'd get a Minnow Turbot, add a GPS receiver,
> put everything in a metal box and just use normal ntpd, i'd expect to
> have a hold over performance of better than 100ms/24h (assuming 1ppm
> stability of the crystal), probably in the order of 10ms/24h and it would
> have no problems handling a humongous number of clients, thanks to the
> fast CPU (1.4GHz) and the Gbit/s ethernet interface.
> So, why does a simple PC with ntp do such a good job? The secret
> lies in the measurement: Very much simplified, ntp measures the
> frequency in 1000s intervals. Measurement uncertainty is reported to be
> better than 100us per reference server. Ie the uncertainty is in
> better than 1e-7 (compare with the estimated 5e-8 from above).
> Add to that averaging over multiple reference severs (4 in this case)
> and a sophisticated clock parameter estimation and the uncertainty
> goes down quite a bit.
> To summarize: If you want to improve your ntp devices hold over performance
> you have to improve the frequency measurement and use a better clock modeling.
> Ie, use a timing GPS receiver and its sawtooth correction, and model the
> clocks frequency change over time.

I do want to improve my NTP devices but I do not understand what you are suggesting.
Why would sawtooth correction matter when there is no GPS signal available at all?
I am not measuring any frequencies - the whole device runs synchronously hard-locked to GPS time when it is available and freewheeling when not.
This is reference stratum 1 clock, it does connect to any servers, it only serves clients.
If you chop off its antenna and disconnect local LAN segment from the internet and other NTP servers, local network time will drift off by 4-5ms in 24 hours and then the server will fall back to stratum 16 and will tell clients that it cannot provide accurate time anymore.

>  But even if we add a factor of 10, this simple, unstabilized, unsophisticated PC comes pretty close to the performance your device claims. 

Are you saying that if you deprive any PC of any connectivity it will drift by 4-5ms in 24 hours?


More information about the Time-nuts_lists.febo.com mailing list