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