[ntp:questions] ntpd questions - FreeBSD 5.5

David Shoulders dhs at bendcable.com
Mon Jul 20 00:08:05 UTC 2009

Danny -

I don't have a critical need for accuracy, so I didn't want to add any 
more load to the servers than necessary.  I thought that a few hits 4 
times a day would be a smaller load than running the daemon all the 
time.  Now that my computer's clock seems to be running inconsistently, 
the load from the ntpd running continuously would be even higher, right?

BTW, new data on my little mystery:  the computer clock seems to gain 
time (like 2 seconds in 3 hours) during times when I'm using my other 
systems -- never when idling.  This even though the computer is just 
providing nfs service and occasional backups.  Shouldn't an increase in 
average load slow the clock (by masking more interrupts)?

(Sorry to be dragging this thread out.  I've been out of town.)


- David

Danny Mayer wrote:
> David Shoulders wrote:
>> I have a little file server running in my basement, and since it's the 
>> only machine running all the time, I set it up to run ntpd and provide 
>> clock settings to my other machines.
>> The machine is running FreeBSD 5.5.  I installed it some years ago, and 
>> have had no reason to upgrade it.
>> Initially, I ran ntpd for a day or two to establish a drift value, then 
>> killed it and set up a crontab entry to run "ntpd -q" every 6 hours.  
>> This worked perfectly for 2 or 3 years.  Corrections were always small 
>> numbers of msec.
> If you are going to use ntpd -q you should use ntpd -qg to allow it a
> large step if that is necessary. There is in any case no need to stop
> ntpd. It will keep going correcting your clock as long as it's running
> and adjusting the drift file as necessary.
>> Then, a few days ago, a disk failed.  I replaced the disk and restored, 
>> and everything was fine -- except that I had lost the drift file.  So, I 
>> started ntpd, let it run overnight, and looked at the drift file.  It 
>> had an obviously bogus number.  The clock corrections were very large 
>> and not getting smaller.  So I put a reasonable number in ntp.drift 
>> (based on my vague memory of the old good value -- about 100), restarted 
>> ntpd and let it run a few hours.  It seemed to be converging, so I 
>> stopped it and reinstated the crontab/ntpd -q routine -- this time every 
>> 3 hours.
>> 12 out of 19 corrections were around 20-30 msec, but the others were 
>> off-the-wall -- hundreds of msec.  So I did some arithmetic (on the 
>> reasonable corrections only) and adjusted the drift value.  Since then, 
>> most of the corrections have been less than 10 msec, but I'm still 
>> getting some crazy ones -- like 1.7 seconds!
>> The wild corrections are all in the same direction (-), so I don't think 
>> the time derived from the servers is wrong.  It seems as if the clock in 
>> the PC must be taking off on wild excursions occasionally.  Is this 
>> possible?  How could replacing a disk have brought this on?  What am I 
>> missing?
> There is no reason to run ntpd -q in a crontab. You can just keep it
> running and it will maintain synchronization. Do you have a particular
> reason not to keep it running? Are you on a dialup line to the outside?
> If so ntpd can keep account of that.
> Just use ntpd -gN and let it run. (The N is for nice).
> Danny

More information about the questions mailing list