[LEAPSECS] Bloomberg announced its smear

[Martin Burnicki]

Tom Van Baak wrote:
>> Actually, cosine with a much higher frequency might be the way to
>> beat the median filter.

Yep.

> If the only application of leap smear is to placate NTP, and if all
> NTP clients use the same hardcoded filter parameters, then, yes, by
> all means, find a higher, optimal frequency.
> 
> But I would worry about defining a future leap smear specification
> based on legacy NTP parameters.

Agreed. No one said that the way smearing is implemented in ntpd is the
optimal solution which should be standardized.

As mentioned in my other reply it is just a hack to help users avoiding
problems wthh leap seconds.

> And it begs the question -- if the
> choice of parameters for a proposed new universal smear standard are
> so rooted in NTP, why not just fix NTP in the first place?

As has been mentioned in a different post ntpd has *no* problems with
leap seconds. It just propagates the information of an upcoming leap
second to its kernel and to its clients.

One of the earlier "leap second problems with ntpd" was that it
announced a leap second at a wrong time, e.g. for the end of September.
However, this was not a problem with ntpd but with faulty GPS receivers
which output a leap second announcement at the wrong time.

You know the discussion how many plausibility checks ntpd should make:
accept a leap second announcement only at the end of June or December,
just because all previous leap seconds happened in these months, or
accept a leap second at the end of *any* month, since basically leap
seconds could be scheduled for any month.

You also know some GPS receivers already added the leap second as soon
as the GPS satellites started announcing it, and thus the time output by
these receivers was off UTC by one second. ntpd is unable to detect
this, and you can't blame ntpd if it starts providing a wrong time just
because its reference time source, the GPS receiver, outputs a wrong time.

BTW, even if ntpd would be able to detect that a leap second
announcement at the end of September was invalid and would ignore it,
this would just delay the problem with the faulty GPS receiver. At the
beginning of October the leap second announcement has been cleared, the
GPS receiver has probably inserted the leap second and thus is off UTC
by 1 second, so ntpd would anyway accept the new, faulty time after a
few minutes. The only real way to fix this is to fix the GPS receiver,
not ntpd.

ntpd includes quite a number of workarounds for limitations in operating
systems, especially in Windows. E.g. Windows knows nothing about leap
seconds at all, so ntpd takes care to slew the system time over 2
seconds when a leap second is inserted. Similarly the leap smear feature
is just a workaround to avoid problems with the OS.

If you'd run a PTP daemon instead of ntpd, and the PTP daemon just
passes the leap second warning down to the kernel the you had the same
problems with applications when the kernel steps the time back, or when
particular versions of the Linux kernel lock up due to the leap second.

Martin