[LEAPSECS] A standard for leap second smearing

[Poul-Henning Kamp]

--------
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
intervals.

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
sample.

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

-- 
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.