At the moment, my plan is to not support hold-over at all. If GPS doesn’t have a fix and I’m not getting PPS pulses, I intend to either jump immediately to stratum 16 or just not respond.
> On Oct 31, 2017, at 1:03 PM, Attila Kinali <att...@kinali.ch> wrote: > > Hoi Leo, > > On Sat, 28 Oct 2017 11:14:08 +0100 > Leo Bodnar <l...@leobodnar.com> wrote: > >>> From: Attila Kinali <att...@kinali.ch> >>> Can you tell a little bit how your device looks like on the inside? >> >> GPS is a Ublox. MCU is Cortex-M7 and does not run any OS - just main loop >> with prioritised interrupts. Network stack is hand-made. >> I don't use saw-tooth correction in this device because +-11ns is not worth >> correcting for NTP application for such a budget device. >> If you can build a test NTP client system that can detect sawtooth 10ns >> offset from the NTP server I'd like to know how you did it. > > 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? > > 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. > > > Attila Kinali > -- > It is upon moral qualities that a society is ultimately founded. All > the prosperity and technological sophistication in the world is of no > use without that foundation. > -- Miss Matheson, The Diamond Age, Neil Stephenson > <hakuoro.png><hakuoro-zoom.png>_______________________________________________ > 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. _______________________________________________ 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.