![](https://seccdn.libravatar.org/avatar/77cb4da5f72bc176182dcc33f03a18f3.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2007-12-12 at 09:54 -0800, Linda Walsh wrote:
Interesting -- using same version of "hwclock" & same kernel version, I compared 3 machines: one machine averaged around -0.988xxx, another -0.991xxx and a third at -0.0003xx. (the xxx digits are variable, the listed digits were mostly fixed values after the loop start).
Their HW varies considerably, the first two about 5-6 years old, the latter more recent. I wonder why they cluster like they do -- the first two around -1, and the newer one nearer 0.
I don't :-P They cluster because you are requesting the data in a programming loop, with a delay that is an integer number of seconds. Do a delay loop with a random number of a fraction of 1 second, and you will see the numbers come out equally random. Or do it manually (see below). Proof: nimrodel:~ # time hwclock --show ; date Wed Dec 12 21:09:03 2007 -0.275262 seconds real 0m0.284s <===== user 0m0.000s sys 0m0.000s Wed Dec 12 21:09:03 CET 2007 nimrodel:~ # time hwclock --show ; date Wed Dec 12 21:09:09 2007 -0.500613 seconds real 0m0.506s <===== user 0m0.003s sys 0m0.003s Wed Dec 12 21:09:09 CET 2007 See how the "real" time used by the command is curiously similar to the offset seconds of the hwclock command? Because hwclock simply waits that long before exiting, and exits at the exact moment the seconds is XX.00, reporting that time it waits as an offset. The offset is /not/ the offset between the cmos clock and the system clock...
Curious...
Satisfied, I hope ;-) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHYEEstTMYHG2NR9URAiXcAKCIiA331Jfx2OcpMwhcOc4dueQ7fACfYkcj 8vooJF8vGDHripd2YRuYx5U= =6kEL -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org