Regarding the thread about NTP as a backup timing source: We've done quite a lot of customizing of NTP code here in our lab, and researching ways to make it better than typically 20mS on a good day (reliably) over the cloud. One of the main problems is that core assumption that the outbound packet time between client and server is the same and the return packet time between server and client. That is almost never true in the real world, and is commonly off by several mS or hundreds of mS.
There are many reasons for this - it could be that the hop-path from client to server is different than server-to client. "Store and forward" routers can add several tens of mS delay to a UDP packet - or not. Even connecting a client directly to an NTP server will still be error prone at the MAC / PHYS interface chips and how often / accurately / symmetrically the OS checks those chips. It is the symmetry of how the data flows outbound vs. inbound, not necessarily the speed at which the packets travel. And the symmetry of packet timing in/out just isn't very good on any Ethernet system. Not as good as a "time-nut" would like, anyway. Then we haven't even gotten to the CPU overhead to when it is intruppted to service the MAC / PHYS chip. OR what happens when then NTP code thread itself gets interrupted while its trying to calculate a clock adjustment. There are systems which put the Ethernet MAC / PHYS functions in an FPGA chip so that the incoming and outgoing packets can be time-stamped more precisely - especially for IEEE 1588 applications, but these techniques still assume equal inbound / outbound packet travel times and typically only work well for LAN intranet applications, not Internet applications. Anywhere the Ethernet time-stamp packet has to cross a router, NAT, store and forward, choice of routes, etc. is going to pose a challenge for any time-synch method. Of course, over the very long term, NTP is essentially zero drift, and is as accurate as NIST. But in the short term it is a very, very jittery source of time. For most computer applications (time-stamping files, general housekeeping) NTP is fine and works well - that's what is was designed for. As a backup time source to GPS?? I don't think its going to serve that purpose in its current form, without some serious averaging. You can average out the jitter, but its still hard to get a confident total clock offset from point A to point B in the real world that is less than a few tens of mS. I'm not sure uSec is reasonable over the cloud with one NTP cycle. That doesn't mean it can't be done, but there needs to be a method that doesn't assume symmetrical packet travel time, I think. If you don't care about total time offset from point A to point B, I suppose NTP could be used to stabilize an oscillator IF you averaged out the jitters over a longer term before applying a correction to your local oscillator. For testing NTP packet timing, you might consider this test method: Use a second computer (as a test platform) running a port sniffer like Wireshark (used to be Etherreal). It helps if the second coomputer is running on an accurate oscillator, like a TCXO or better. Now you can watch your NTP packets leave the first computer (the unit under test) and see when they leave, and see when the packets return from the NTP server, and you can look at the data payload and see what the timestamps are. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
