On: Is Redlock Safe? Reply to Redlock Analysis

[xorcist]

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 → xorcist]

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.

[Dylan16807 → dsp1234]

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.

[SrslyJosh → dsp1234]

> 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.

[baruch → xorcist]

> 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.