On Thu, Jul 03, 2014 at 03:18:57PM +0200, Holger Hoffstätte wrote: > Indeed - from this morning's wakeup, after sleeping overnight: > > Jul 3 09:18:39 hho chronyd[28177]: Forward time jump detected! > Jul 3 09:18:39 hho chronyd[28177]: Can't synchronise: no reachable sources > Jul 3 09:19:19 hho chronyd[28177]: Selected source 192.168.100.222
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 don't remember how long I waited for it to restart polling before kicking > it, but I'm sure it was >> 2*minpoll. 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. I think this could be improved by resetting the NTP tx timeouts when a time jump is detected, but the detection itself would still take up to one maxpoll. > Other than this it's working fine, so no drama. For now I can add a > post-wakeup script to kick it into gear with a few bursts. If you have any > ideas I can gladly try patches/build from git if that would help. Running chronyc offline before suspend and chronyc online after resume should work too. That's what happens with the NetworkManager dispatcher script in Fedora. I'm wondering if there should be new suspend and resume commands added to chronyc for this case. -- Miroslav Lichvar -- 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.