perfSONAR User Q&A and Other Discussion

[Mark Feit <>]

Purna Mididuddi writes:
>
> In the output I sent before, the offset for bare-metal is also drifting by 
> about 15ms…

The offset is NTPD’s estimate of the difference between the local and 
reference clocks.  Network conditions will affect this figure, and it will 
change more frequently when sync is being acquired and the server is being 
polled more often. 10 ms in either direction isn’t anything to worry about.

> Is this acceptable in general, for different type of perfsonar tests?

Yes:  Measuring  round-trip time or throughput accurately (or as accurately 
as you can on a general-purpose computer) depends more on the stability of 
the clock in the system and less on knowing exactly what time it is.  If you 
send a packet, look at the clock, wait to receive a reply and look at the 
clock again, all you care about is whether the difference between the two 
time checks is correct, not whether the absolute time on the clock is 
accurate.  The same goes for figuring throughput over an interval.

Yes, but…:  Latency is a different matter because there are two clocks 
involved.  If I look at my clock, send a packet to you and you look at your 
clock when it shows up, the best we can do to figure the time difference 
without knowing how much of that difference is a result of a difference in 
our clocks.  Knowing that requires a high-accuracy reference in both places, 
and if you have one of those, there’s no need to use the clocks in the 
computers.  The 1 ms you get out of NTP  over the Internet means that any 
measurement you take where the topological distance between the hosts is less 
than about 100 miles isn’t likely to be accurate, and it’s possible that the 
receiving end could report that the test packets arrived before they 
departed.  Over longer distances, the difference is just error, and more 
distance dilutes the error.

> Note that this is to a stratum 1 server.

Even so, it’s across a network where every packet can take a different path 
and every hop introduces unpredictable latency.  Better NTP accuracy requires 
a good clock (GPS, CDMA, etc.) at the server end and stable latency.

--Mark