| Re: [chrony-dev] Wake from sleep on OS X |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
On Tue, Dec 01, 2015 at 11:14:51AM +1300, Bryan Christianson wrote:
> When the machine wakes up I see syslog messages such as:
> Dec 1 00:00:28 number9 chronyd[3450]: Forward time jump detected!
> Dec 1 00:00:52 number9 chronyd[3450]: System clock wrong by 5.978007 seconds, adjustment started
> Dec 1 07:30:07 number9 chronyd[3450]: Forward time jump detected!
> Dec 1 07:30:31 number9 chronyd[3450]: System clock wrong by 6.672551 seconds, adjustment started
> Dec 1 08:10:13 number9 chronyd[3450]: Forward time jump detected!
> Dec 1 08:10:37 number9 chronyd[3450]: System clock wrong by 6.625014 seconds, adjustment started
>
> And then it can take a couple of minutes before the local offset converges to something less than a millisecond.
It looks like the RTC is off by 6 seconds. Is it not synchronized by
the kernel automatically?
> OS X has an API for getting notification of sleep/wake events so I was thinking of something like
>
> 1. Receive 'about to sleep' notification
> pause chronyd scheduler
> allow system to sleep
>
> 2. Receive 'has woken up' notification
> set T0 in the Mac driver to current gettimeofday()
> reinitialise drift correction interval to default
> any other book keeping chores required in the driver
The scheduler calls the parameter change handlers with
LCL_ChangeUnknownStep when the forward time jump is detected, so these
could be implemented in the driver with no additional changes if "has
woken up" could mean "time jump was detected". The sys_generic.c
driver is doing that.
> restart chronyd scheduler
> I'm not sure of the best approach to pausing/restarting the scheduler.
By pausing and restarting the scheduler you mean adding the interval
when the system was suspended to all timeouts, or something else?
> A new entry point that sets the state of the scheduler, then in SCH_MainLoop() poll the state at say 1 second intervals (doing nothing if in a sleeping state) would be one option
>
> Maybe a callback to the driver from the scheduler that performs a waitloop if the system is asleep before returning. I think this option means minimal change to the scheduler itself.
>
> What do you think about this?
It's not clear to me what the result should be. Faster detection of
the forward time jump, or faster adjustment of the clock when it's
detected?
--
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.