[ntp:questions] Wrong time after changing hardware
smith at cag.zko.hp.com
Fri Jul 20 22:10:05 UTC 2007
Richard B. Gilbert wrote:
> Tom Smith wrote:
>> Marc Muehlfeld wrote:
>>> I'm running a NTP server on one of my Linux servers that distribute
>>> time in our local network. But since I changed Mainboard/CPU/RAM on
>>> that machine, the machine is allways having a time in future.
>>> When I restart the NTP service, the time is sycronized again. But
>>> allready after 12h there is a drift difference of about +6 seconds.
>>> Meanwhile I reinstalled the service, but that didn't made any
>>> changes. Before switching to the new hardware, it run fine for about
>>> 1.5 years.
>>> Any idea?
>>> The server is running Suse 10.0 with xntp 4.2.0a.
>> Hello Marc.
>> I'm surprised nobody has described the obvious yet.
>> You changed the oscillator, so the system has a different characteristic
>> frequency error than your previous hardware. However, you are, I assume,
>> using the same filesystem, including the previous /etc/ntp.drift (or
>> wherever you drift file is stored) that contains the frequency error of
>> your previous hardware.
>> 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
>> This will re-initiliaze the drift rate for your new hardware. Give it
>> a day or 2 to settle without stopping (x)ntpd. If you still have
>> a problem at that point, you may have some other hardware-related
>> issue, but that's the first step.
> I think you are giving the drift file more weight than it deserves. Ntpd
> updates the drift file hourly so as to provide a reasonable starting
> value in case of a reboot or restart. If ntpd has been running for an
> hour or more, the drift file should have a reasonable value in it.
> No matter what's in the drift file, NTP is supposed to measure the
> drift. The contents may be helpful or hurtful at startup but once ntpd
> is running they should not matter.
The drift file does matter. If it's there, that's where it starts, and
adjustments to the drift rate from there are small and slow. If it is not
there, it starts from scratch and converges on a correct rate much more
The classic "My clock runs too fast/slow" problem is a drift file with
a bogus value so large it can't be corrected in any period of time a
system manager is willing to wait for.
More information about the questions