NTP problem - Clock too fast for NTP to keep up?

[Robin Laing]

Peter Kiem wrote:
> Hi Gene,
> 
>>>> I too had the fast clock problem, and by tickling the tick counter
>>>> with the 'tickadj' command, was able to stay well within 1 second
>>>> per hour.  The bare command will return the current tick value,
> 
> 
> Ahhhh the light dawns.  I didn't realise it was a program, I thought it 
> was an option for NTP.
> 
>> Lower.  Default is 10000.
>>
>> Setup an ntpdate to hit the net for the time, say hourly.  Put
>> a tail on the log so you can see how far off it is.
> 
> 
> Well I've reverted to the ntpdate every 2 mins so this should be pretty 
> fast to see the difference.
> 
>> Set tickadj to 9950 and see if it still gains time, if it does,
>> try 9925.  Here, that was enough to make it start running slow,
>> and I wound up in the 9926 to 9927 area for get the thing running
>> within range of the soft only, no step adjustment in ntpdate.
>>
>> Once fine tuned, stick that tickadj in your /etc/rc.d/rc.local file.
> 
> 
> Thanks for the suggestion :)
> 
> This is what I am currently seeing
> Feb 10 16:04:04 krusty ntpdate[8692]: step time server 202.173.151.129 
> offset 2.372749 sec
> Feb 10 16:05:38 krusty ntpdate[8748]: step time server 202.173.151.129 
> offset -22.546148 sec
> Feb 10 16:05:59 krusty ntpdate[8754]: step time server 202.173.151.129 
> offset -2.965399 sec
> Feb 10 16:07:44 krusty ntpdate[8770]: step time server 202.173.151.129 
> offset -16.632290 sec
> 
> As you can see it is a pretty rapid time gain :(
> 
Throwing out a question for those more experienced.

I am working with FC1 and I don't know if there are changes in FC that 
differs in regards to time.

Looking that the offsets between the individual checks seems to bounce 
around.  Pretty severe changes that makes me wonder if the checks may 
be happening to fast, especially if running in VMware.

Another note:
Looking at the man page for ntpdate I read this.

"Time adjustments are made by ntpdate  in one of two  ways.  If 
ntpdate determines  the  clock  is in error more than 0.5 second it 
will simply step the time by calling the system  settimeofday() 
routine.  If  the error  is  less  than 0.5 seconds, it will slew the 
time by calling the system adjtime()  routine. The latter technique is 
less disruptive  and more  accurate  when the error is small, and 
works quite well when ntpdate is run by cron  every hour or two."

With the time being so far out, ntpdate isn't adjusting the offset. 
The usage of hwclock --adjust may be necessary to get the /etc/adjtime 
to change.

This poses the question if /etc/adjtime is being changed?

-- 
Robin Laing