Re: Introduction of long term scheduling
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
Re: Introduction of long term scheduling
So you think it is appropriate to demand that ever computer with a clock should suffer biannual software upgrades if it is not connected to a network where it can get NTP or similar service ? I know people who will disagree with you: Air traffic control Train control Hospitals and the list goes on. FWIW, I believe most hospitals are more than capable of looking after equipment with complex maintenance schedules. They have endoscopes, blood gas analysers, gamma cameras, MRI machines, dialysis machines and a rake of other stuff that has a schedule requiring attention more regurally than once every 6 months. I am not sure how much un-networked equipment that requires UTC to 1 second and doesn't already have a suitable maintenance schedule exists in hospitals. David.
Re: Introduction of long term scheduling
On Sat, 6 Jan 2007, M. Warner Losh wrote: Most filesystems store time as UTC anyway... POSIX time is not UTC :-) Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ SOUTHEAST ICELAND: CYCLONIC 6 TO GALE 8, DECREASING 5 OR 6 LATER. ROUGH OR VERY ROUGH. OCCASIONAL RAIN OR WINTRY SHOWERS. MODERATE OR GOOD.
Re: Introduction of long term scheduling
On Sun, 7 Jan 2007, Rob Seaman wrote: 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. As http://www.eecis.udel.edu/~mills/leap.html shows, NTP (with kernel support) is designed to stop the clock over the leap second, which I don't call correct. Without kernel support it behaves like a pinball machine (according to Mills). Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ SOUTHEAST ICELAND: CYCLONIC 6 TO GALE 8, BECOMING VARIABLE 4 FOR A TIME. ROUGH OR VERY ROUGH. OCCASIONAL RAIN OR WINTRY SHOWERS. MODERATE OR GOOD.
Re: Introduction of long term scheduling
In message [EMAIL PROTECTED], David Malone writes: FWIW, I believe most hospitals are more than capable of looking after equipment with complex maintenance schedules. It is not just a questoin of ability, to a very high degree cost is much more important. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Introduction of long term scheduling
In message: [EMAIL PROTECTED] Tony Finch [EMAIL PROTECTED] writes: : On Sat, 6 Jan 2007, M. Warner Losh wrote: : : Most filesystems store time as UTC anyway... : : POSIX time is not UTC :-) True. It is designed to be UTC, but fails to properly implement UTC's leap seconds and intervals around leapseconds. Warner
Re: Introduction of long term scheduling
In message: [EMAIL PROTECTED] Rob Seaman [EMAIL PROTECTED] writes: : 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. It implements exactly what ntpd wants. I asked Judah Levine when determining what was pedantically correct during the leap second. I also consulted with the many different resources avaialable to deterimine what the right thing is. Of course, there are different explaintions about what the leap second should look like depending on if you listen to Dr. Levine or Dr Mills. Dr. Mills web site says 'redo the first second of the next day' while Dr. Levine's leapsecond.dat file says 'repeat the last second of the day.' Actually, both of them hedge and say 'most systems implement...' or some variation on that theme. It is possible to determine when you are in a leap second using ntp extensions with their model. Just not with POSIX interfaces. The POSIX interfaces are kludged, while the ntpd ones give you enough info to know to print :59 or :60, but POSIX time_t is insufficiently expressive, by itself, to know. But ntp_gettime returns a timespec for the time, as well as a time_state for the current time status, which includes TIME_INS and TIME_DEL for psotive and negative leap second 'warning' for end of the day so you know there will be a leap today, and TIME_WAIT for the actual positive leap second itself (there's nothing for a negative leapsecond, obviously). So I stand by my returns the correct time statement. Warner
Re: Introduction of long term scheduling
On Sun, 7 Jan 2007, M. Warner Losh wrote: [POSIX time] is designed to be UTC, but fails to properly implement UTC's leap seconds and intervals around leapseconds. From the historical point of view I'd say that UNIX time was originally designed to be some vague form of UT, and the POSIX committee retro-fitted a weak form of UTC synchronization. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ DOGGER FISHER GERMAN BIGHT HUMBER: SOUTHWEST, VEERING NORTHWEST FOR A TIME, 6 TO GALE 8, OCCASIONALLY SEVERE GALE 9 IN DOGGER. ROUGH OR VERY ROUGH. RAIN OR SHOWERS. MODERATE OR GOOD.
Re: Introduction of long term scheduling
On 8 Jan 2007 at 0:15, Tony Finch wrote: How did you extend the UTC translation back past 1972 if the undelying clock followed TAI? I assume that beyond some point in the past you say that the clock times are a representation of UT. However TAI matched UT in 1958 and between then and 1972 you somehow have to deal with a 10s offset. Formulas for UTC, as actually defined at the time, go back to 1961 here: ftp://maia.usno.navy.mil/ser7/tai-utc.dat It appears the offset was 1.4228180 seconds at the start of this. -- == Dan == Dan's Mail Format Site: http://mailformat.dan.info/ Dan's Web Tips: http://webtips.dan.info/ Dan's Domain Site: http://domains.dan.info/
