* John Stultz <john.stu...@linaro.org> wrote:
> > [...]
> >
> > but the long term trend still dominates. Look at this graph of measurements
> > of the
> > Earth's rotation:
> >
> > http://en.wikipedia.org/wiki/File:Deviation_of_day_length_from_SI_day.svg
> >
> > See how the mean (the green line) was always above zero in the measured
> > past. The
> > monotonically increasing nature comes from that.
> >
> > and given how many problems we had with leap second insertion, on millions
> > of
> > installed systems, guess the likelihood of there being a leap second
> > deleted? How
> > many OSs that can do leap second insertion are unable to do leap second
> > deletion?
> >
> > Also note that leap second deletion means a jump in time backward. Daylight
> > saving
> > time is already causing problems with that.
>
> Err.. Other way around. Leap-second deletion is a jump in time forward
> (jumping
> from 23:59:58 to 00:00:00, skipping 23:59:59). Which is simpler to deal with.
> [...]
Indeed!
Still my point remains: many OSs that can handle leap second insertion don't
handle leap second deletion, so what are the chances that even a temporary blip
in
earth's rotation (which will be offset by the long term trend within a year or
so
after the event) will cause a conservative international standards body to
declare
an unprecedented leap second deletion? Fairly low I'd say.
> [...] And luckily (at least for us) daylight savings is done in userspace (as
> UTC, including leapseconds, ideally would be from the kernel providing TAI
> time).
>
> But yes, I agree that the leap deletion logic is likely to never run outside
> of
> testing.
Which is a red flag.
> > [...]
> >
> > So why make the code more fragile, more complex, just to solve a scenario
> > that
> > cannot really be done perfectly?
>
> So here I worry I didn't communicate clearly enough what the patch does. :(
>
> Its not about making interrupts more accurate around the leapsecond, its
> about
> applying the leapsecond transition in the read-path precisely at the
> leapsecond
> edge (rather then a short while later when the timer fires and we update the
> timekeeping structures).
>
> But more importantly, this change to the read path prevents timers that may
> be
> expired before update_wall_time timer runs (most likely on other cpus) from
> being expired early. Since the time read that is used by the hrtimer
> expiration
> logic is adjusted properly right on that edge.
But with leap second smearing we'd have the same benefits and some more.
> > Especially as second smearing appears to be the way superior future method
> > of
> > handling leap seconds.
>
> So here the problem is it depends on the user. For probably most users, who
> really don't care, the leap-smear is ideal behavior for CLOCK_REALTIME (I
> think
> leap-smears causing any change to other clockids would be surprising).
> However,
> there are some users who expect posix UTC leapsecond behavior. Either because
> they're positioning telescopes doing things that do depend on strict solar
> time,
> or because they are required (in some cases by law) to use UTC.
That usecase is perfectly OK: they can use the old leap second logic.
What I argue is that we should not add significant complexity to logic that is
fragile already as-is, and which runs at most only once per year.
> I don't think we can just abandon/break those users, for leap-smearing. So I
> don't know if we can get away from that complexity.
That's a false dichotomy - I'm not suggesting to 'abandon' them.
I'm suggesting one of these options:
- Keep the current leap second code as-is, because it's proven. Concentrate
on
leap second smearing instead that is superior and which might emerge as a
future standard.
- or make leap second insertion much more obvious and easier to verify (i.e.
not
a +100 LOC delta!)
- or make leap second handling a part of some other existing facility that is
used much more frequently: for example have you considered making it a
special, kernel-internal case of settimeofday()? If settimeofday was
implemented in a fashion to set the time at a given 'time edge', then
thousands of systems would test that facility day in and out. Leap second
insertion would simply be a special settimeofday() call that sets the time
back by one second at midnight June 30 or so. Normal settimeofday() would
be a
call that sets the time back (or forward) at the next seconds edge right
now -
but it would fundamentally use the same facility.
and yes, this variant would necessarily complicate settimeofday(), but
that's
OK, as it's used so frequently so we have adequate testing of it.
A third facility would effectiely be merged with this as well: when NTP
adjusts large offsets (when running with -g, etc.) it will use
settimeofday(),
right?
I don't think we've exhausted all of these options.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
