4 ms·

Somewhat off topic, but in the referenced Google blog describing their leap smearing technique, they say that their correction factor is "lie(t) = (1.0 - cos(pi

Somewhat off topic, but in the referenced Google blog describing their leap smearing technique, they say that their correction factor is "lie(t) = (1.0 - cos(pi * t / w)) / 2.0" (where w is the length of time over which they are smearing). Does anyone know why they do not just do a linear correction?

plantain 11y ago
It is linear now - see http://googlecloudplatform.blogspot.com.au/2015/05/Got-a-second-A-leap-second-that-is-Be-ready-for-June-30th.html http://googlecloudplatform.blogspot.com.au/2015/05/Got-a-sec...
- DougMerritt 11y ago
  That page doesn't say that it's linear, and the page that it links that gives the precise method shows that it's not at all linear.
  - plantain 11y ago
    "During a 20-hour “smear window” centered on the leap second, we slightly slow all our servers’ system clocks (by approximately 14 parts per million). At the end of the smear window, the entire leap second has been added, and we are back in sync with civil time. (This method is a little simpler than the leap second handling we posted back in 2011. The outcome is the same: no time discontinuities.)" From the article.
    - DougMerritt 11y ago
      I can see how that sounds like a linear adjustment, but you missed the key explanation. Going back two sentences before the part you quoted, we find: > We have a clever way of handling leap seconds that we posted [1] about back in 2011. Instead of repeating a second, we “smear” away the extra second. During a 20-hour “smear window” centered on the leap second... [1] http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html http://googleblog.blogspot.com/2011/09/time-technology-and-l... ...which says: > ...modulating this “lie” over a time window w before midnight: > lie(t) = (1.0 - cos(pi * t / w)) / 2.0 That's the nonlinear smear that we [2] are referring to. [2] see surrounding comments here on YC that agree that it is nonlinear. Note that this is extremely similar to the various kinds of data weighting "windows" (Hamming etc.) that are necessarily used with the Fast Fourier Transform. (Except that with those it is often undesirable for the window edges to go all the way to zero, and yet that is exactly what is desired for the time adjustment) And in both, it is for what amounts to the same mathematical issues: to avoid discontinuities, in either the function or its derivatives, that give rise to undesirable artifacts.
      - cnvogel 11y ago
        > And in both, it is for what amounts to the same > mathematical issues: to avoid discontinuities, in > either the function or its derivatives, that give > rise to undesirable artifacts. My guess is that with the cos/sin modulation the time can be precisely followed by a stock ntp client that doesn't know anything about "google time" and needs some time to ramp up/down the observed clock drift, as you said: Because the derivative doesn't jump. But if you deploy special ntp servers that know about your exact method of leap-second handling (as, I suppose, google does on all servers which are sensitive to sub-second time offsets) you don't need a steady derivative: you just set adjtimex(freq-14PPM) at -10 hours before the leap second and adjtimex(freq+14PPM) at the end. And this will lead to even tighter timing, as the percieved frequency offset (from the point of view of an NTP daemon doing time interval measurements relative to a server) will disappear completely. So maybe that's why they now use a simpler method? The other explanation I could think of for introducing this simpler handling is that google may have switched to PTP on their networks: As the measurement precision is much higher (jitter much lower) than UDP based ntp even a simple NTP client will be able to quickly and precisely follow the discontinuous clock drift at the beginning and end of the smearing period. Just for illustration purposes, here's aplot of the "google lie" clock offset going from 0...1 (cos...), and the modulation of the clock frequency (sin): http://www.wolframalpha.com/input/?i=plot+%281.0+-+cos%28pi+*+t%29%29+%2F+2.0+and++sin%28pi+*+t%29+from+0+to+1 http://www.wolframalpha.com/input/?i=plot+%281.0+-+cos%28pi+...
  - xfs 11y ago
    It is now http://people.ntp.org/burnicki/leap-second-2015-06-30/time1.google.com-216.239.32.15.png http://people.ntp.org/burnicki/leap-second-2015-06-30/time1....
flashman 11y ago
There was a discussion about HOW it works, but not WHY they chose that method: http://stackoverflow.com/questions/11279992/math-behind-google-leap-second-smear-formula http://stackoverflow.com/questions/11279992/math-behind-goog... My guess is they wanted time to deviate less at the start of the smear window, instead of deviating equally at all points during the window. But perhaps it turned out not to be an issue.
- davidcuddeback 11y ago
  My guess is that they wanted to avoid a discontinuity in the time's derivative. At t=0 and t=w, lie'(t)=0, so the clock is smoothly transitioned into and out of a faster rate.
thrownaway2424 11y ago
I'm guessing: that function has a continuous derivative. Simply running the clock uniformly faster during the interval would have a discontinuous derivative.
yonran 11y ago
If it were just linear like AWS (https://news.ycombinator.com/item?id=9567761 https://news.ycombinator.com/item?id=9567761), then an NTP client pointed to a smearing NTP server will have an immediate 12ppm drift discontinuity (NTP continually models the hardware clock as a fast or slow clock with a linear drift from true time). Perhaps the NTP client’s control algorithm will bounce around as it tries to figure out the correct hardware clock drift, and perhaps this bounce is smoother when you use cos over a day. But I haven’t studied the NTP algorithm enough to tell for sure. Edit: from other comments here, it looks like Google also uses a linear smear now (a linear drift over 20 hours is 14ppm).

plantain 11y ago

It is linear now - see http://googlecloudplatform.blogspot.com.au/2015/05/Got-a-second-A-leap-second-that-is-Be-ready-for-June-30th.html http://googlecloudplatform.blogspot.com.au/2015/05/Got-a-sec...

DougMerritt 11y ago
That page doesn't say that it's linear, and the page that it links that gives the precise method shows that it's not at all linear.
- plantain 11y ago
  "During a 20-hour “smear window” centered on the leap second, we slightly slow all our servers’ system clocks (by approximately 14 parts per million). At the end of the smear window, the entire leap second has been added, and we are back in sync with civil time. (This method is a little simpler than the leap second handling we posted back in 2011. The outcome is the same: no time discontinuities.)" From the article.
  - DougMerritt 11y ago
    I can see how that sounds like a linear adjustment, but you missed the key explanation. Going back two sentences before the part you quoted, we find: > We have a clever way of handling leap seconds that we posted [1] about back in 2011. Instead of repeating a second, we “smear” away the extra second. During a 20-hour “smear window” centered on the leap second... [1] http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html http://googleblog.blogspot.com/2011/09/time-technology-and-l... ...which says: > ...modulating this “lie” over a time window w before midnight: > lie(t) = (1.0 - cos(pi * t / w)) / 2.0 That's the nonlinear smear that we [2] are referring to. [2] see surrounding comments here on YC that agree that it is nonlinear. Note that this is extremely similar to the various kinds of data weighting "windows" (Hamming etc.) that are necessarily used with the Fast Fourier Transform. (Except that with those it is often undesirable for the window edges to go all the way to zero, and yet that is exactly what is desired for the time adjustment) And in both, it is for what amounts to the same mathematical issues: to avoid discontinuities, in either the function or its derivatives, that give rise to undesirable artifacts.
    - cnvogel 11y ago
      > And in both, it is for what amounts to the same > mathematical issues: to avoid discontinuities, in > either the function or its derivatives, that give > rise to undesirable artifacts. My guess is that with the cos/sin modulation the time can be precisely followed by a stock ntp client that doesn't know anything about "google time" and needs some time to ramp up/down the observed clock drift, as you said: Because the derivative doesn't jump. But if you deploy special ntp servers that know about your exact method of leap-second handling (as, I suppose, google does on all servers which are sensitive to sub-second time offsets) you don't need a steady derivative: you just set adjtimex(freq-14PPM) at -10 hours before the leap second and adjtimex(freq+14PPM) at the end. And this will lead to even tighter timing, as the percieved frequency offset (from the point of view of an NTP daemon doing time interval measurements relative to a server) will disappear completely. So maybe that's why they now use a simpler method? The other explanation I could think of for introducing this simpler handling is that google may have switched to PTP on their networks: As the measurement precision is much higher (jitter much lower) than UDP based ntp even a simple NTP client will be able to quickly and precisely follow the discontinuous clock drift at the beginning and end of the smearing period. Just for illustration purposes, here's aplot of the "google lie" clock offset going from 0...1 (cos...), and the modulation of the clock frequency (sin): http://www.wolframalpha.com/input/?i=plot+%281.0+-+cos%28pi+*+t%29%29+%2F+2.0+and++sin%28pi+*+t%29+from+0+to+1 http://www.wolframalpha.com/input/?i=plot+%281.0+-+cos%28pi+...
- xfs 11y ago
  It is now http://people.ntp.org/burnicki/leap-second-2015-06-30/time1.google.com-216.239.32.15.png http://people.ntp.org/burnicki/leap-second-2015-06-30/time1....

flashman 11y ago

There was a discussion about HOW it works, but not WHY they chose that method: http://stackoverflow.com/questions/11279992/math-behind-google-leap-second-smear-formula http://stackoverflow.com/questions/11279992/math-behind-goog... My guess is they wanted time to deviate less at the start of the smear window, instead of deviating equally at all points during the window. But perhaps it turned out not to be an issue.

davidcuddeback 11y ago
My guess is that they wanted to avoid a discontinuity in the time's derivative. At t=0 and t=w, lie'(t)=0, so the clock is smoothly transitioned into and out of a faster rate.

thrownaway2424 11y ago

I'm guessing: that function has a continuous derivative. Simply running the clock uniformly faster during the interval would have a discontinuous derivative.

yonran 11y ago

If it were just linear like AWS (https://news.ycombinator.com/item?id=9567761 https://news.ycombinator.com/item?id=9567761), then an NTP client pointed to a smearing NTP server will have an immediate 12ppm drift discontinuity (NTP continually models the hardware clock as a fast or slow clock with a linear drift from true time). Perhaps the NTP client’s control algorithm will bounce around as it tries to figure out the correct hardware clock drift, and perhaps this bounce is smoother when you use cos over a day. But I haven’t studied the NTP algorithm enough to tell for sure. Edit: from other comments here, it looks like Google also uses a linear smear now (a linear drift over 20 hours is 14ppm).