Re: [LEAPSECS] Introduction of long term scheduling

From: Rob Seaman <seaman_at_NOAO.EDU>
Date: Sat, 6 Jan 2007 18:12:18 -0700

Warner Losh wrote:

> 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.

Every IP packet has a 1's complement checksum. (That not all
switches handle these properly is a different issue.) Calculating a
checksum is about as expensive (or more so) than subtracting
timestamps the right way. I have a hard time believing that epoch<-
>interval conversions have to be performed more often than IP
packets are assembled. One imagines (would love to be pointed to
actual literature regarding such issues) that most computer time
handling devolves to requirements for relative intervals and epochs,
not to stepping outside to any external clock at all. Certainly the
hardware clocking of signals is an issue entirely separate from what
we've been discussing as "timekeeping" and "traceability". (And note
that astronomers face much more rigorous requirements in a number of
ways when clocking out their CCDs.)

> 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.

Well, no - the point is that only some limp attempt is made to adjust
to the right 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).

One might imagine that an interface could be devised that would only
carry the burden for a leap second when a leap second is actually
pending. Then it could be handled like any other rare phenomenon
that has to be dealt with correctly - like context switching or
swapping.

> Really, it is a lot more complicated than just the 'simple' case
> you've latched onto.

Ditto for Earth orientation and its relation to civil timekeeping.
I'm happy to admit that getting it right at the CPU level is
complex. Shouldn't we be focusing on that, rather than on
eviscerating mean solar time? In general, either "side" here would
have a better chance of convincing the other if actual proposals,
planning, research, requirements, and so forth, were discussed. The
only proposal on the table - and the only one I spend every single
message trying to shoot down - is the absolutely ridiculous leap hour
proposal. We're not defending leap seconds per se - we're defending
mean solar time.

A proposal to actually address the intrinsic complications of
timekeeping is more likely to be received warmly than is a kludge or
partial workaround. I suspect it would be a lot more fun, too.

> 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.

No, but the kernels can implement support for these types and the
applications can code to them in whatever language. Again - there is
a hell of a lot more complicated stuff going on under the hood than
what would be required to implement a proper model of timekeeping.

Rob
Received on Sat Jan 06 2007 - 17:12:47 PST