[LEAPSECS] A standard for leap second smearing

Poul-Henning Kamp phk at phk.freebsd.dk
Wed Sep 28 01:54:19 EDT 2016

In message <CALvMCHLqRGR0-J6w-8u11g-o94OUK7eamdYs2X2079+nHkh18Q at mail.gmail.com>, Michael Shield
s via LEAPSECS writes:

>> 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.
>I expect a smear of 2000 s or less would be challenging for NTP
>clients, because of the 500 ppm max slew rate, which would be entirely
>consumed by tracking the smear.  Clients that have backed off to 1024
>s polling would also have trouble noticing that a smear was happening
>when the smear is only 1000 s or 2000 s long.

It is much worse than that: You need to account for the delay in
the median filter, which on straight slopes is typically 4 poll

For a well-running client, that means it won't even start to pay
attention to the smear from the server until after 4096 seconds,
at which time it will start to look at a 1024 or 2048 second old

Once fully on the slope of the smear, the median filter will run
4096 seconds "behind" and once the smear is over, it will overshoot
in similar fashion.

>Besides being easier for NTP clients to track, a slow smear has the
>advantage [...]

Ohh, and don't forget:

DCF77 only announces the smear one hour in advance.


Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

More information about the LEAPSECS mailing list