[LEAPSECS] A standard for leap second smearing

[Miroslav Lichvar]

On Tue, Sep 27, 2016 at 11:45:18PM +0100, Stephen Colebourne wrote:
> The goal of this thread is to see if consensus could be found for one
> approach of smearing.

I suspect that won't be possible as it seems there are conflicting
requirements which may have different priorities in different
environments.

> The decisions would appear to be:
> 
> 1) Linear or Other?
> All current known smears are linear. Google previously had a different
> approach, but changed to linear. Are there any major arguments against
> linear? It would seem to be easier to specify and code that way.

As others have said in this thread, linear smear works well when the
control loop is aware of it, e.g. it's performed by NTP clients
themselves. When the smeared time is distributed over NTP and the
clients don't know what's happening, it's better to use a function
with a continous first derivate (no steps the frequency) so it's
easier for them to track. From what I've seen this can reduce the
maximum error of the clock by a factor of somewhere around 3 to 10
(it depends on the network and the implementation/configuration of the
client). This means the smear can be significantly shorter while
meeting the same requirements for accuracy.

The reference NTP implementation supports a cosine smear on NTP
server. The chrony implementation supports a quadratic smear on NTP
server and a linear smear on NTP client. I can't give you any names,
but I know that some companies have used the quadratic smear on the
2015 leap.

> 2) When to smear?
> Some smear up to midnight, some smear after midnight, some smear both
> sides. What are the arguments for/against each?

An argument for after midnight is that it doesn't need to know about
the leap second too long before the midnight. With NTP and reference
clocks it's quite common that the leap is announced just an hour
before midnight.

Symmetric smear minimizes the average error to UTC.

I'm not sure if there is any advantage of smearing before midnight
over the other two approaches, except maybe in specific cases where it
would be preferred to have it on Sunday instead of Monday to avoid
business hours.

> 3) Speed of smearing?
> The existing approaches have two broad groups - fast (under an hour -
> Bloomberg/UTC-SLS) and slow (20 hours or more - Google/Amazon) with
> QTnet an outlier towards the fast end. What are the arguments
> for/against fast/slow? Would there be a case for two agreed standards,
> one fast and one slow?

Possibly, but I suspect they would not cover all possible use cases. I
think it all depends on what is the maximum acceptable phase and
frequency error of the clocks. The 1000/2000 second smears may be
useful if they can be applied locally and the frequency error of
500-1000 ppm is acceptable. The 20/24 hour smears may be acceptable
some environements, but not when there is a requirement is to keep
ntpd clients (in default configuration) accurate to 10 milliseconds
for instance.

-- 
Miroslav Lichvar