Louis Lagendijk writes: : On Fri, 2007-12-28 at 15:23 -0800, Dean S. Messing wrote: : <summary> : adjtimex --utc --compare=20 --interval=10 : returns values of "system-cmos" that make it look like the RTC : is "jumping" : : Could this be caused by some funny resolution of the system time : delivered by the RTC to the OS? If it delivers time only in seconds, by : uses some strange divider internally, one could see this : behaviour..... : The RTC might still be accurate, but might vary upto one second from the : system clock. Hi Louis. This is an interesting idea. Do you know of an independent way to verify it? I guess I'm going to have to find some time (limited!) to read the kernel docs on /dev/rtc. If /dev/rtc only delivers time with 1 second granularity that would be mightly useless, I would think. One thing that may argue against your idea: each time I invoke adjtimex --utc --compare=20 --interval=X X can be _anything_ (I've tried 10, 13, 15, 20, 23, 60), but the delta between (system-cmos) from line to line is always almost exactly 0.1 seconds, until the "correction" occurs. By the way, I ruled out the possibility of the CMOS clock running grossly slow. Last evening I turned off `ntpd', hand set my system clock to freerun using adjtimex --tick 10001 --freq 3831728 which are the equivalent parameters that ntpd was using to drive the sytem clock when it was well-tuned. I also turned off the 11 minute kernel update to the RTC (with adjtimex -S 64 ) So both clock are free-running. In 12 hours or so my system clock has drifted from the "montpelier.ilan.caltech.edu" stratum 1 clock by only 23 ms (from -0.005 to 0.018) which is less than 1 ppm. On the other hand [root@medulla ~]# hwclock --show; date Sat 29 Dec 2007 12:04:10 PM PST -0.080610 seconds Sat Dec 29 12:04:09 PST 2007 so my RTC has deviated from system time by no more than 1 second. Indeed it appears be running slightly _fast_ not grossly slow. Dean
