[LEAPSECS] Leap second smearing test results
Martin Burnicki
martin.burnicki at burnicki.net
Wed Jan 4 10:34:56 EST 2017
Again, sorry for replying so late. I've been mostly offline over the
holidays.
Zefram schrieb:
> Martin Burnicki wrote:
>> https://www.meinberg.de/download/burnicki/ntp_leap_smearing_test_results.pdf
>
> This is interesting. The smear actually achieved on the downstream ntp
> is a complicated function of the smear introduced upstream. Your graphs
> nicely illustrate the lesson that Google has imparted recently, that
> there's little advantage in a sinusoidal shape for a slow smear. It also
> shows that the smear isn't really as successful as one might expect:
> the smeared clock isn't being tracked without significant error.
Indeed. As expected this depends on the server's smear interval and
smear shape, on the client's poll interval, if the server starts
smearing just after the client has polled, or shortly before it polls
next time, etc.
However, my initial motivation to run these time-consuming tests was
that I read that some folks thought the could just smear the leap second
over 2000 seconds or so, and I didn't believe this works properly with
standard NTP clients.
> An immediate implication is that, if one needs to recover real UTC
> from a timestamp generated on a system downstream of such a smear, then
> for precision finer than 100 ms it is not sufficient to just apply the
> inverse of the smear that was introduced.
As I've already mentioned in another reply, I think this kind of leap
smearing is just a hack, an ugly workaround for clients which are
seriously affected by leap seconds.
For example, we have a customer running an old Linux system with the
kernel bug where it just hangs when the leap second is inserted. Even
though they know there is a patched kernel available there are some
specific reasons why they can't apply any update. So letting the server
smear the leap second avoids problems with that machine.
I don't think clients of a smearing server should try to undo the
smearing. Rather, the time distribution should be set up such that most
of the stuff works as usually, without smearing, and smeared time should
only be supplied to machines which can't handle leap seconds for some
reason.
Martin
More information about the LEAPSECS
mailing list