The referenced article indicates that they apply the smear to their NTP
servers and allow
the clients to track the servers. This approach would place some limits
on the minimum
lead time you would need to implement the smear.
1) you would have to start early enough for the servers to detect the
change. Unless
Google has an internal policy to limit maxpoll you would expect the
clients to be operating
at the default value of 1024 seconds. They would have to start well
before 1024 seconds
to allow the clients to detect the change and start tracking.
2) NTP has a maximum slew rate of 500ppm (
http://doc.ntp.org/4.1.0/ntpd.htm) .
In practice you wouldn't be able to use this full range because the
clients would already
have some error in their clocks.
The scary part of the referenced article is in the third to last paragraph:
"and Google engineers developing code don’t have to worry about leap
seconds."
That seems like the kind of attitude that would have caused such a mess
with computer
timekeeping in the first place.
On 1/11/2015 09:31, Tom Van Baak wrote:
The google code is "lie(t) = (1.0 - cos(pi * t / w)) / 2.0" and they are wise
not to publish the actual window value, w. If it were me I'd make it somewhere between a
couple of seconds or couple of minutes but I too would not make it a published or
hardcoded constant.
Here's the link again:
http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
