4 ms·

Distributed time is tricky, but it depends on what the intended use is. Under normal operation it will only move forward, for example. > VM live migration "pau

by xorcist 11y ago

Distributed time is tricky, but it depends on what the intended use is. Under normal operation it will only move forward, for example. > VM live migration "pause"? System clock will take a larger step than usual. It won't go backwards. > daylight savings change? None. System clock is UTC for a reason. > ntp updates which change the time? NTP only drifts the clock (under normal operation).

dsp1234 11y ago
Not that I think it effects your point, but just off the top of my head: System clock will take a larger step than usual. It won't go backwards. Assumes that checkpoint and restore to a previous time won't happen. NTP only drifts the clock (under normal operation). Unless it's a system like this. Note that this was pulled at about 1pm EST. Waiting for clock tick... ...got clock tick Time read from Hardware Clock: 2016/02/09 22:36:50 Hw clock time : 2016/02/09 22:36:50 = 1455057410 seconds since 1969 Tue 09 Feb 2016 02:36:50 PM PST -1.038948 seconds Under normal operation it will only move forward 'Under normal operation' is not really a high bar for distributed systems. After all, the network is reliable 'under normal operation' too.
- SrslyJosh 11y ago
  > Assumes that checkpoint and restore to a previous time won't happen. Or migration to a host whose clock is behind the original host's clock.
- Dylan16807 11y ago
  Use CLOCK_MONOTONIC. Or you could make your client abort when the clock goes backwards. If someone forks a VM from a running snapshot, you're screwed whether they mess with the clock or not.
baruch 11y ago
> NTP only drifts the clock (under normal operation). That shouldn't be an assumption. NTP may jump the clock if the difference is too high, I've had it once that a system was connected to two different NTP servers and they each had a different clock and the system would jump the clock every now and then based on what NTP server it though was more correct.

by xorcist 11y ago

dsp1234 11y ago

Not that I think it effects your point, but just off the top of my head: System clock will take a larger step than usual. It won't go backwards. Assumes that checkpoint and restore to a previous time won't happen. NTP only drifts the clock (under normal operation). Unless it's a system like this. Note that this was pulled at about 1pm EST. Waiting for clock tick... ...got clock tick Time read from Hardware Clock: 2016/02/09 22:36:50 Hw clock time : 2016/02/09 22:36:50 = 1455057410 seconds since 1969 Tue 09 Feb 2016 02:36:50 PM PST -1.038948 seconds Under normal operation it will only move forward 'Under normal operation' is not really a high bar for distributed systems. After all, the network is reliable 'under normal operation' too.

SrslyJosh 11y ago
> Assumes that checkpoint and restore to a previous time won't happen. Or migration to a host whose clock is behind the original host's clock.
Dylan16807 11y ago
Use CLOCK_MONOTONIC. Or you could make your client abort when the clock goes backwards. If someone forks a VM from a running snapshot, you're screwed whether they mess with the clock or not.

baruch 11y ago

> NTP only drifts the clock (under normal operation). That shouldn't be an assumption. NTP may jump the clock if the difference is too high, I've had it once that a system was connected to two different NTP servers and they each had a different clock and the system would jump the clock every now and then based on what NTP server it though was more correct.