LOL, I have been worrying about a non-problem for some years but did not bother me enough to take a deeper look, so today it nagged me to the point of looking into the docu.
When I put my machine to sleep, all VMs suspend time until it's awake again. The hardware clock of the host ticks while sleeping, but in all VMs the time is respectively lagging with the added sleep time.
I was wondering why doesn't NTPD update that as soon as they are awake..... until reading this today:
LOL, had I waited for 15 minutes before checking, I would never have noticed the time lag. Also, I never bothered to check a second time, I just called ntpdate manually.
Weird stuff, right?
When I put my machine to sleep, all VMs suspend time until it's awake again. The hardware clock of the host ticks while sleeping, but in all VMs the time is respectively lagging with the added sleep time.
I was wondering why doesn't NTPD update that as soon as they are awake..... until reading this today:
The ntpd algorithms discard sample offsets exceeding 128 ms, unless the interval during which no sample offset is less than 128 ms exceeds 900s. The first sample after that, no matter what the offset, steps the clock to the indicated time. In practice this reduces the false alarm rate where the clock is stepped in error to a vanishingly low incidence.
LOL, had I waited for 15 minutes before checking, I would never have noticed the time lag. Also, I never bothered to check a second time, I just called ntpdate manually.
Weird stuff, right?