From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020827
Description of problem:
OK, the clock on my laptop isn't that good. But I can adjust
for its systematic drift using
adjtimex --tick 10151 --frequency -4380195
That worked great in RedHat 7.3, but now that I've upgraded
to RedHat 8.0, this value is rejected by adjtimex:
# adjtimex --tick 10151
adjtimex: Invalid argument
What's worse, adjtimex --adjust fails for the same reason, once it
realizes how much of an adjustment it needs to make:
# adjtimex --adjust
--- current --- -- suggested --
cmos time system-cmos 2nd diff tick freq tick freq
1034215946 3496.727966 3496.727966 1953 -17548967
1034215953 3499.140679 2.412713 1953 -17548967
1034215961 3501.506561 2.365882 1953 -17548967 -416 2885504
1034215968 3503.870485 2.363924 1953 -17548967 -414 2609554
1034215975 3506.285170 2.414685 1953 -17548967 -464 -2376853
adjtimex: Invalid argument
Aside from the fact that I ought to complain to the manufacturer
of my PC (do you have a suggestion for exactly how I should word
my complaint, given that the machine wasn't shipped with Linux),
it would be nice if Linux would once again allow me to have a
somewhat sane clock, as it did in RedHat 7.3.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. adjtimex --tick 10151
Actual Results: adjtimex: Invalid argument
Expected Results: Command accepted and time parameters adjusted
I'm running a Dell Latitude C840 laptop. Are their clocks
all this bad?
I have no workaround.
adjtimex --tick 10000 fails. This is the nominal value of the tick,
so clearly something is very wrong here. adjtimex accepts values between
1757 and 2148. This is clearly very wrong, as the nominal value should
be 10000, and the documented range is 9000 to 11000. The value I'm using,
10151, is well within the documented range accepted by adjtimex.
I've noticed the same problem. Also, my clock behaved normally on 7.3 and
drifts terribly now. I wonder if this has something to do with changes made to
the kernel to make it more responsive. I remember reading somewhere that the
kernel interrupt now happens ~10 times more often that it used to. That would
explain both the fact that the times recommended by adjtimex are so much lower,
and could have something to do with where the trouble might be coming from.
No tick value in the new valid range gets my clock better than 2% slow.
It may be a function of the latest RedHat-supplied kernels. Try
cd /usr/src/linux-`uname -r`
grep -r CONFIG_HZ *
The i386 and i586 kernels have HZ set to 100, but for some reason the i686
value has been changed to 512. The tick and frequency numbers adjtimex uses
are now based on 512 kernel tick interrupts per second. sysconf(_SC_CLK_TCK)
still reports 100, though. Does anyone know if ntp is also affected, or why
this change was made?
The same bug appears on Dell c400 laptop. The --adjust option came up with
tick=10793 freq= -1431594. The clock ran very fast.
By applying the EXAMPLE method over 10 hours, I got tick=10008
freq=-1835614. These make the clock virtually perfect.
Note that the --adjust tick increment is 100 time larger than what I found
was needed. Therein lies the problem.
Perhaps this will work: set tick to 10000; find the correction via
--compare; divide the correction increment by 100 and add or subtract from
10000; run --compare again to get freq, but ignore the tick correction.
I should have been more detailed in my earlier comment. I am still running
7.3 but with adjtimex 1.12-2. There is no problem setting 10000 with these
versions, but the correction calculated by --adjust was much too big. It
calculates ~10800 ticks which is an adjustment of 6400 seconds per day!
Your original correction of 10151 also seems large, if the manual pages are
correct. You must have been losing 8.64*151= 1304 seconds per day, ~22 minutes.
Does that sound right?
Perhaps when the authors went in to fix the 100x mistake they scaled the
10000 down by 512 instead of just the increment they added.
Sorry the problem and solution I found didn't apply, but you might try
reinstalling the old version 1.12-2, which is on the 7.3 CD-ROM.
jim: your problem is not the same as mine. I would be happy
to merely have that problem. I tried using adjtimex 1.12-2 with
the same results. It is clearly a problem with the way the 8.0
kernels interacts with adjtimex. I certainly had no such
problem with 7.2 or 7.3. The closest I can get it in 8.0 is
off by 8 seconds every 5 minutes.
Yes, off by 22 minutes a day sounds about right.
My clock drift problem was resolved by updating by BIOS. But I still can't use
The rawhide adjtimex doesn't output "Invalid argument". At least not with the
latest FC4 kernel.