Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 07 Dec 2013 08:52:54 +0000
From: Laurent Bercot <ska-dietlibc@...rnet.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCHv2] Add support for leap seconds in zoneinfo files


> What I'm missing is the benefit. The only benefit I can see to using
> TAI-10 is that you're synchronizing with your chosen clock source over
> years/decades with no discontinuity. If you're willing to accept a
> discontinuity every few years, why not just use plain POSIX time and
> apply the new difference between TAI-10 and POSIX time when rebooting?

  You don't choose when a leap second happens. To provide accurate time at
every instant your machine is up, you would have to schedule your
downtime right around a leap second. That's obviously not possible. My
suggestion allows you to choose and plan your discontinuity, most
probably merging it with some other discontinuity that will happen
anyway, while providing accurate time at every moment.


> I think this is an area where you'll find you're coming from a
> fundamentally different philosophy than most of the musl folks. The
> way I interpret your position is that using TAI-10 is only suitable
> for managed desktop/server systems, not any other kind of use where
> there's no system operator who's aware of leap second announcements
> and capable of doing manual upgrasdes. (And having system scripts kill
> and restart processes behind your back to do this for you is even
> worse; that's akin to the way Windows automatically reboots behind
> your back, and users hate it.)

  - Users hate it when Windows reboots behind their backs because it
obnoxiously gets in their way and disrupts their workflow. It's an obvious
loss of quality of service. Restarting a Unix process has nothing to do
with that. Even rebooting a whole Unix machine has nothing to do with that
if it's correctly planned.
  - Even embedded systems have firmware upgrades, and most embedded devices
automatically download the new firmware and switch to it the next time the
user powercycles the machine. I challenge the belief that a system without
any kind of operator is going to have a 3 years uptime. (And if it does,
it probably doesn't need to measure Earth time accurately.)
  - If there's such a demand for it, I can provide an implementation where you
don't even have to restart a process when the leap second table changes. It
will just be expensive at run-time (perform some kind of test whenever the
table is accessed, or simply open/read/close the file for every access). I
will ask for a musl compilation option to disable it, though, because I
believe it's useless and a waste of resources.


> If that's your only goal, it's easily achieved without storing TAI-10
> in the CLOCK_REALTIME clock, assuming by "linear" you just mean
> "monotonic, continuous, and accurate within the margin of measurement
> error".

  It probably becomes a matter of religion at this point. What is a second ?
is it Evil if a second isn't always the same duration ? Is it Evil to pretend
that some operation lasted 5 seconds when it actually was a bit more by the
usual definition of a second ?
  Until kernels perform leap smearing or provide CLOCK_UTS, and we manage to
coerce computers into using our imperfect, changing, human idea of time without
choking (my religion considers this as torture!), though, TAI-10 is the only
way to achieve this goal in practice.


> Discontinuous jumps and non-monotonicity in CLOCK_REALTIME
> were a monstrosity invented by the NTPD folks in their implementation
> for mapping TAI onto POSIX time, not any fundamental requirement.

  I agree that ntpd is a prime example of bad design in about every way, but
I blame POSIX more for forcing computers to align system time with human time
in the first place. :)

-- 
  Laurent

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.