[ntp:questions] Re: offset values from ntpq and ntptrace

Richard B. Gilbert rgilbert88 at comcast.net
Thu Mar 30 13:13:06 UTC 2006


Tanguy.ropitault at gmail.com wrote:

> Ok, but it seems that in loops statistic file, the value given for
> offset is the value of the ntptrace command result so statitic files
> are incorrect??? that is the thing i want to know because i want to see
> the performance on NTP on my network, and when i monitor this with
> statistic files, i have weird things...
> For example, I have a computer on my LAN that is my NTP server. It
> synchronizes on NTP's pool.ntp.org server. And all the other computers
> of my LAN are synchronized on my NTP server. When I look statistics,
> the offset field on the clients have lower value than my ntp server.
> Normally, a client machine cannot be more accurate than its server but
> it's the case here, because server offset are higher than client...
> what is the problem?
>

The problem lies in your interpretation.  Offset is not a measure of 
accuracy!   It is literally the difference between the time received 
from the server and your client's clock.  The time received from the 
server is degraded by its trip over the network which introduces random 
delays in the paths to and from the server.  NTP's algorithms must 
assume that the delay is symmetrical when, in fact, it rarely is.  So 
the packet takes 12 milliseconds to get to NIST and 14 milliseconds to 
return; the time is off by one millisecond.

You have hundreds of miles of cable and several routers between NIST and 
your site. Every router, every repeater, switch and hub introduce 
delays.  You have, perhaps, fifty feet of Cat-5 cable between your 
server and your clients.  Just to add to the fun, packets are not 
guaranteed the same route going and returning.  If you are in New York 
and the server is in Los Angeles, the request packet might go direct and 
the return packet might travel via Dallas-Fort Worth!

These errors are normally small but there are occasional cases where the 
asymmetry is quite noticeable.   ADSL connections exhibit this asymmetry 
to a greater or lesser degree.  Long distance dialup connections to an 
internet provider have been known to exhibit this problem.


The ntptime command should give you the "estimated error" in your time.




More information about the questions mailing list