Red Hat Bugzilla – Bug 75599
adjtimex reports "Invalid argument" for some values of --tick
Last modified: 2013-07-02 18:57:21 EDT
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): How reproducible: Always Steps to Reproduce: 1. adjtimex --tick 10151 2. 3. Actual Results: adjtimex: Invalid argument Expected Results: Command accepted and time parameters adjusted Additional info: 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 adjtimex.
The rawhide adjtimex doesn't output "Invalid argument". At least not with the latest FC4 kernel.