[ntp:questions] Wrong time after changing hardware

Per Hedeland per at hedeland.org
Mon Jul 23 21:02:02 UTC 2007

In article <f81hmu$1l7$1 at svr7.m-online.net> Marc Muehlfeld
<marc.muehlfeld at web.de> writes:
>Tom Smith schrieb:
>> 1) Stop (x)ntpd
>> 2) Delete your existing ntp.drift file (the path should be shown in
>>    your ntp.conf)
>> 3) Run "ntpdate -b [a reliable server]"
>> 4) Start (x)ntpd
>I allready did the described steps. But it changed nothing. Also a new 
>ntp.drift file is not created. The old one contained "0.000". Also i 
>completely reinstalled the service.
>Im sure that I look to the right file. /etc/ntp.conf shows me
>driftfile /var/lib/ntp/drift/ntp.drift
>And thats the file i look at.

Note that the location can also be specified via the commandline (-f
option), overriding what is in ntp.conf AFAIK. I.e. check the
commandline of your running ntpd too. In any case the driftfile spec you
have there is pretty "weird" - I've seen some Linux distros use
/var/lib/ntp/drift (i.e. a file called 'drift' in the /var/lib/ntp
directory), which makes some sense when running ntpd as non-root, but
your pathname is just "stupid" (no offense intended:-). And, the fact
that the old file had 0.000 means that it wasn't used by ntpd either,
the 0.000 having been put there by misguided Linux installation

>I had bought and installed this mainboard on two other servers and there I 
>have the same problem. Without syncronizing the time, the time is allways 
>wrong of about 6-10 sec. per 12h. The mainboard, I use is a Supermicro PDSME+ 

This works out to roughly 200 ppm or a bit less - there shouldn't be any
problem for ntpd to correct for that.

>Currently my workaround is, to restart ntpd every hour on the server. At this 
>time the time is sycronized. Then the other machines who syncronize with my 
>ntp server via ntpdate, get the right time. Not a fine solution, but at the 
>moment, it works.

This may actually be due to your "restart" of ntpd running ntpdate as
part of the rc script's "start" function. But anyway, I don't see that
anyone has asked for, or you have provided, the most important info:
Output of 'ntpq -p', after ntpd has been running for a significant
while. Also check your logs (typically /var/log/messages) for any
messages from ntpd.

>Maybe it's really a problem with the kernel shipped with 10.0, like Martin 
>Burnicki wrote.

I'd say this is out of the question given the symptoms you (now)
describe - maybe if your system time had been running totally berserk,
but 6-10 seconds drift in 12 hrs is "mostly OK", meaning that the kernel
has no problem setting up the counters it wants to tick and interrupt at
the desired rate, and that's quite enough for ntpd to do its thing.

--Per Hedeland
per at hedeland.org

More information about the questions mailing list