ntp.drift

ntp.drift

Post by Walter HIL » Wed, 26 Jan 2005 13:52:56


Hi,

I have a Sun Blade 100 workstation running Linux 2.4.27 and have
compiled and installed ntpd

The computer has been running for several weeks yet the ntp.drift file
still contains 0.000. Yes ntp.conf contains

driftfile /var/lib/ntp/ntp.drift

The computer was losing about 2s / hour prior.

Is there another parameter required in ntp.conf?

drwxr-xr-x 2 ntp ntp 4096 Jan 25 12:23 .
drwxr-xr-x 11 root root 4096 Jan 24 20:23 ..
-rw-r--r-- 1 ntp ntp 6 Jan 25 12:23 ntp.drift

Thanks.
 
 
 

ntp.drift

Post by Martin Bur » Wed, 26 Jan 2005 17:45:27


No.

There are 2 things you could check:

1.) Has the NTP daemon synchronized to some time source other than "local
clock", i.e. is there a '*' in the first column of the output ot the
command "ntpq -p"? If in doubt, please post that output here.

2.) Is the NTP daemon running chrooted? Then the directory "var/lib/ntp/"
must exist below the chroot jail directory and be writeable for the daemon.


Martin
--
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

 
 
 

ntp.drift

Post by John DeDou » Sat, 29 Jan 2005 08:28:41


Don't know what operating systems those machines run.
On a few Linux systems, ntpd was hacked to run under user id
"ntp", but the install forgot to make directory /var/lib/ntp and/or
the file ntp.drift writeable by user "ntp". If the system
is Unix/Linux, check the user running ntpd by use of the "ps"
utility. Then use "ls -l" to check ownership and privileges
on /var/lib/ntp and /var/lib/ntp/ntp.drift.
 
 
 

ntp.drift

Post by Walter HIL » Sat, 29 Jan 2005 10:06:44


remote refid st t when poll reach delay offset
jitter
==============================================================================
+nimda.mailworx. 198.30.92.2 2 u 223 1024 77 296.561 1336.97
505.919
caenis 192.43.244.18 2 u 22 64 377 1.724 827.625
963.550
*cerberus 128.250.36.3 2 u 26 64 377 0.729 896.530
901.532
LOCAL(0) LOCAL(0) 10 l 20 64 377 0.000 0.000
0.002

caenis and cerberus are on the local subnet.


When I installed ntp (Running Gentoo - Installed ntp as a "package")&
first ran it, it complained about the content of ntp.drift so i seeded
it with 0.00 and restarted the daemon. It didn't complain on the restart
so I assume it can read the file.

drwxr-xr-x 2 ntp ntp 4096 Jan 28 08:28 .
drwxr-xr-x 13 root root 4096 Jan 25 15:24 ..
-rw-r--r-- 1 ntp ntp 6 Jan 28 08:28 ntp.drift

I can't answer the chroot question.

Thanks.
 
 
 

ntp.drift

Post by Harlan Ste » Sat, 29 Jan 2005 12:56:29

That's bad jitter and offset.

H
 
 
 

ntp.drift

Post by Richard B. » Sat, 29 Jan 2005 13:06:28


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!

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

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
suggest deleting the existing file. ntpd should create a new file with
a drift value in it. The ntpd daemon should create a temporary file
with a new value, delete the existing file and rename the temporary file
each hour. Make sure that ntpd has write access to /var/lib/ntp.

On some flavors of Unix ntpd runs, not as root, but as user "ntp". It
is so with Red Hat. If Gentoo is the same, make sure that /var/lib/ntp
is owned by ntp with permissions rwxr-xr-x. If the existing file is not
owned by ntp, either delete it or chown ntp /var/lib/ntp/drift; chgrp
ntp /var/lib/ntp/drift!

HTH
 
 
 

ntp.drift

Post by davi » Sat, 29 Jan 2005 16:51:54


2s an hour is more than the 500ppm capture range for ntpd.

You either have a broken motherboard (good quality ones will be
within 50ppm and even the worst I've seen are within about 200ppm) or
you are losing a lot of clock interrupts.

In the broken motherboard case, replace it.

Lost clock interrupts are particularly prevalent on Windows and on
Linux. For Linux the problem is that Linux device drivers often disable
interrupts for rather a long time and at the same time recent versions
of Linux have started using 1ms clock ticks, rather than 10ms ones. This
has been extensively discussed over recent weeks on this newsgroup, but
as a general principle, you cannot hope to maintain good time on a machine
that is losing large numbers of interrupts, as the exact loss rate isn't
predictable.

ntp.drift isn't being updated because you never achieve frequency lock.

ntpd is not a solution for broken systems.
 
 
 

ntp.drift

Post by Barry Bouw » Sat, 29 Jan 2005 20:40:12


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 62.2.22.61 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 62.2.22.61 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.



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.



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