2 ms·

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 hav

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

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