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.

Walter HILL wrote:
> 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?

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

Martin Burnicki wrote:
> Walter HILL wrote:
> 
>>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?
> 
> 
> 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

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.

Martin Burnicki wrote:
> Walter HILL wrote:
> 
>>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?
> 
> 
> 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.

      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.

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

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.

That's bad jitter and offset.

H

Walter HILL wrote:

> Martin Burnicki wrote:
>
>> Walter HILL wrote:
>>
>>> 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?
>>
>>
>>
>> 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.
>
>
>      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.
>
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

Walter HILL wrote:
 
>
>The computer was losing about 2s / hour prior.

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.

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

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


> 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