On Monday, June 16, 2008 at 11:25:46 -0700, David Brownell wrote: > there should probably be a way to export a list of hardware "features" > (and misfeatures) of which that would be one Much thanks for your valuable input, Dave. That's actually an excellent idea, matching some of mines. > or at least to identify the RTC hardware through /dev operations. But then the knoweledge about the behaviour of each RTC type would have to be included into hwclock (and into each RTC-writing app), instead of into the corresponding driver. Workable, but somewhat less logical. >> All(?) RTC-setting apps work well out-of-the-box unmodified. > Busybox "hwclock" sure doesn't. Busybox is maybe not a totally appropriate example, because it makes no attempt to be precise besides the second granularity. IINM busybox version 1.10.1 doesn't care about restart delay or not, and doesn't care about any good moment to set the clock, neither S.0 nor S.5. It just calls RTC_SET_TIME immediatly. The result is that the RTC ends with: - A maximum error of one full second, RTC offset in the range -1 to 0, in case the RTC restarts immediatly. - A maximum error of 0.5 seconds, RTC offset in the range -0.5 to +0.5, in case either the RTC or its driver do the half second restart delay. This twice better "accuracy" probably justifies the inclusion of such restart delay by hardware designers 20 years ago. And pushes busybox into the pro-mimic camp. > Does anything other than the util-linux(-ng) "hwclock" know about > this quirk of the PC RTC? - The mainline hwclock 2.33 by BJH at <URL:http://giraffe-data.com/software/about_hwclock.html> manages half-second RTCs by default. The user of another RTC may get perfect results with the --correct=+0.5 option (or --correct=+0.495 on RTCs having 10 ms of non-resyncable granularity). - IINM the eleven-minutes mode of the Linux kernel, last time I looked, was scheduling the RTC write for the timer interrupt occuring at the closest to the middle of the second. - Chrony 1.23 has a rather complicated "trimrtc" procedure, that will automatically adapt to whatever restart delay or not (by picking several verification ticks after the RTC_SET_TIME). >> Applications timestamping the first tick following RTC_SET_TIME for >> verification > I'm trying to understand what, other than hwclock or a replacement > for it, would ever do that. As example I use wrapper scripts around hwclock doing that, in order to gather stats and syslog things like: | Jun 17 01:09:09 hwclockset: CMOS clock set: Residual error +0.000068 s, virtual error -0.000002 s. Drift calculated -11.925593 reset to previous -11.870000. Was last set 17618 seconds ago (4:53:38). > Drawbacks of adding that requirement to drivers: Also I suppose that there could exist an RTC without restart delay, but without hundredth to be set to 50, nor other quick and easy trick to mimic a restart delay. Alain. -- To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
