Also, clocks are often not monotonic. For NTP, if the drift is > 128ms it will just yank the time in whatever direction is necessary to correct. https://github.com/ntp-project/ntp/blob/stable/parseutil/dcfd.c#L1059
Experimentally, if you run various system-local time functions, you will often get values that jump backwards as well.
run this Go on OSX and you’ll occasionally hit values less than zero: time.Since(time.Now()) (linux, freebsd have been monotonic since 1.3)
There are certain local time functions in various languages that allow you to specify monotonicity, and if this is a requirement make sure you take advantage of them!
Monotonicity is especially for benchmarking. I didn’t think it would be that much of an issue for short benchmarks until one of my histograms had a few trials taking negative time.
Depending on the sensitivity, you may want to be even more specific for linux. NTP can cause time functions relying on CLOCK_MONOTONIC to speed up or slow down, but when using CLOCK_MONOTONIC_RAW it will avoid NTP-related rate fluctuations.
Backwards jumps only happen if ntp is set to step and not slew (-x to ntpd). If its slewing the system clock will be adjusted up/down as needed but never go backwards.
That is true only if the skew is less than 500 ppm however. To change this on OS X you’ll need to modify /usr/libexec/ntpd-wrapper and the ntp launchd entry. Which is a bit harder to do with 10.11 and SIP.
I had severe clock skew on one of my home machines.
On the plus side it meant I won all the uptime comparisons with my friends.
“Ten years uptime, baby!”
“…You just bought that server last month.”
“What’s your point?”
My understanding is that google has systems that rely on timestamps with extremely exact bounds. So the truetime API will guarantee that the true timestamp doesn’t lie outside some certain range. I’m not even close to an expert in this area, but it seems like google basically does build systems that can function with the assumption that “A clock is within X duration of another clock”.
You’re thinking of Spanner.
I think truetime is the time API spanner uses. “The key enabler of these properties is a new TrueTime
API and its implementation. The API directly exposes
clock uncertainty, and the guarantees on Spanner’s timestamps
depend on the bounds that the implementation provides”
link to pdf
I found this in the comments section of HN somewhere, although I haven’t read it yet, but seems interesting.
When I joined this place I found that an accidental firewall rule had blocked access to NTP and some machines' (luckily not in live) clocks were out by hours.