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 _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
