Re: [chrony-dev] Wake from sleep on OS X

[Miroslav Lichvar <mlichvar@xxxxxxxxxx>]

On Wed, Dec 02, 2015 at 02:31:24PM +1300, Bryan Christianson wrote:
> These methods will eventually issue a settimeofday() system call. I had a look in the OS X kernel and settimeofday() seems to be the only exported mechanism for updating the hardware clock.

Interesting. I guess on other systems it could be the same. I remember
when I was reworking the system drivers in the previous release to use
ntp_adjtime(), I was not able to find out much information on how the
systems work with the RTC and it looked like clearing the STA_UNSYNC
flag in the ntp_adjtime() status didn't do anything with the RTC, so
unlike on Linux, it's cleared even when the rtcsync option is not set.

> I think the best option is periodic updates from chronyd via the settimeofday() system call. Nothing else is setting the h/ware clock and since it seems as tho rtc recovery is not supported, settimeofday() wouldn't be trading on anyones toes.

I think for the rtcsync option that would be a reasonable thing to do. 

I'm just worried the gettimeofday()+settimeofday() call will step
the system clock too much. IIRC, "chronyc makestep" was surprisingly
inaccurate on some of the systems we support. I think I saw errors in
tens of milliseconds, maybe that's because the system call also sets
the RTC? Anyway, if it was documented as a drawback of the rtcsync
option, I think that would be ok.

As for the settimeofday() update interval, I think that should
correspond to the precision of how the kernel sets and reads the
RTC. If it just reads seconds and doesn't wait for the interrupt
(assuming it's not some special RTC with a sub-second counter), the
update interval could be probably much longer than 15 minutes.

-- 
Miroslav Lichvar

-- 
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.