[ntp:questions] Re: time reset, syncronisation lost and Large PPM values

tor tz at lv.fo
Tue Nov 1 06:24:07 UTC 2005


"Johan Swenker" <no_spam_please at swenker.xs4all.nl> skrev i en meddelelse
news:pan.2005.11.01.00.33.39.200240 at swenker.xs4all.nl...
> On Sun, 23 Oct 2005 14:18:43 +0000, Tom Smith wrote:
>
> > mike wrote:
> >> The explanation is that the kernel also keeps a frequency drift value
> >> that is persistent across boots. It is kept in /etc/adjtime. If this
> >> file exists in your implementation, just removing it might be the
> >> answer. It fixed my problem.

/etc/adjtime comes from a package called initscripts, and
/etc/adjtime is updated by hwclock(8) which is from a util-linux package.
If /etc/adjtime is removed then running hwclock will create it again.
hwclock --hctosys is run at startup by both apmd and rc.sysinit
hwclock --systohc is run at shutdown by halt

> > Interesting. Hadn't run into that one (yet). Maybe setting the contents
> > of the drift file to "0.000" instead of deleting the file would also
> > get around that hickup, if that (or something similar) is, in fact,
> > the problem.

Setting 0.0 into the drift file helped somewhat by initializing the
frequency to 0.0.
Removing the driftfile kept the large frequency ppm (500).
Still I end up the same place.

> You should REMOVE adjtimex and it's configuration file from your system or
> at least prevent it from starting.

Are you thinking of a command named adjtimex ?
Here - on RHEL3  - adjtimex(2) is a system call.

> 2) adjtimex uses an obsolete parameter in a systemcall. Unfortunately
> it does have an effect: it set's the kernel variable STA_CLK. This is
> interpreted by ntpd: don't mess with the clock, some other program handles
> the clock.

Any idea of how we can see the value of this STA_CLK variable ?


I have been messing with the adjtime and the drift files - the following
script is how I restart ntpd by now

---8<---
#! /bin/sh
# reset configuration files and restart ntp
TZ=UTC  # We work in UTC here
service ntpd stop

# reset hwclock configuration to sane values
cat <<EOM >/etc/adjtime
0.000000 0 0.000000
0
UTC
EOM

# reset ntpd drift file - if we just remove it then the kernel keeps using
large (>500) PPM values.
echo 0.000 >/var/lib/ntp/drift
chown ntp.ntp /var/lib/ntp/drift

# Copy servers from ntp.conf to step-tickers, so ntpdate will be called and
set the systemtime.
/usr/bin/awk '$1=="peer"||$1=="server"{print $2}' /etc/ntp.conf | grep -v
^127.127. >/etc/ntp/step-tickers

service ntpd start
---8<---

I still get 2 resets an hour (depending on load ?), synchronisation lost and
a large frequency (512 ppm).
If I read the log correctly then "kernel time dicipline status change 1"
means the kernel is now adjusting the hardware clock.

Nov  1 04:45:45 lv-lomur ntpd: ntpd shutdown succeeded
Nov  1 04:45:46 lv-lomur ntpdate[12129]: step time server 172.17.2.71 offset
0.540713 sec
Nov  1 04:45:46 lv-lomur ntpd:  succeeded
Nov  1 04:45:46 lv-lomur ntpd[12133]: ntpd 4.1.2 at 1.892 Thu Sep 11 05:38:15
EDT 2003 (1)
Nov  1 04:45:46 lv-lomur ntpd: ntpd startup succeeded
Nov  1 04:45:46 lv-lomur ntpd[12133]: precision = 9 usec
Nov  1 04:45:46 lv-lomur ntpd[12133]: kernel time discipline status 0040
Nov  1 04:45:46 lv-lomur ntpd[12133]: frequency initialized 0.000 from
/var/lib/ntp/drift
Nov  1 04:46:29 lv-lomur ntpd[12133]: kernel time discipline status change
41
Nov  1 04:47:31 lv-lomur ntpd[12133]: kernel time discipline status change 1
Nov  1 05:21:53 lv-lomur ntpd[12133]: time reset 1.033389 s
Nov  1 05:21:53 lv-lomur ntpd[12133]: synchronisation lost

Now ntptime now show an offsett of 0.000us and the frequency is 512.00 ppm.
:-(
The adjtime was unchanged
The driftfile has been updated - to the maximum value (500.000)

I should add that ntpd works fine a number of servers here (including
PowerEdge 2600 (RHEL3))
Yet ntpd fails on another HP box (RHEL3) just like on the PE2650´s.



More information about the questions mailing list