[LEAPSECS] Bloomberg announced its smear
mshields at google.com
Thu Sep 29 15:05:16 EDT 2016
The cosine smear might be better for leap-naïve clients that have to
recognize and adapt to the frequency change, but the linear smear also
seems to work well for this if the period is long enough. The simpler
smear is great for leap-aware clients who must present a POSIX API. A
client that knows about the upcoming leap, either from NTP's leap
indicator bits or from a leap second file, can use the kernel
timekeeping knobs to slew the clock in a coordinated way instead of a
On Thu, Sep 29, 2016 at 12:34 AM, Martin Burnicki
<martin.burnicki at burnicki.net> wrote:
> Harlan Stenn wrote:
>> Cosine smearing might need to be a choice. It's harder to track the
>> leap second if you get a sample during when both phase and frequency are
> Indeed it could be just a choice, but I think it's a very good one.
> Leap smearing in general is just a hack to workaround the limitations in
> POSIX time which can severely affect client applications, e.g. problems
> with databases when the client kernel just steps the time back by 1 s
> and thus duplicate time stamps occur.
> I agree that it would be better to have a proper solution for this
> problem, and I believe that Dave Mills' idea to stop the time during an
> inserted leap second, and increment it only by 1 LSB whenever an
> application queries the time would solve most of the problems we see.
> However, quite some time ago one of the Linux kernel developers said
> it's just much more complex (and thus more expensive, with regard to
> execution time) to implement this in the kernel.
> If all servers used by a client do the smearing in the same way then the
> NTP clients will will happily move across the leap second.
> We (Meinberg) have quite a number of customers who asked for a solution
> for problems with leap seconds, and this works very well if their
> corporate NTP servers (e.g. Meinberg LANTIME NTP servers) smear the leap
> second. Of course this is only an option if the customers applications
> can tolerate that the time is temporarily off UTC, but this is often the
> least evil.
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
More information about the LEAPSECS