Re: [LEAPSECS] Introduction of long term scheduling

From: M. Warner Losh <imp_at_BSDIMP.COM>
Date: Sat, 06 Jan 2007 12:37:01 -0700 (MST)

In message: <CCCCEA4B-3E55-444D-8B0A-A7CDA0D67687_at_noao.edu>
            Rob Seaman <seaman_at_NOAO.EDU> writes:
: Warner Losh wrote:
:
: > leap seconds break that rule if one does things in UTC such that
: > the naive math just works
:
: All civil timekeeping, and most precision timekeeping, requires only
: pretty naive math. Whatever the problem is - or is not - with leap
: seconds, it isn't the arithmetic involved. Take a look a SETI_at_Home
: and other BOINC projects. Modern computers have firepower to burn in
: fluff like live 3-D screensavers. POSIX time handling just sucks for
: no good reason. Other system interfaces successfully implement
: significantly more stringent facilities.

But modern servers and routers don't. Anything that makes the math
harder (more computationally expensive) can have huge effects on
performance in these areas. That's because the math is done so often
that any little change causes big headaches.

: Expecting to be able to "naively" subtract timestamps to compute an
: accurate interval reminds me of expecting to be able to naively stuff
: pointers into integer datatypes and have nothing ever go wrong.

Well, the kernel doesn't expect to be able to do that. Internally,
all the FreeBSD kernel does is time based on a monotonically
increasing second count since boot. When time is returned, it is
adjusted to the right wall time. The kernel only worries about leap
seconds when time is incremented, since the ntpd portion in the kernel
needs to return special things during the leap second. If there were
no leapseconds, then even that computation could be eliminated. One
might think that one could 'defer' this work to gettimeofday and
friends, but that turns out to not be possible (or at least it is much
more inefficient to do it there).

Since the interface to the kernel is time_t, there's really no chance
for the kernel to do anything smarter with leapseconds. gettimeofday,
time and clock_gettime all return a time_t in different flavors.

In short, you are taking things out of context and drawing the wrong
conclusion about what is done. It is these complications, which I've
had to deal with over the past 7 years, that have lead me to the
understanding of the complications. Espeically the 'non-uniform radix
crap' that's in UTC. It really does complicate things in a number of
places that you wouldn't think. To dimissively suggest it is only a
problem when subtracting two numbers to get an interval time is to
completely misunderstand the complications that leapseconds introduce
into systems and the unexpected places where they pop up. Really, it
is a lot more complicated than just the 'simple' case you've latched
onto.

: A
: strongly typed language might even overload the subtraction of UTC
: typed variables with the correct time-of-day to interval
: calculations.

Kernels aren't written in these languages. To base one's arugments
about what the right type for time is that is predicated on these
langauges is a non-starter.

: But then, what should one expect the subtraction of
: Earth orientation values to return but some sort of angle, not an
: interval?

These are a specialized thing that kernels don't care about.

Warner
Received on Sat Jan 06 2007 - 11:38:56 PST