On 07/03/14 16:33, Miroslav Lichvar wrote: > So it seems it selected the source pretty quickly after the jump was > detected. So the problem is that it took too long to detect it? Do > you know at what time you issued the sources command?
I have a "chronytop" "realtime monitor" (using the term loosely here ;), with "watch" issuing various statistics calls every two seconds. I started it immediately after waking up and observed, mostly to see how quickly chrony would start polling again. > There is a difference in how are the scheduled timers corrected when > chronyd reaches a timeout (select() returning 0) and when an > external request (e.g. chronyc command) wakes it up. > > When it doesn't timeout, all scheduled timers are moved by the > interval between last select() call and the current time. This means > if a chronyc command is issued before chronyd timeouts, the actual > time it takes to send first request after suspend could be up to > 2*maxpoll. Oh! That might explain why I didn't observe it sooner and kicked it. Anyway, I'll just give it a few tries again over the next few days without post-wakeup nudge, since the expected behaviour should eventually happen (and apparently eventually does). So that's good. > Running chronyc offline before suspend and chronyc online after > resume should work too. That's what happens with the NetworkManager > dispatcher script in Fedora. That's a good idea! I might try that. cheers Holger -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.