William Unruh wrote:
incorporated into ntpd. I like chrony's ease of using intermittent time sources and also its disciplining of the rtc as well as the system clock, although it is not as useful as it could be since the rtc is greatest use when the computer is shut off and cold, while the estimate of it drift rate is done while it is running and hot. Are there any ideas as to how that could be better done than it is in chrony?
That one is pretty obvious: I wrote code around 1985 or so which sampled the CMOS clock with one-day intervals (using a dial-up time source as my reference).
After just 24 hours (i.e. with two samples) I let it free-run for a week, when I tried again I found that the eventual offset was around 0.1 second, which might have been partly luck, but definitely a huge improvement.
For an RTC improved estimate I would use the last sample (i.e. the last time the current system clock was written back to the rtc, something that usually happens once per hour, and then check the first external sync after system restart: At this point the system clock will be rtc based and the measured offset divided by the time since the last rtc update is a good estimate of the rtc drift rate.
Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching" _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
