On Thu, Dec 3, 2009 at 12:59 AM, Mike Connors <[email protected]> wrote: > Denis Heidtmann wrote: >> Data: ntpdate runs during boot and logs an offset of something from >> .3 to .9 seconds. A short time after boot runing ntpdate from the >> command line reports an offset of .00##--something close to zero. >> Shutdown and reboot shortly later, ntpdate runs during boot and logs >> an offset of something from .3 to .9 seconds. Repeat as desired. >> >> I take this to mean that 1) the hardware clock was not synchronized >> better than 1 second on shutdown, or 2) the hardware clock gets bumped >> during the shutdown/reboot cycle, or 3) the hardware clock is unstable >> in the extreme, or 4) the system clock gets set to the rtc to within 1 >> second on boot. 1) and 4) seem to me to be effectively the same >> thing. >> >> I vote for 4), because I find in the logs: >> Dec 2 17:58:46 R2D4 kernel: [ 3.906800] rtc_cmos 00:08: setting >> system clock to 2009-12-03 01:58:34 UTC (1259805514) >> >> If it were set more accurately than the nearest second why would it >> not show in the log? > Why wouldn't the output from the NTPDATE command be close to zero shortly > after ntpdate just adjusted the system clock to an ntp server? It's a > highly accurate clock source and the system clock doesn't drift as much as > the hwclock. > > If you don't believe the hwclock is unstable, just run the "hwclock" > command a few times in a row and you'll see the drift: > > r...@mc-goose:/var/log# hwclock > Wed 02 Dec 2009 11:22:27 PM PST -0.859939 seconds > r...@mc-goose:/var/log# hwclock > Wed 02 Dec 2009 11:22:28 PM PST -0.094328 seconds > r...@mc-goose:/var/log# hwclock > Wed 02 Dec 2009 11:22:30 PM PST -0.719333 seconds > r...@mc-goose:/var/log# hwclock > Wed 02 Dec 2009 11:22:31 PM PST -0.281826 seconds > r...@mc-goose:/var/log# hwclock > Wed 02 Dec 2009 11:22:33 PM PST -0.625572 seconds > > > The System Time is the time that matters. The hwclock's purpose > is to keep time when Linux is not running. The System Time is initialized by > the time from the hwclock when Linux starts up, and then never use the > hwclock again. > > > Here's some debug output that shows hwclock after > reboot: > > r...@mc-goose:~# hwclock -D > hwclock from util-linux-ng 2.16.1 > Using /dev interface to clock. > Last drift adjustment done at 1259827578 seconds after 1969 > Last calibration done at 1259827578 seconds after 1969 > Hardware clock is on local time > Assuming hardware clock is kept in local time. > Waiting for clock tick... > ...got clock tick > Time read from Hardware Clock: 2009/12/03 00:08:18 > Hw clock time : 2009/12/03 00:08:18 = 1259827698 seconds since 1969 > Thu 03 Dec 2009 12:08:18 AM PST -0.666495 seconds > > I did find some info that the hwclock doesn't make adjustments for > drift < 1 sec. > > "A small amount of error creeps in any time hwclock sets the clock, so > it refrains from making an adjustment that would be less than 1 second. > Later on, when you request an adjustment again, the accumulated drift > will be more than a second and hwclock will do the adjustment then. > > It is good to do a hwclock --adjust just before the hwclock --hctosys > at system startup time, and maybe periodically while the system is run- > ning via cron. > > The adjtime file, while named for its historical purpose of controlling > adjustments only, actually contains other information for use by > hwclock in remembering information from one invocation to the next." > This is very interesting. But I do not think that the "-0.nnnnnn seconds" numbers represents random noise in the Hardware Clock's time-keeping. The man page does not explain what that final number means, but I think it is a refinement of the displayed time--the displayed time is only to the nearest second. I cannot believe that a quartz crystal oscillator could have deviations in the order of a second over a time of a few seconds. Another test shows something a little different:
sudo hwclock --show ; sudo hwclock --show; sudo hwclock; sudo hwclock --show Thu 03 Dec 2009 09:52:59 AM PST -0.347595 seconds Thu 03 Dec 2009 09:53:00 AM PST -0.987145 seconds Thu 03 Dec 2009 09:53:01 AM PST -0.987157 seconds Thu 03 Dec 2009 09:53:02 AM PST -0.985207 seconds Notice that when the time of invocation of the command is predictable, the seconds are stable to the order of 0.002 seconds. I believe the offset displayed by ntpdate is due to hwclock not making adjustments < 1 second, as you pointed out. For my system, since I run ntpdate at boot, and I boot at least every day, I should be fine. if I wanted to determine the drift of my rtc, I would stop running ntpdate at boot for a week or more, then check to see how far the rtc had drifted. My suspicion is that it is reasonable, since only recently have I gotten ntpdate to run at boot. I noticed the problem when the clock was off by about 5 minutes after 6 months. -Denis _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
