On Thu, 4 Oct 2012 10:44:41 -0400 bownes <bow...@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. HTH Attila Kinali -- There is no secret ingredient -- Po, Kung Fu Panda _______________________________________________ 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.