[ntp:questions] Wrong time after changing hardware

David L. Mills mills at udel.edu
Mon Jul 23 21:27:37 UTC 2007


Per,

Aside. The Linux style to provide an initial frequency file with ASCII 
zero content completely defeats the rapid initial frequency calculation. 
At first startup of a virgin system, the location of the file should be 
specified, but the file itself should not exist. This is the latest in a 
long list of Linux attempts to fix something that ain't broke.

Dave

Per Hedeland wrote:
> 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
> procedures.
> 
> 
>>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+ 
>>E3010.
> 
> 
> 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