[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