[LEAPSECS] Leap second smearing test results

[Zefram]

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.

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.  One must also model the error
introduced by the difficulty of the unaware downstream ntp in tracking
the smear.  I would be interested to see how consistent the tracking
error is across multiple runs of this scenario, and with varying phase
of the polling cycle.  The level of consistency here places an upper
limit on how precisely UTC can be recovered from the smeared timestamps,
in the usual case where the tracking error wasn't measured at the time.

NTP's multi-stratum architecture means that this problem isn't limited
to the simple case of tracking a clock that is smearing cleanly.
The unaware ntp doing that may also serve as the reference for a
further-downstream client, which then has the even more difficult job of
tracking an uncleanly-smearing clock.  I'd like to see how the tracking
error changes with stratum.  To recover UTC, one would need to know by
how many NTP links the timestamping system is removed from the system
introducing the smear, in order to correctly model the tracking error.

To make analysis easier, it would be tempting to look for a smear shape
that is an eigenvalue of the clock tracking function.  But I think there
can't be such a shape: an unaware client by definition can't start its
own frequency shift until strictly after its upstream reference has
started it.  I think the complications of multi-stratum tracking are
just going to be managed by avoiding having more than a couple of layers.

But an understanding of the imperfect clock tracking opens up another
possibility: could a sufficiently clever ntp server introduce a smear
calculated to manipulate its clients into actually executing a smear
of a precisely specified target shape?  Presumably this would require
starting the smear early, exaggerating the frequency offset at the
start, and temporarily overshooting the return to normal frequency at
the end.  This could get us an easily-inverted linear smear on unaware
timestamp-generating clients.

A final lesson to draw here is that lying about the time is a problematic
strategy.  The smear is not a great way to steer a clock that doesn't
know that a smear is going on.  The smear *is* good for squeezing
UTC into timestamp data formats that can't handle 23:59:60, provided
that no precise computation needs to be performed by an unaware entity.
So the better way to implement the smear would be to shift it downstream:
clock synchronisation should be all unadulterated NTP handling the leap
as a leap, and the lying should happen later, probably where the client
ntp instances are steering their system clock.

-zefram