Hello David, gentlemen, On Wednesday, April 30, 2008 at 0:50:50 -0700, David Brownell wrote: > One issue is a mechanism that's specific to the PC/AT clone RTCs: > waiting for "exactly" 1/2 second after the clock rolls over before > setting the clock, since those RTCs wait a half second. If someone > has time to work such issues: that 1/2 second delay [...] should not > be required, since most RTCs don't have those PC/AT semantics. Those clone RTCs were historically close to monopolistic in Linux boxes of various arches, and are still some vast majority. When one sets them to a given second, they restart ticking half a second later to the next one, second+1. So the good moment to set them is indeed second.5 in system time. Applications setting the RTC know that, and (hopefully) do the right thing. This includes hwclock, and the kernel's own eleven-minutes mode. For other RTCs, shouldn't the device driver mimic such half second restart delay? This is possible easely for the Digi ns9215 RTC that Uwe is taming. The driver code below ioctl(RTC_SET_TIME) could set the hundredths of second value to 50. This RTC would then also tick half a second later to the next second, just like the usual PC clone RTCs. That is Uwe's briliant idea; I'm seeking arguments for/against it. Given that waiting for the next occurence in system time of second.0 or of second.5 takes statistically the same time (between 0 and 1 second), so far I can see only advantages: - ioctl(RTC_SET_TIME) behaviour consistent across different RTCs. - All(?) RTC-setting apps work well out-of-the-box unmodified. - Applications timestamping the first tick following RTC_SET_TIME for verification will have to wait half a second only, instead of a full second. I could imagine no potential drawback in setting HSEC=50, nor find any practical advantage in doing otherwise. What do you think about this? 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
