4 ms·

This is what puzzles me - while time drift does occur, it tends to be in the form of minor errors which build up over time; large jumps are relatively rare. You

This is what puzzles me - while time drift does occur, it tends to be in the form of minor errors which build up over time; large jumps are relatively rare. You'd think the mechanism described in the article would have a failsafe ensuring that only minor time recalibrations are performed.

toast0 3y ago
It kind of depends. There's a lot of poor clocks at boot up time, but a continuously running host usually doesn't get too off, too quickly; I've seen some things, but even at 10% fast/slow, you don't have to jump days unless you're checking infrequently. On the other hand, with virtualization, who knows how long it's really been between clock ticks. Let's say someone suspends a VM for a couple months and then unsuspends it; hopefully the clock is synchronized, but maybe it isn't, and you do need to jump ahead. I thought I saw in the article that there are failsafes, but the allowed range is still pretty broad. But reporting is going to tend to be dominated by larger values, because smalller jumps are less likely to be noticed or more likely to be considered an accidental change.
- Wowfunhappy 3y ago
  Every VM software I've ever used automatically syncs the guest OS's clock to the host OS's clock. I've never used VMs in a server context, but do servers not do this too? It seems like the logical solution here.
  - toast0 3y ago
    I've certainly had issues with time sync in the past, and Windows has a wide range of deployment, so I would imagine they can't rely on it.
HPsquared 3y ago
There are a lot of machines out there with a dead battery on the real time clock. Every time they boot, the time is miles out and at some system-determined zero point.
- magicalhippo 3y ago
  Imagine one could make an approximate clock that does not rely on batteries or similar things that can expire. How close would it need to be to the actual time to be useful? Does it have to be within a day, or could it be within a week or a month?

toast0 3y ago

It kind of depends. There's a lot of poor clocks at boot up time, but a continuously running host usually doesn't get too off, too quickly; I've seen some things, but even at 10% fast/slow, you don't have to jump days unless you're checking infrequently. On the other hand, with virtualization, who knows how long it's really been between clock ticks. Let's say someone suspends a VM for a couple months and then unsuspends it; hopefully the clock is synchronized, but maybe it isn't, and you do need to jump ahead. I thought I saw in the article that there are failsafes, but the allowed range is still pretty broad. But reporting is going to tend to be dominated by larger values, because smalller jumps are less likely to be noticed or more likely to be considered an accidental change.

Wowfunhappy 3y ago
Every VM software I've ever used automatically syncs the guest OS's clock to the host OS's clock. I've never used VMs in a server context, but do servers not do this too? It seems like the logical solution here.
- toast0 3y ago
  I've certainly had issues with time sync in the past, and Windows has a wide range of deployment, so I would imagine they can't rely on it.

HPsquared 3y ago

There are a lot of machines out there with a dead battery on the real time clock. Every time they boot, the time is miles out and at some system-determined zero point.

magicalhippo 3y ago
Imagine one could make an approximate clock that does not rely on batteries or similar things that can expire. How close would it need to be to the actual time to be useful? Does it have to be within a day, or could it be within a week or a month?