Bug 75599 - adjtimex reports "Invalid argument" for some values of --tick
Summary: adjtimex reports "Invalid argument" for some values of --tick
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: adjtimex   
(Show other bugs)
Version: 8.0
Hardware: i686 Linux
Target Milestone: ---
Assignee: Jindrich Novy
QA Contact: Mike McLean
Depends On:
TreeView+ depends on / blocked
Reported: 2002-10-10 03:25 UTC by Neal Gafter
Modified: 2013-07-02 22:57 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-08 14:22:43 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Neal Gafter 2002-10-10 03:25:46 UTC
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:

Steps to Reproduce:
1. adjtimex --tick 10151

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.

Comment 1 Neal Gafter 2002-10-10 03:48:14 UTC
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.

Comment 2 Yaron Minsky 2002-10-11 12:23:32 UTC
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.

Comment 3 Neal Gafter 2002-10-15 04:24:30 UTC
No tick value in the new valid range gets my clock better than 2% slow.

Comment 4 Need Real Name 2002-12-05 09:18:28 UTC
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?

Comment 5 jim 2003-02-25 04:52:58 UTC
    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.

Comment 6 jim 2003-02-26 04:41:16 UTC
    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.

Comment 7 Neal Gafter 2003-02-27 06:33:42 UTC
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.

Comment 8 Neal Gafter 2003-02-27 06:35:19 UTC
Yes, off by 22 minutes a day sounds about right.

Comment 9 Neal Gafter 2003-10-15 19:31:30 UTC
My clock drift problem was resolved by updating by BIOS.  But I still can't use

Comment 10 Jindrich Novy 2005-09-08 14:22:43 UTC
The rawhide adjtimex doesn't output "Invalid argument". At least not with the
latest FC4 kernel.

Note You need to log in before you can comment on or make changes to this bug.