[tz] Google public NTP servers to 'smear' leap seconds.
dot at dotat.at
Mon Dec 5 11:04:26 UTC 2016
Paul Eggert <eggert at cs.ucla.edu> wrote:
> With leap smearing, the ideal clock is at most 0.5 s off UTC, as opposed to
> being at most 1.0 s off with strict POSIX time.
It's a bit more complicated than that :-)
There are a number of variations of leap smear. The ones that centre the
smear interval on the leap second have an up-to-0.5s divergence from UTC.
The ones that have the whole smear interval before (or after) the leap
second have an up-to-1s divergence from UTC.
If I understand the ntpd documentation, they have implemented a
configurable smear interval that occurs before the leap second.
If you have a traditional ntp setup without kernel leap second support,
ntpd will react to a leap second by slewing the clock after it realises it
is one second wrong, when it next polls its servers after the leap second.
This is effectively a leap smear after the second, implemented as a
side-effect of ntp's sync algorithms rather than being deliberately
Ops people have often configured ntpd to work this way rather than using
kernel leap second support in order to avoid the clock appearing to go
backwards, which frequently causes enormous consternation for sensitive
software. Explicit leap smear is a more principled way to avoid this kind
of upset, rather than old-ntp-style smear-as-a-side-effect.
f.anthony.n.finch <dot at dotat.at> http://dotat.at/ - I xn--zr8h punycode
East Sole, Lundy, Fastnet, Irish Sea: Southeasterly 4 or 5, veering southerly
5 or 6. Slight or moderate. Occasional drizzle later. Moderate or good,
occasionally poor later.
More information about the tz