Question

I have an application that depends on gpsd and ntpd to accurately set the system time on a linux machine.

gpsd is fed NMEA + PPS

The application is punping ~25MB per second over the network and I think the loading on the system is causing jitter in the time somehow. (loaded PCI express bus causing irregular interrupt latency)

I have another machine that is not loaded at all that I could setup to read the GPS and act as an NTP server for the loaded machine. (the loaded machine would be getting startum 1 ???)

How accurate can I expect the time to be from a stratum 0 NTP server on the same subnet on Ethernet?

I hope this is not too off topic, I am sure sometime someone else will be happy the answer is documented here. ;-)

Was it helpful?

Solution

Best info I could find on NTP accuracy, seems to point at 1-2 ms in a LAN setting:

NTP v4 with kernel mods to support it, is capable of much better than 1ms accuracy, possibly as good as 1ns. According to [Dave Mills] article, NTP v3 is accurate to 1-2ms in a LAN and 10s of ms in WAN nets. http://www.cis.udel.edu/~mills/ntp.html

Other articles suggest that with an accurate time source, such as a GPS time source, NTP is accurate to 50us, but the links on the Linux kernel support say that accuracy of a few ms are possible. http://www.atomic-clock.galleon.eu.com/support/ntp-time-server-accuracy.html

Another article says that it is dependent on the predictability of network delays (i.e. a low jitter network). http://www.postel.org/pipermail/end2end-interest/2003-April/002925.html

OTHER TIPS

NTP is usually considered good for small single-digit ms in this sort of situation.

After it has been running for a few days, there shouldn't really be much jitter in any of the the actual clocks, because the ntpd implements a heap of very long time-constant filtering.

However, you don't really say how you're measuring the time, and whatever mechanism you're using might be just as jittery as (if not more than) the underlying synchronisation.

If you do have a busy network and network cards with really deep buffering, then that might not be helping things, as the jitter between packet arrival and interrupt service will be larger. The fancier your Ethernet switching is the worse it is for timing too - old fashioned hubs are better than switches in this regard.

The stratum level of the NTP server in question has no relation to the accuracy of the clock/server. It purely means the distance away from the "reference clock" you are.

What matters more, in regards to NTP accuracy (in regards to time, of course) is network latency between servers, type of server being used, and potentially server load. Depending on what NTP server you use, they document on how accurate their time will be. Each server software uses various algorithims to compute time based on network latency and server load, and it comes down to the accuracy of those algorithims.

For instance, MS NTP server states that it will be accurate within 2 seconds. OpenNTPd has stated that they won't give you the possible accuracy of the server. There are instances where stratum 3 servers can be more accurate than stratum 2 servers, etc.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top