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