Re: [LEAPSECS] Introduction of long term scheduling

From: Rob Seaman <seaman_at_NOAO.EDU>
Date: Sun, 7 Jan 2007 01:49:38 -0700

Warner Losh wrote:

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

Ok. I simplified. There are several layers of checksums. I
designed an ASCII encoded checksum for the astronomical FITS format
and should not have been so sloppy. "They do it in hardware" could
be taken as an argument for how time should be handled, as well.

> Adding or subtracting two of them is relatively easy.

Duly stipulated, your honor.

> Converting to a broken down format or doing math
> with the complicated forms is much more code intensive.

And should the kernel be expected to handle "complicated forms" of
any data structure?

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

Indeed. May well be. I would suggest that the natural scope of this
discussion is the intrinsic requirements placed on the kernel, just
as it should be the intrinsic requirements of the properly traceable
distribution and appropriate usage of time-of-day and interval
times. Current kernels (and other compute layers, services and
facilities) don't appear to implement a coherent model of
timekeeping. Deprecating leap seconds is not a strategy for make the
model more coherent, rather, just the timekeeping equivalent of
Lysenkoism.

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

With zero irony intended, that would be thoroughly refreshing.

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

It's not the correct time under the current standard if the
timekeeping model doesn't implement leap seconds correctly. I don't
think this is an impossible expectation, see http://
www.eecis.udel.edu/~mills/exec.html, starting with the Levine and
Mills PTTI paper.

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

Does such testing involve the complex arithmetic you describe above?
(Not a rhetorical question.) The kernel does a heck of a lot of
conditional comparisons every second.

> Did I say anything about eviscerating mean solar time?

Well, these side discussions get a little messy. The leap second
assassins haven't made any particular fuss about kernel computing
issues, either, just previous and next generation global positioning
and "certain spread spectrum applications" and the inchoate fear of
airplanes falling from the sky.

The probability of the latter occurring seems likely to increase a
few years after leap seconds are finally eradicated - after all,
airplanes follow great circles and might actually care to know the
orientation of the planet. Hopefully, should such a change occur
courtesy of WP7A, all pilots, all airlines and all air traffic
control centers will get the memo and not make any sign errors in
implementing contingent patches. It's the height of hubris to simply
assume all the problems vanish with those dastardly leap seconds. (I
don't suppose the kernel currently has to perform spherical trig?)

Note that the noisy astronomer types on this list are all also
software types, we won't reject computing issues out of hand.

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

Real performance issues will be compelling evidence to all parties.
Real performance issues can be described with real data.

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

Either the overhead in question is intrinsic to the reality of
timekeeping - or it is not. In the latter case, one might expect
that we could all agree that the kernel(s) in question are at fault,
or that POSIX is at fault. I have little sympathy for the suggestion
that having established that POSIX or vendors are at fault that we
let them get away with it anyway. Rather, workaround any limitations
in the mean time and redesign properly for the future.

If, however, the overhead is simply the cost of doing timekeeping
right, then I submit that it is better to do timekeeping right than
to do it wrong. Doing it right certainly may involve appropriate
approximations. Destroying mean solar time based civil time-of-day
is not appropriate.

Of course, we have yet to establish the extent of any problem with
such overhead. It sounds like you have expertise in this area.
Assemble your data and make your best case. Note that your audience
should be WP7A, not just this rollicking crew.

Rob
Received on Sun Jan 07 2007 - 00:59:16 PST