[time-nuts] Tracking NTP displacement and correlation between two clients.

Attila Kinali attila at kinali.ch
Thu Oct 4 12:23:50 EDT 2012

On Thu, 4 Oct 2012 10:44:41 -0400
bownes <bownes at gmail.com> wrote:

> I'm convinced that it really isn an issue as long as the two systems in
> question remain within a few 10's of ms. However, I have no off the shelf
> method of collecting and correlating the data. Before I go out and invent
> the wheel, I thought I would check and see if anyone has done such a thing
> and saved the scripts and whatnot. 

I guess, the simplest method would be to add system A to the ntp server
list of system B, but as a non-refernece station (don't remember the
flag needed for that, but it's somewhere in the documentation), then
you can track the difference between the two systems by using the
peers log on system B. Of course, it will differ from what the value
actually is, but it should be accurate within one RTT between
system A and B.

If you cannot track one system from the other, using a different
NTP server that can be reached from both, could do the job.
Again, let the system A and B track it as non-reference station,
but make sure to keep a high poll rate (the standard 1024s is too
low and will not get you enough data to do usefull statistics with
"short" measurement times).

Of course you can also use a GPS as reference "ntp" server on
system A and system B and measure the offset against that.

Doing a plot from the peers log is then a simple matter of handling
gnuplot and maybe a line of perl for statistical analysis (or excel
if you prefer that other OS ;-)

That's the proof of the measurement style.

The other possibility would be to have both peer logs of system A and
B analysed for the RTT and jitter values. From that you can argue that
the time difference between the two systems is at most (RTT_A_max+RTT_B_max)/2
(theoretically one leg of the path to the ntp server could have zero delay.
thus the calculated delay would be off by half the RTT). This will clearly
overestimate the time difference between the two systems.  A more accurate
time difference value would be jitter_A+jitter_B under the assumption
that the packet delays on both legs of the path are nearly identical[1].
There is no division by 2 using the jitter, because jitter does not
need to be symetrical around an average, but can have any probability
distribution. Thus (jitter_A+jitter_B)/2 could underestimate the actuall
time difference.

[1] this assumption should hold true for most networks these days
given that:
1) the jitter is much smaller than RTT
2) none of the network connections is conguested
You can "test" it if you do a traceroute from both ends of the path.
If both tracerouts show the same routers, then the path that the packet
travels on the its way back and forth is the same.


			Attila Kinali

There is no secret ingredient
         -- Po, Kung Fu Panda

More information about the time-nuts mailing list