Hello Karel,
On Wednesday, August 6, 2008 at 14:37:58 +0200, Karel Zak wrote:
> On Tue, Jul 15, 2008 at 03:34:42PM -0700, David Brownell wrote:
>> Capsule summary: absolutely nothing keeps the emulated RTC IRQs
>> (arch/x86/kernel/hpet.c) in phase with the real RTC.
> Does it mean that /sys/class/rtc/rtc0/settime_offset_ms is nonsense?
IMHO no, those are two different problems:
- The HPET emulated RTC interrupts are inaccurate by nature, and may
additionally suffer from bugs and misconfigurations (unsynchronized,
too early, or never coming interrupts). This affects all hwclock
operations, read and write, because this affects the detection of the
clock tick by the default method.
- The half second restart delay still exists, in the RTC, regardless of
the HPET faking interrupts above. This delay still has to be counted,
for people using --directisa, --nointerrupt, a kernel without bugs, with
"nohpet", or without IRQ emulation (??). And of course for people using
non-HPET machines.
Even outside of any bugs, HPET emulated RTC interrupts are inaccurate by
design, as they can delay the tick detection by a random amount anywhere
in the range between 0 and 15625 microseconds. I'd recommend "nohpet"
or --directisa to impacted people wanting normal accuracy. To know if
you're impacted, you can do several times:
| # hwclock --systohc; adjtimex --compare=1 | awk '/^[0-9]+/{printf "RTC phase offset: %+.0f usec\n", -$2 * 1e6; exit}'
| RTC phase offset: -4 usec
This number of microseconds is the offset of the RTC compared to system
time, measured one second after the setting, with the RTC drift since
then compensated. It should be small and quite constant, optimally
always less than 10 microseconds, as here, but up to -2700 ±200 µs at
worst. If it varies more widely, in a 15625 µs range, you're probably
impacted by HPET IRQs.
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
