Re: [LEAPSECS] Introduction of long term scheduling

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

In message: <0C08AA15-F048-476C-9641-3C36D0F3A96E_at_noao.edu>
            Rob Seaman <seaman_at_NOAO.EDU> writes:
: 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.)

Actually, every IP does not have a 1's complement checksum. Sure,
there is a trivial one that covers the 20 bytes of header, but that's
it. Most hardware these days off loads checksumming to the hardware
anyway to increase the throughput. Maybe you are thinking of TCP or
UDP :-). Often, the packets are copied and therefore in the cache, so
the addition operations are very cheap.

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

Benchmarks do not lie. Also, you are misunderstanding the purpose of
timestamps in the kernel. Adding or subtracting two of them is
relatively easy. Converting to a broken down format or doing math
with the complicated forms is much more code intensive. Dealing with
broken down forms, and all the special cases usually involves
multiplcation and division, when tend to be more computationally
expensive than the checksum.

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

Having actually participated in the benchmarks that showed the effects
of inefficient timekeeping, I can say that they have a measurable
effect. I'll try to find references that the benchmarks generated.

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

If by "some limp attempt" you mean "returns the correct time" then you
are correct.

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

You'd think that, but you have to test to see if something was
pending. And the code actually does that.

: > 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?

Did I say anything about eviscerating 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.

I'm just suggesting that some of the suggested ideas have real
performance issues that means they wouldn't even be considered as
viable options.

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

True, but timekeeping is one of those areas of the kernel that extra
overhead is called so many times that making it more complex hurts a
lot more than you'd naively think.

Warner
Received on Sat Jan 06 2007 - 22:43:51 PST