[ntp:questions] Re: ntp.drift

Barry Bouwsma ntp-200203 at remove-NOSPAM-to-reply.NOSPAM.dyndns.dk
Fri Jan 28 11:40:12 UTC 2005

On Thu, 27 Jan 2005 23:06:28 -0500, "Richard B. Gilbert" wrote:

> >      remote           refid      st t when poll reach   delay   offset 
> >  jitter
> ============================================================================== 
> > +nimda.mailworx.      2 u  223 1024   77  296.561  1336.97 
> > 505.919
> >  caenis    2 u   22   64  377    1.724  827.625 
> > 963.550
> > *cerberus     2 u   26   64  377    0.729  896.530 
> > 901.532

> Something is very wrong here!!  Your offset and jitter numbers two 
> orders of magnitude too large.  I expect offsets and jitter to be less 
> than twenty milliseconds; usually a lot less!  A round trip delay of 
> 296.561 milliseconds seems excessive unless you are using tin cans and 
> string!

Not necessarily -- the jitter from the two local-net machines with low
delay figures is probably due to the local machine's clock drifting.
Without guessing the hostnames of the remote and local machines, I
can't speculate on the network connectivity between them, but observe
how my local performance has gone down the tubes to my next hop,
simply by pumping out traffic on the network, slightly more than tin
cans and string:

+GENERIC(1)      .DCFa.           0 ?    9   16   77    0.000    0.530   0.538
 Cabal-GW       3 u   44   64    3  411.963  201.224   0.935
(yes, this is right after a restart, compare this a few minutes later:)
xCabal-GW       3 u   30   64  377  288.182  139.960 132.882

Normally, the delay is some 7msec, and jitter somewhat less, with
fairly minimal traffic to/from the real world.

> I'd suggested configuring several more servers and selecting a set of at 
> least four servers with low round trip delays and low jitter.

That may not help -- if the traffic levels are too high.  In my
case shown, with a premium-rate connection, as the Cabal-GW peer
is in fact the next hop upstream, I'm not going to see better
figures from anywhere, without drastically reducing the network
traffic flowing.  On the other hand, if the OP's machine and the
mailworx reference are continents apart, that delay figure may
not be as traffic-impaired as my values, and may be improved by
selecting a much closer reference.

> I'm not sure what the problem with your drift file might be but you 
> should not have to create a drift file or seed it with a value!  I would 

Seeding it with `0' is worse, because if no drift file is present,
then ntpd goes into a special initialization mode to calculate the
value needed, quickly.  If the file is present, ntpd has reason to
believe it's correct and isn't going to calculate a new value so
quickly, and it will take even longer to stabilize.

This is why it's better to remove the drift file when swapping OS
disks into new hardware, or juggling boards, or whatever, as the
calculated value is specific to the hardware.  (When I was hardware-
hopping, I grabbed the CPU speed at boot and referred to a different
drift file for each of several machines, all of which had rather
different contents.)

barry bouwsma

More information about the questions mailing list