[ntp:questions] losing time fast

unruh unruh at invalid.ca
Tue Jul 10 05:40:56 UTC 2012


On 2012-07-09, Ron Frazier (NTP) <timekeepingntplist at techstarship.com> wrote:
>
>
>
>
> unruh <unruh at invalid.ca> wrote:
>
>>On 2012-07-09, Dave Hart <hart at ntp.org> wrote:
>>> On Mon, Jul 9, 2012 at 18:14 UTC, Fritz Wuehler wrote:
>>>> I noticed the clock on my main desktop was off by 28 minutes today
>>and it
>>>> increased to 45 minutes. I resync'd with ntpdate manually and it has
>>drifted
>>>> behind again about 7 minutes in the last few hours.
>>>>
>>>> I am using ntp version 4.2.4p7 which was installed with Slackware on
>>Linux
>>>> kernel 2.6.29.6. Until today the clock on this system has always
>>matched the
>>>> clocks of the other machines on my network. The system has been
>>running for
>>>> several years essentially unchanged.
>>>>
>>>> The only thing that changed (that I know of) is I added a new
>>machine to my
>>>> network recently. Its clock matches all the other clocks. I don't
>>see any
>>>> unusual messages from ntpd in my log or messages files on the system
>>with
>>>> the problem. One system has problems, all others appear to be fine
>>and have
>>>> synchronized clocks.
>>>>
>>>> I realize this isn't much information but I don't know what to look
>>for. Can
>>>> anyone tell me how to troubleshoot this? Thank you.
>>>
>>> Stop ntpd using whatever means is normal for your OS.  Find the path
>>> to the drift file (which preserves an estimate of your system's clock
>>> rate error):
>>>
>>> $ fgrep drift /etc/ntp.conf
>>> driftfile /var/lib/ntp/drift
>>>
>>> Then remove it and restart ntpd.  It will synchronize once then spend
>>> 1024 seconds (17m) measuring the clock rate error.  With any luck it
>>> will be an accurate-enough estimate that ntpd will then converge on
>>> its own.
>>>
>>
>>If he is losing minutes per hour, this is hopeless. That is 16000PPM.
>>npt cannot correct that. Ssomething is very very wrong. 
>>
>>> Note to regulars:  I'm going to have sporadic internet access for the
>>> rest of July, so I won't be as responsive.  Your help is welcome.
>>>
>>
>
> I'll admit to not following this thread too closely.  I've been looking at some of the posts.  I will also admit to not being an NTP expert.  However, I remember once when I was getting a clock error of a few minutes per hour.  I think (but wouldn't bet my life on it) that it may have happened after I copied the NTP directory to another system and the drift file was wrong.  Therefore, the NTP program was running the system software clock at the wrong rate and the clock was rapidly getting too far out to correct.

If he is really loosing minutes par day, then there is no drift file
that could do that. 
But certainly your suggestions are worth trying. 

>
> I would recommend the following:
>
> a) Stop ntpd (as mentioned above)
> b) check the config file to make sure it's configured to use a drift file, and find the location of it
> c1) set both minpoll and maxpoll to 6 (64 seconds) if polling the internet
> c2) set both minpoll and maxpoll to 4 (16 seconds) or 3 (8 seconds) if polling the LAN or a GPS
> d) delete the drift file (as mentioned above)
> e) find the startup script for ntpd, which might be in the /etc/init.d or similar folder, is probably named NTP, and see what parameters it uses, and make a backup of it
> f) edit the startup script with elevated privileges (ie sudo, if applicable)
> g) insert the parameter (which I cannot remember the letter of) which allows ntpd to step the time at first
> h) save the startup script
> i) sync to a national time standard server for his country 3 times in quick succession with ntpdate set to make a step change (In the USA, I would use NIST.)

Why a national time server? No need for that kind of accuracy.


> j) start ntpd back up
> k) let if run several hours
> l) this should set a valid drift file and reign in the clock speed fairly rapidly
> m) stop ntpd
> n) reset the startup script to the way it was unless you want to leave the step command in there
> o) reset the config file for the original minpoll and maxpoll
> p) restart ntpd
>
> Hopefully after a few more hours of running, the clock will be stable.  You can even put the stop ntpd, ntpdate, ntpdate, ntpdate, start ntpd sequence in your own script and run that for greater speed and accuracy of the ntpdate sequences and minimal delay restarting ntpd.



More information about the questions mailing list