[LEAPSECS] Leap second smearing test results

[Warner Losh]

On Thu, Dec 22, 2016 at 6:48 PM, Zefram <zefram at fysh.org> wrote:
> Martin Burnicki wrote:
>>I've run some more tests with smearing of leap seconds,
>
> These new ones, with variable polling interval on the client, are much
> more useful than the former ones with fixed polling interval.  It seems
> to me that these measurements should concentrate on clients with default
> settings, because if one is able to configure the client to better follow
> the smear then one could easily do an even better job by configuring
> the client to follow an honest server and to introduce the smear itself.
> Only the case where the client can't be specially configured is really
> relevant to the concept of introducing the smear upstream.
>
> I'd like to see a run of this client type with the 24 hour smears
> that you used earlier, or of a fixed-polling-interval client with the
> new 10 hour smears, so that variable polling interval can be directly
> compared against fixed polling interval.  I'd interpreted your earlier
> tests generally based on the poll=10 client, in the expectation that
> the default variable polling interval would behave similarly, but it's
> not clear whether the reductions of polling interval that you see would
> result in a significant difference in performance.
>
> It is strange that the polling interval varies so much more with the
> linear smear than with the sinusoidal smear.  I would have expected them
> to remain stable at poll=10 for the bulk of the smear, after they've
> recovered from the initial frequency change.  There is a point 2.5
> hours into the smear where all the clients have returned to poll=10;
> can you explain why they reduce it again after that?
>
> Also strange that the three clients had such different reactions to the
> end of the linear smear, having been so similar in their reactions to
> the start of it, and similar in all parts of the sinusoidal smear.
>
> It is interesting that when the server suggests a smaller poll interval
> the shape of the smear makes a big difference to the tracking accuracy.
> This is much like the difference that we intuitively expected the shape
> to make in the first place.

I'd be curious what a longer smear time would do? Longer smears would
give a smaller frequency error, which might be easier to digest. It
also copes better with long-polling intervals in clients at the
expense of a longer phase error in the clients.

I'd have to say that any hope of recovering actual UTC on the clients
that are smearing is likely in vain. Too many steering loops involved
to get a good, stable, reliable, predictable answer at any given
moment, even if you on the average get decent behavior. If you need
UTC, you must count in UTC and lie to the clients on your machine
directly if you are smearing for their sake.

These are the reasons I hate leap seconds: they are of dubious value
and cause all kinds of havoc because nobody expects them to work, and
the programming standards are written as if they don't exist.

Warner