[ntp:hackers] smearing the leap second

John Stultz john.stultz at linaro.org
Sat Jun 20 04:14:18 UTC 2015


On Fri, Jun 19, 2015 at 2:38 PM, Harlan Stenn <stenn at ntp.org> wrote:
> Martin Burnicki writes:
>> Looks like the OS maintainers don't worry that applications may get
>> confused when this happens. I think with the approach DLM has proposed
>> many years ago, i.e. stop the clock for one second and increment if by
>> one LSB only when a process reads the time, there would be by far less
>> problems applications encounter due leap seconds (of course except due
>> to implementation error where kernels hang, or faulty GPS receivers
>> don't get it right).
>
> There must be a good reason why folks haven't implemented DLM's scheme.
>
> There are a lot of choices about leap smear, and there are a lot of
> problems with being able to trace system time to legal time.
>
> The General Timestamp API should do a fine job on all of these counts,
> and I want to use that "technology" for the NTPv5 spec.
>
> This will require enough folks to "put their money where their mouth
> is", because this isn't an issue that can be solved by each particpant
> choosing their own path and then expecting everybody to play nice
> together.

Yea. My concern with the leap-smear method that many are using is it
is ad-hoc, and while it does provide value as it works today (and only
requires the ntp server to be modified - all clients are unmodified),
it causes problems with systems interpreting time differently. For
instance, CLOCK_TAI on systems using a server driven leap-smear will
be incorrect. Further, since there is no standardized smear-interval
nor smear-starting point, systems using multiple servers might have
problems if those servers report differing smear times.

So I think an important part of the solution here will be to establish
a standard behavior for leap-smears, and to provide some signaling
from servers using the smear so "aware" clients can understand how to
interpret the smeared timestamps (possibly un-doing it if they want
strict UTC) for their own needs. So basically we need a standard
UTC-SLS, and for servers to identify which time domain they're
broadcasting.

(Ideally, it would be nice if this could be done in a compatible way
such that legacy clients see something similar to the current
leap-smear implementations)

>From that point I think we can work out how to push the functionality
down through the clients to support both legacy systems and kernel's
that support kernel driven smears (which will be required if we want
to allow systems to correctly support both CLOCK_TAI and a smeared
CLOCK_REALTIME).

thanks
-john


More information about the hackers mailing list