> The offset needs to be sufficient to handle the case of the RTC being
> set to local time and the boot and first ntp sync occurring on opposite
> sides of a Daylight Savings Time change. A couple of timezones use a DST
> offset of 90 minutes, so if it's less than that, there will be problems.
There is a related problem, where if you are running something which
can suspend, like a laptop, but not using integrated apm to do it (for
instance a laptop which has a broken BIOS), then suspending 'freezes'
the system time, which is wrong on resume (as the power management
event appears to be invisible to Linux). Then this goes and blats
over the (correct) RTC time. If you then get a network connection up,
ntp won't adjust the time as it's too far out. What I wanted was
an option which did the copy the other way on a large offset - i.e.
keep the RTC in sync for smallish offsets, but if the offset is
wrong by more than 5 minutes (and RTC is in advance), copy RTC to
system time as the laptop probably suspended. There might of course
be a better hueristic to detect this (perhaps every time it does
the check see if it got out of sync by > the interval between
checks). Short of this, it would be useful to be able to turn /off/
futzing with the rtc.
-- Alex Bligh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/