> And in both, it is for what amounts to the same > mathematical issues: to avoid discontinuities, in > either the function or its derivatives, that giv

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