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
