[time-nuts] June 30 2015 leap second
martin.burnicki at burnicki.net
Sun Jan 11 13:29:02 EST 2015
Tom Van Baak wrote:
>> Keep in mind that this system drives you to having pretty bad time for the
>> better part of a whole day, on purpose... I realize that when the
> Hi Didier,
> The google article never claims the smear spans an entire day. I
> think you may be confusing references to the leap smear with a DIY
> digital clock someone on the list wanted to build (and they proposed
> using a slow 86400 second slew).
> 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.
Hm, the article says, "It also made sure the updates were sufficiently
small so that any software running on the servers that were doing
synchronization actions or had Chubby locks wouldn't lose those locks or
abandon any operations."
So I think they smeared it over more than just a few minutes. I'd expect
some hours, so standard NTP clients would just notify this as clock
drift (oscillator frequency offset) which they'd have to compensate.
Since ntpd's control loop is pretty slow it wouldn't respond quickly to
smears over a few seconds our hours.
> Here's the link again:
> Again, I don't know what value they use, or even if they use the same
> value from one leap second to the next. If any of you have inside
> contacts with google and can find out let me know, off-list.
> Regardless, it should be possible to experimentally determine the
> smear duration by repeatedly using some google service that returns
> time-stamps during the day, hours, minutes, or seconds before and
> after June 30. It would make a nice posting for a time nut, or a
> research paper for a high school student or undergrad: Experimental
> Confirmation of Google's Leap Smear Algorithm.
Yes, interesting idea!
More information about the time-nuts