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

[Gene Heskett]

On Thursday 10 February 2005 01:10, 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.
>
Given a stable clock in your box, which from the reports below I 
doubt, every 2 minutes would, I think, give results that are totally 
lost in the propagation delays of the net.

>> 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 :(

I'd say that the above statement is a good candidate for the 
understatement of the week at least, maybe longer.  Good grief!  
Thats a 22 second gain in a minute 34.  But then its only 16 seconds 
in 1:45.  And again its 3 seconds in 21 seconds.  Even given the 
unpredictability of network delays, that would appear pretty erratic 
to me.

This doesn't look like a tickadj correctable error to be truthfull 
unless you take tickadj down in the 6000 - 7500 range.  This one 
looks as if it really does need code scrutiny, more than I can give 
it since I'm just an old fart lurker most of the time and haven't 
hacked more than 100 lines of kernel code if even that much since 
1997 when I first installed linux.

Asking the next obvious question, do you have cpufreq enabled?

>--
>Regards,
>Peter Kiem
>
>Zordah IT - IT Consultancy and Internet Services
>Ph: (0414) 724-766   Fax: (07) 3344-5827
>Web: www.zordah.net  Email: zordah at zordah.net

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.33% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.