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: [EMAIL PROTECTED] ~]# 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 [EMAIL PROTECTED] ~]# 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: [EMAIL PROTECTED] ~]# 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: [EMAIL PROTECTED] ~]# 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): [EMAIL PROTECTED] ~]# 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: [EMAIL PROTECTED] ~]# 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 _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions