[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