[ntp:questions] quirky adjtimex behaviour

Dean S. Messing deanm at sharplabs.com
Thu Jan 3 17:42:30 UTC 2008


First, apologies if this is the wrong list for this.
Please direct my to the right place if it is.

I am seeing strange behaviour on my _x86_64 Fedora 7 desktop
workstation with regard to the "system-cmos" time that `adjtimex'
reports.

Below is an illustration:

[root at medulla ~]# adjtimex --utc --compare=20 --interval=10
                                      --- current ---   -- suggested --
cmos time     system-cmos  error_ppm   tick      freq    tick      freq
1199380337       0.438974
1199380346       0.540422    10144.8  10001   3950000
1199380355       0.642382    10196.0  10001   3950000    9899   4212512
1199380364       0.744336    10195.4  10001   3950000    9899   4251575
1199380373       0.845293    10095.7  10001   3950000    9900   4230787
1199380382       0.946259    10096.6  10001   3950000    9900   4172975
1199380392       0.047206   -89905.3  10001   3950000   10900   4297975
1199380401       0.149166    10196.0  10001   3950000    9899   4210950
1199380410       0.251134    10196.8  10001   3950000    9899   4160950
1199380419       0.353096    10196.2  10001   3950000    9899   4198450
1199380428       0.455055    10195.9  10001   3950000    9899   4218762
1199380437       0.557004    10194.9  10001   3950000    9899   4284387
1199380446       0.658973    10196.9  10001   3950000    9899   4153137
1199380455       0.759925    10095.2  10001   3950000    9900   4265162
1199380464       0.860889    10096.4  10001   3950000    9900   4185475
1199380473       0.961848    10095.9  10001   3950000    9900   4218287
1199380483       0.063806   -89804.2  10001   3950000   10899   4225012
1199380492       0.165759    10195.3  10001   3950000    9899   4257825
1199380501       0.267719    10196.0  10001   3950000    9899   4212512
1199380510       0.369682    10196.3  10001   3950000    9899   4192200
[root at medulla ~]# 

As you can see, the system time appears to advance by almost exactly
0.1 seconds every 10 seconds relative to the RTC.  Then, just as they
are about to get out of phase by 1 second, something causes either the
system clock to "jump back" by ~1 second or the RTC to jump forward,
or so it appears.

Furthermore if I change --interval to something odd (like 17) the
delta from line to line remains about the same at 0.1 sec, which it
should not if there was a "real" slew occurring:

[root at medulla ~]# adjtimex --utc --compare=10 --interval=17
                                      --- current ---   -- suggested --
cmos time     system-cmos  error_ppm   tick      freq    tick      freq
1199380633       0.540237
1199380649       0.642055     5989.3  10001   3950000
1199380665       0.743996     5996.5  10001   3950000    9941   4177948
1199380681       0.845918     5995.4  10001   3950000    9941   4250558
1199380697       0.947846     5995.8  10001   3950000    9941   4227580
1199380714       0.048774   -52886.6  10001   3950000   10530   3070784
1199380730       0.150698     5995.5  10001   3950000    9941   4243205
1199380746       0.252637     5996.4  10001   3950000    9941   4185301
1199380762       0.354556     5995.2  10001   3950000    9941   4261588
1199380778       0.456482     5995.6  10001   3950000    9941   4235852


>From my investigations, the system time is _not_ 
advancing faster than UTC.  In fact:

root at medulla ~]# ntpdate -q  montpelier.ilan.caltech.edu
server 192.12.19.20, stratum 1, offset -0.001267, delay 0.05643
 3 Jan 09:24:28 ntpdate[18831]: adjust time server 192.12.19.20 offset -0.00126\
7 sec

so my system is currently about 1 ms ahead the Stratum 1 server,
"montpelier.ilan.caltech.edu".

This offset is nearly constant over several minutes. Also, if I
execute the command at several random times over the period of a
minute, the offset only fluctuates by 1/2 a ms or so.  

Conclusion: my system clock is not jumping around.

That leaves the RTC doing the jumping.  But having an RTC that is
runing nearly 10000 ppm slower than my system clock and which "jumps
ahead" every 10 seconds seems absurd.

In fact two results seem to prove that the RTC is running smoothly:

-- If I look at the seconds digit changing w/in the desktop BIOS (pre-boot)
   it do not change its relative phase w.r.t. the displayed system
   clock on my laptop screen as I hold the latter next to the BIOS clock.
   (A 10% second retard would be quite visible, as would the jump.

-- The "delta" from line to line in the `adjtimex' output remains
   at ~0.1 no matter the --inverval used.  This shd. not be the case
   if there was a true slew between the system clcok and RTC.

It seems that leaves two other possibilities: a bug in adjtimex or a
bug in the kernel.  That's where I am right now.

For reference here's a few lines of output from the laptop (running
Fedora 6, kernel 2.6.20, and being an i386 32-bit machine):

[root at axon ~]# adjtimex --utc --compare=20 --interval=17
                                      --- current ---   -- suggested --
cmos time     system-cmos  error_ppm   tick      freq    tick      freq
1199326863     0.001312
1199326880     0.001481        9.9  10000   -633968
1199326897     0.001531        2.9  10000   -633968    9999   5727380
1199326914     0.001423       -6.3  10000   -633968    9999   6333079
1199326931     0.001346       -4.5  10000   -633968    9999   6217269

Quite normal behaviour!

I have no idea what's happening on my F7 system to cause the strange
behaviour.  I hoping one of you does.

Some system specifics:

Machine: Dell Precision 490 with 2 dual-core processors.
Kernel:  Linux 2.6.23.8-34.fc7 x86_64

Machine was un-loaded during the tests.

RTC is set to UTC

`rpm -q adjtimex' gives:   adjtimex-1.21-2.fc7.x86_64
Note: I've also compiled and tried version 1-23 with the same results.

The output of adjtimex -p is:

[root at medulla ~]# adjtimex -p
         mode: 0
       offset: -258
    frequency: 3950000
     maxerror: 2936955
     esterror: 861
       status: 64
time_constant: 7
    precision: 1
    tolerance: 33554432
         tick: 10001
     raw time:  1199381203s 842990us = 1199381203.842990
 return value = 5


In getting the above data, the system clock is "free-running"
in order to check its behaviour. (ntpd off)

The tick and frequency were hand-set after a couple of days running
`ntpd' and examining the drift and other paramters.  (I rounded
freq. slightly because I like round numbers :-)

The same behaviour occurs when the system clock is under the control
of `ntpd'.

Also the RTC is "free-running".   That is, "11-minute mode" is off as
indicated by the status flag in the output of `adjtimex -p'.

If I can provide any other information to help diagnose this
behaviour, I'll be more than happy to do so.

Thanks for you help!

Dean



More information about the questions mailing list