Re: [LEAPSECS] happy anniversary pips
Um, that is false. All linux kernels did not crash, in fact NONE of mine did. "all" here was an overstatement, but the impact of the leap second should never be "your kernel crashes" even if your personal kernels didn't. You should refrain from making inaccurate claims, it damages your credibility. The fact that the most recent leap second error didn't cause kernel crashes but caused extra cpu cycles to be spent again lowers your credibility. MP is hard, sure, but that's not the root cause of this issue. The root cause of this issue was an error when stepping a clock backwards? Why was the clock stepped backwards? To comply with a POSIX requirement that does not match reality? I submit that the proper fix is to update the spec to match the fact that we now have days that are 86401 seconds long, now to eliminate leap seconds. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
On Feb 12, 2014, at 5:36 AM, Greg Hennessy wrote: > >>> Um, that is false. All linux kernels did not crash, in fact NONE of >>> mine did. >> >> "all" here was an overstatement, but the impact of the leap second >> should never be "your kernel crashes" even if your personal kernels >> didn't. > > You should refrain from making inaccurate claims, it damages your > credibility. It still doesn't detract from my point: leap seconds caused aberrant behavior in the linux kernel that everybody wants to nit-pick me on, but the nit-picks don't detract from the point. The point is the aberrant behavior, rather than the slight mischaracterizations of that. Geeze, no wonder no progress can be made, people are arguing over the wrong things. > The fact that the most recent leap second error didn't cause kernel > crashes but caused extra cpu cycles to be spent again lowers your > credibility. I'm sorry, but a live lock is a crash. Claiming otherwise lowers your credibility. The Linux bug was a classic live-lock problem where no progress could be made depriving other users of CPU cycles. This is a crash, and has been considered a crash for the past 30 years or so. I've personally fixed a number of such crashes where the bug description was "crash" when more properly it was described as a deadlock or live lock.. >> MP is hard, sure, but that's not the root cause of this issue. > > The root cause of this issue was an error when stepping > a clock backwards? Why was the clock stepped backwards? To > comply with a POSIX requirement that does not match reality? The root cause happened in 1972 when time was changed from an fixed radix to a variable radix. > I submit that the proper fix is to update the spec > to match the fact that we now have days that are 86401 > seconds long, now to eliminate leap seconds. Actually it isn't reality. Days don't have 86401 seconds, and won't for a few millennia. Days have 86400.001 SI seconds (give or take). UTC isn't "reality," but a standard for keeping the variations in that 0.001 in sync with fixed-length seconds by choosing a convention to label seconds so that is accomplished. POSIX is a standard for keeping time in a computer. These two standards are in conflict. That's the real root cause here. Claiming that POSIX doesn't match "reality" lowers your credibility. POSIX and UTC don't describe the same thing. One must change to resolve the conflict. Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
On 2014-02-12 04:36 AM, Greg Hennessy wrote: Um, that is false. All linux kernels did not crash, in fact NONE of mine did. "all" here was an overstatement, but the impact of the leap second should never be "your kernel crashes" even if your personal kernels didn't. You should refrain from making inaccurate claims, it damages your credibility. The fact that the most recent leap second error didn't cause kernel crashes but caused extra cpu cycles to be spent again lowers your credibility. MP is hard, sure, but that's not the root cause of this issue. The root cause of this issue was an error when stepping a clock backwards? Why was the clock stepped backwards? To comply with a POSIX requirement that does not match reality? I submit that the proper fix is to update the spec to match the fact that we now have days that are 86401 seconds long, now to eliminate leap seconds. There is nothing fundamentally wrong with UTC and Leap Seconds - the theory is sound, and the IERS does a fantastic job of keeping track of it. But there are difficulties with implementations for several reasons - A) The specifications and procedures regarding UTC are scattered over many documents and several standards bodies. B) There is no standardized, centralized, and *automated* way to obtain the UTC metadata (Leap Seconds table, announce signals, etc) C) There are well know inadequacies with c and POSIX specs with regard to Leap Seconds which have percolated through the computer industry. D) Timezones are a horrendous mess, if somewhat mitigated now by IANA's administration of tz database. "Eliminating Leap Seconds" doesn't begin to address the implementation difficulties. By itself it would likely make things (much) worse. Instead, all this passion could be directed at - A) Cleaning up and consolidating the UTC specs B) Designing a good and modern "date and time metadata server" C) Cleaning up the c and POSIX specs D) Clarifying timezone guidelines, including standardizing "international date line", "UTC offset", and methods of "Daylight instantiation" It took centurys for the Gregorian calendar to be accepted. Hopefully it won't take as long for society to start using UTC correctly. -Brooks ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
Warner Losh writes: > > On Feb 12, 2014, at 5:36 AM, Greg Hennessy wrote: > > > > >>> Um, that is false. All linux kernels did not crash, in fact NONE of > >>> mine did. > >> > >> "all" here was an overstatement, but the impact of the leap second > >> should never be "your kernel crashes" even if your personal kernels > >> didn't. > > > > You should refrain from making inaccurate claims, it damages your > > credibility. > > It still doesn't detract from my point: leap seconds caused aberrant behavior > in the linux kernel that everybody wants to nit-pick me on, but the nit-pick > s don't detract from the point. The point is the aberrant behavior, rather th > an the slight mischaracterizations of that. Geeze, no wonder no progress can > be made, people are arguing over the wrong things. Bad handling and inadequate testing of leap seconds in those kernels (and was some of it libc?) caused the aberrant behavior. H ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
On Feb 12, 2014, at 7:53 AM, Harlan Stenn wrote: > Warner Losh writes: >> >> On Feb 12, 2014, at 5:36 AM, Greg Hennessy wrote: >> >>> > Um, that is false. All linux kernels did not crash, in fact NONE of > mine did. "all" here was an overstatement, but the impact of the leap second should never be "your kernel crashes" even if your personal kernels didn't. >>> >>> You should refrain from making inaccurate claims, it damages your >>> credibility. >> >> It still doesn't detract from my point: leap seconds caused aberrant behavior >> in the linux kernel that everybody wants to nit-pick me on, but the nit-pick >> s don't detract from the point. The point is the aberrant behavior, rather th >> an the slight mischaracterizations of that. Geeze, no wonder no progress can >> be made, people are arguing over the wrong things. > > Bad handling and inadequate testing of leap seconds in those kernels > (and was some of it libc?) caused the aberrant behavior. The linux kernel has been touted by some of its proponents as the most tested and verified kernel around. Some may quibble with this characterization, but if not the most, certainly one of the most. And even so, this problem with leap seconds managed to escape into released kernels. If that happened, here, what hope is there for other, less well tested systems. Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
On Feb 12, 2014, at 8:03 AM, Brooks Harris wrote: > On 2014-02-12 04:36 AM, Greg Hennessy wrote: >> Um, that is false. All linux kernels did not crash, in fact NONE of mine did. >>> >>> "all" here was an overstatement, but the impact of the leap second >>> should never be "your kernel crashes" even if your personal kernels >>> didn't. >> >> You should refrain from making inaccurate claims, it damages your >> credibility. >> >> The fact that the most recent leap second error didn't cause kernel >> crashes but caused extra cpu cycles to be spent again lowers your >> credibility. >> >>> MP is hard, sure, but that's not the root cause of this issue. >> >> The root cause of this issue was an error when stepping >> a clock backwards? Why was the clock stepped backwards? To >> comply with a POSIX requirement that does not match reality? >> >> I submit that the proper fix is to update the spec >> to match the fact that we now have days that are 86401 >> seconds long, now to eliminate leap seconds. >> >> > > There is nothing fundamentally wrong with UTC and Leap Seconds - the theory > is sound, and the IERS does a fantastic job of keeping track of it. But there > are difficulties with implementations for several reasons - > > A) The specifications and procedures regarding UTC are scattered over many > documents and several standards bodies. > > B) There is no standardized, centralized, and *automated* way to obtain the > UTC metadata (Leap Seconds table, announce signals, etc) i'd add 'verified' or 'secure' (since many of the ways involve http:// urls) to this list. > C) There are well know inadequacies with c and POSIX specs with regard to > Leap Seconds which have percolated through the computer industry. > > D) Timezones are a horrendous mess, if somewhat mitigated now by IANA's > administration of tz database. E) Leap seconds are tied to observations of the earth's spin, rather than predicted years in advance. With only 6 months warning for leap seconds, this produces operational difficulties for many environments that have burdensome change control policies. Long term, we have the ability to predict out decades what the proper rate of leap seconds should be to keep things in sync over the long haul. One of the nice things about the Gregorian calendar is that it accepts errors of up to like 3 days (worst case) to keep the over all system simple (every 4 except 100 except 400) and on track for millennia. Leap seconds, as currently implemented, require too much "phone home" to keep things on track. > "Eliminating Leap Seconds" doesn't begin to address the implementation > difficulties. By itself it would likely make things (much) worse. Instead, > all this passion could be directed at - > > A) Cleaning up and consolidating the UTC specs and improving the spec. Currently, it works great for astronomers and other folks that need a cheap distribution of time within a second of UT who are fairly technical, but works less well for less technically situations (witness the number of places that get leap seconds wrong and don't care to fix it) and for less well connected environments. A better analogy to the Gregorian calendar would be to have a leap second every 18 months for the next 100 years, with the next schedule to be published after 50 years for the hundred years after that. The problems with the Gregorian calendar on on the scale of thousands of years. > B) Designing a good and modern "date and time metadata server" Assuming internet connectivity may be problematic for some applications. ensuring that other distribution of time channels are augmented to include better leap data (GPS has current leap info, but no historical leap info, for example). > C) Cleaning up the c and POSIX specs The time guys were kicked out of the posix committee, so good luck on that one. :( And it isn't so much cleaning up the standard, which could be solved with some diplomacy, tact, etc. It is cleaning up all the code that's extant that assumes all days always have 86400 seconds, or that the formulas in the POSIX standard for converting broken up time into time_t are now invalid. The C standard actually is fine, because it is too non-specific to be (a) useful and (b) cause problems. > D) Clarifying timezone guidelines, including standardizing "international > date line", "UTC offset", and methods of "Daylight instantiation" This is really orthogonal to leap seconds. > It took centurys for the Gregorian calendar to be accepted. Hopefully it > won't take as long for society to start using UTC correctly. Hopefully the UTC standard can evolve to match the needs of society better. Taking off my atomic time hat, there are a number of short comings to the standard which could make a time scale with leap seconds that's close to UTC, but through refinements offer better operational performance. ___ LEAPSECS mailing list L
Re: [LEAPSECS] happy anniversary pips
On Feb 12, 2014, at 8:47 AM, Warner Losh wrote: > The linux kernel has been touted by some of its proponents as the most tested > and verified kernel around. Some may quibble with this characterization, but > if not the most, certainly one of the most. And even so, this problem with > leap seconds managed to escape into released kernels. If that happened, here, > what hope is there for other, less well tested systems. There are many much more complex computer science challenges. In fact, the entire purpose of these things called computers is to deal efficiently with hellaciously complicated problems. This problem ain't that intractable. Meanwhile, whatever discussions occur on this list should flow from documented case studies: http://www.cacr.caltech.edu/futureofutc/preprints/files/2_AAS%2013-502_Allen.pdf Not untethered speculation. Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
On Feb 12, 2014, at 9:09 AM, Rob Seaman wrote: > On Feb 12, 2014, at 8:47 AM, Warner Losh wrote: > >> The linux kernel has been touted by some of its proponents as the most >> tested and verified kernel around. Some may quibble with this >> characterization, but if not the most, certainly one of the most. And even >> so, this problem with leap seconds managed to escape into released kernels. >> If that happened, here, what hope is there for other, less well tested >> systems. > > There are many much more complex computer science challenges. In fact, the > entire purpose of these things called computers is to deal efficiently with > hellaciously complicated problems. This problem ain't that intractable. > > Meanwhile, whatever discussions occur on this list should flow from > documented case studies: > > > http://www.cacr.caltech.edu/futureofutc/preprints/files/2_AAS%2013-502_Allen.pdf > > Not untethered speculation. Untethered speculation? Sweet! I've never had my direct, personal experiences in a topic be called that before. Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
On 2014-02-12 07:47 AM, Warner Losh wrote: The linux kernel has been touted by some of its proponents as the most tested and verified kernel around. Some may quibble with this characterization, but if not the most, certainly one of the most. And even so, this problem with leap seconds managed to escape into released kernels. If that happened, here, what hope is there for other, less well tested systems. In my industry we have a timing protocol casually referred to as "timecode", the latest specification is called "ST 12". There's a reasonably good explanation of it at Wikipedia - http://en.wikipedia.org/wiki/SMPTE_timecode. The original designs of this predate the c and POSIX specs, tracing their heritage to IRIG timecode http://en.wikipedia.org/wiki/IRIG_timecode. In the early years of industry deployment it was pretty unreliable. It took years for venders, both hardware and software, to learn how to do it interoperablly. As things progressed, SMPTE revised and refined the specification and eventually everybody was on the same page. It was really 10 years before it all settled down, or "matured". The implementation of UTC in computers spans many standards bodies across many disciplines so its way more difficult in that respect. Its going to take a while. I think the "kill Leap Seconds" call as an unfortunate diversion from concentrating efforts to clarify usage. In my experience in standards bodies the conversation and resources are driven by venders who in turn are presumably responding to their customer's requests but too often the user's opinions get lost in translation. The LEAP_SECS list seems populated mostly by computer "users" (sophisticated users), rather than "manufacturers" or "venders". As a group you all could probably have some influence. -Brooks ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
On 2014-02-12 08:09 AM, Rob Seaman wrote: There are many much more complex computer science challenges. In fact, the entire purpose of these things called computers is to deal efficiently with hellaciously complicated problems. This problem ain't that intractable. Yes. I've never been able to understand why facing the guts of this problem has been evaded. Its a great computer-science project - it should be fun! -Brooks ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
On 2014-02-12 08:03 AM, Warner Losh wrote: On Feb 12, 2014, at 8:03 AM, Brooks Harris wrote: On 2014-02-12 04:36 AM, Greg Hennessy wrote: Um, that is false. All linux kernels did not crash, in fact NONE of mine did. "all" here was an overstatement, but the impact of the leap second should never be "your kernel crashes" even if your personal kernels didn't. You should refrain from making inaccurate claims, it damages your credibility. The fact that the most recent leap second error didn't cause kernel crashes but caused extra cpu cycles to be spent again lowers your credibility. MP is hard, sure, but that's not the root cause of this issue. The root cause of this issue was an error when stepping a clock backwards? Why was the clock stepped backwards? To comply with a POSIX requirement that does not match reality? I submit that the proper fix is to update the spec to match the fact that we now have days that are 86401 seconds long, now to eliminate leap seconds. There is nothing fundamentally wrong with UTC and Leap Seconds - the theory is sound, and the IERS does a fantastic job of keeping track of it. But there are difficulties with implementations for several reasons - A) The specifications and procedures regarding UTC are scattered over many documents and several standards bodies. B) There is no standardized, centralized, and *automated* way to obtain the UTC metadata (Leap Seconds table, announce signals, etc) i'd add 'verified' or 'secure' (since many of the ways involve http:// urls) to this list. Sure. All the related issues. You'd like to see many API's (XML, Binary XML, Soap, etc ) over many channels (Internet, private network, satellite, etc). If a core data set were designed that would be a start. C) There are well know inadequacies with c and POSIX specs with regard to Leap Seconds which have percolated through the computer industry. D) Timezones are a horrendous mess, if somewhat mitigated now by IANA's administration of tz database. E) Leap seconds are tied to observations of the earth's spin, rather than predicted years in advance. With only 6 months warning for leap seconds, this produces operational difficulties for many environments that have burdensome change control policies. Long term, we have the ability to predict out decades what the proper rate of leap seconds should be to keep things in sync over the long haul. One of the nice things about the Gregorian calendar is that it accepts errors of up to like 3 days (worst case) to keep the over all system simple (every 4 except 100 except 400) and on track for millennia. Leap seconds, as currently implemented, require too much "phone home" to keep things on track. The IERS's ability to adjust UTC to +-0.9s of TAI is an incredible achievement. Its unpredictable, but that's fundamentally the nature of the beast. Lets deal with it. Its not hard to imagine some standardized way of stating how far in the future predictions are accurate and how far off they might likely be beyond that. "Eliminating Leap Seconds" doesn't begin to address the implementation difficulties. By itself it would likely make things (much) worse. Instead, all this passion could be directed at - A) Cleaning up and consolidating the UTC specs and improving the spec. Currently, it works great for astronomers and other folks that need a cheap distribution of time within a second of UT who are fairly technical, Yes. but works less well for less technically situations (witness the number of places that get leap seconds wrong and don't care to fix it) and for less well connected environments. But its hard to fix in the absence of clear specification, so they really can't. A better analogy to the Gregorian calendar would be to have a leap second every 18 months for the next 100 years, with the next schedule to be published after 50 years for the hundred years after that. The problems with the Gregorian calendar on on the scale of thousands of years. Sure, but UTC handling, if flawed, is now embedded in the culture, like Gregorian calendar. Maybe the flaws can be fixed. B) Designing a good and modern "date and time metadata server" Assuming internet connectivity may be problematic for some applications. ensuring that other distribution of time channels are augmented to include better leap data (GPS has current leap info, but no historical leap info, for example). Yes. The metadata needs to be distributed over many APIs and channels. C) Cleaning up the c and POSIX specs The time guys were kicked out of the posix committee, so good luck on that one. :( And it isn't so much cleaning up the standard, which could be solved with some diplomacy, tact, etc. It is cleaning up all the code that's extant that assumes all days always have 86400 seconds, or that the formulas in the POSIX standard for converting broken up time into time_t are now invalid. Yes, but it all needs to be reengaged. Certainl
Re: [LEAPSECS] happy anniversary pips
On Feb 12, 2014, at 9:54 AM, Brooks Harris wrote: > On 2014-02-12 08:09 AM, Rob Seaman wrote: >> >> There are many much more complex computer science challenges. In fact, the >> entire purpose of these things called computers is to deal efficiently with >> hellaciously complicated problems. This problem ain't that intractable. >> > Yes. I've never been able to understand why facing the guts of this problem > has been evaded. Its a great computer-science project - it should be fun! The problem stems not because one person can't climb the complexity hill to get it right: several have. The problem comes more from the large numbers of people in my industry that have failed to climb the complexity hill due to apathy, incompetence or both. Coupled with the 'it is only a second' attitude that prevails, these problems make it extremely difficult to build a system based on any third party components that gets things right, especially with the standards stacked against you... Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
Hi Warner, You’ll note that this particular email is addressed to you. Most contributions to this mailing list are not personally addressed. In those cases one might reasonably infer that other messages were intended as general contributions to a common forum. > On Feb 12, 2014, at 9:09 AM, Rob Seaman wrote: > >> Meanwhile, whatever discussions occur on this list should flow from >> documented case studies: >> >> >> http://www.cacr.caltech.edu/futureofutc/preprints/files/2_AAS%2013-502_Allen.pdf >> >> Not untethered speculation. > > Untethered speculation? Sweet! I've never had my direct, personal experiences > in a topic be called that before. As are many of those reading this, I’m fitting time for the forum into a packed schedule of other activities. Since the list has been busy lately it is hard to keep up with all the talking points. Some of these correspond to things with which I disagree, but have no time to address. On more than one occasion lately I have therefore chosen to reference the many previous discussions on this list or its precursor, as well as the proceedings of the two meetings we organized in 2011 and 2013 precisely to discuss these topics. Assertions on a mailing list, not just yours alone, may be called untethered if they don’t reference prior work, here and elsewhere. In particular, Steve Allen’s paper is the most complete exploration of the topic in question, and itself references a variety of resources well worth reviewing. Many talking points here have indeed been speculative. Those who believe in hiding the signature of the synodic day within a shell game of ever shifting timezones could certainly arrange for prudent research to either demonstrate or demolish such a scheme. Absent such studies the notion is speculation. It is not speculation, however, to point out that this notion forms no part of the actual ITU proposal, which is focused on redefining UTC to no longer serve as Universal Time, not on the remedies for such action. Those who need access to interval timescales already have such access. What the proposal does, rather, is deny access to the current solar timescale, an issue not directly related to the timezone system. One might therefore infer that the entire discussion of timezones is a ploy to achieve a short term political end, but that would be speculation. Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
[LEAPSECS] leap second issues in linux kernel
On Wed 2014-02-12T11:22:57 -0700, Rob Seaman hath writ: > > On Feb 12, 2014, at 9:09 AM, Rob Seaman wrote: > >> Meanwhile, whatever discussions occur on this list should flow from > >> documented case studies: > >> > >> > >> http://www.cacr.caltech.edu/futureofutc/preprints/files/2_AAS%2013-502_Allen.pdf > In particular, Steve Allen's paper is the most complete exploration > of the topic in question, and itself references a variety of resources > well worth reviewing. For completeness, I recently encountered an earlier list of linux kernel leap issues at http://winningraceconditions.blogspot.com/2012_07_01_archive.html I haven't checked to see how much overlap is in the lists. Note that as of this week there are still linux kernel patches that mention leap second issues http://www.spinics.net/lists/stable/msg35597.html -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory--ISB Natural Sciences II, Room 165Lat +36.99855 1156 High StreetVoice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
On 2014-02-12 09:46 AM, Warner Losh wrote: On Feb 12, 2014, at 9:54 AM, Brooks Harris wrote: On 2014-02-12 08:09 AM, Rob Seaman wrote: There are many much more complex computer science challenges. In fact, the entire purpose of these things called computers is to deal efficiently with hellaciously complicated problems. This problem ain't that intractable. Yes. I've never been able to understand why facing the guts of this problem has been evaded. Its a great computer-science project - it should be fun! The problem stems not because one person can't climb the complexity hill to get it right: several have. The problem comes more from the large numbers of people in my industry that have failed to climb the complexity hill due to apathy, incompetence or both. Sure, but its hard in the absence of standards as you say, so apathy might be avoidance. Its not hard to be incompetent here either - you really have to study carefully to get all the pieces straight, and then you're still left with loose ends. Its frustrating. Coupled with the 'it is only a second' attitude that prevails, Yeah, thats the one I don't get. You'd think engineers would strive for accuracy. But if it looks like a death march they are likely to make excuses to avoid it, I'd guess. these problems make it extremely difficult to build a system based on any third party components that gets things right, especially with the standards stacked against you... Its the lack of clarity in the standards together with the long legacy of flawed implementations for many reasons that makes the political landscape so daunting. But the problem has such broad consequences I can't believe people don't want to solve it. I think the ITU needs more than "why Leap Seconds should be retained". They need something like "here's a better way to explain it and a better way to disseminate it". And the computer industry needs champions of the approach to lead refinements of API specs, etc. With that it might take hold and the implementations would mature. -Brooks ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] leap second issues in linux kernel
On Feb 12, 2014, at 11:41 AM, Steve Allen wrote: > On Wed 2014-02-12T11:22:57 -0700, Rob Seaman hath writ: >>> On Feb 12, 2014, at 9:09 AM, Rob Seaman wrote: Meanwhile, whatever discussions occur on this list should flow from documented case studies: http://www.cacr.caltech.edu/futureofutc/preprints/files/2_AAS%2013-502_Allen.pdf > >> In particular, Steve Allen's paper is the most complete exploration >> of the topic in question, and itself references a variety of resources >> well worth reviewing. > > For completeness, I recently encountered an earlier list of linux > kernel leap issues at > http://winningraceconditions.blogspot.com/2012_07_01_archive.html > I haven't checked to see how much overlap is in the lists. "An obvious zeroth-order conclusion: There were/are disproportionately many disastrous race conditions in the leap second code simply because it's such an infrequently-executed codepath. Hence, there's a call for some extra form of verification apart from "run the code as it is" - whether it's code-coverage-based stress tests, symbolic execution, or static analysis. I think static analysis would do best here." Which is basically what I've been trying to say. Given that this keeps repeating itself over time by people that are quite smart adds credence to my assertion that the more average folks are in for even bigger issues if they come near this area... > Note that as of this week there are still linux kernel patches > that mention leap second issues > http://www.spinics.net/lists/stable/msg35597.html interesting :) Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
On Feb 12, 2014, at 11:22 AM, Rob Seaman wrote: > Hi Warner, > > You’ll note that this particular email is addressed to you. Most > contributions to this mailing list are not personally addressed. In those > cases one might reasonably infer that other messages were intended as general > contributions to a common forum. Yea. >> On Feb 12, 2014, at 9:09 AM, Rob Seaman wrote: >> >>> Meanwhile, whatever discussions occur on this list should flow from >>> documented case studies: >>> >>> >>> http://www.cacr.caltech.edu/futureofutc/preprints/files/2_AAS%2013-502_Allen.pdf >>> >>> Not untethered speculation. >> >> Untethered speculation? Sweet! I've never had my direct, personal >> experiences in a topic be called that before. > > As are many of those reading this, I’m fitting time for the forum into a > packed schedule of other activities. Since the list has been busy lately it > is hard to keep up with all the talking points. Some of these correspond to > things with which I disagree, but have no time to address. On more than one > occasion lately I have therefore chosen to reference the many previous > discussions on this list or its precursor, as well as the proceedings of the > two meetings we organized in 2011 and 2013 precisely to discuss these topics. Yea, I'd hoped to attend those, but they were held in locations the advance notice of the meeting precluded my attendance. > Assertions on a mailing list, not just yours alone, may be called untethered > if they don’t reference prior work, here and elsewhere. In particular, Steve > Allen’s paper is the most complete exploration of the topic in question, and > itself references a variety of resources well worth reviewing. I wasn't aware that we had to foot-note all the assertions made before they'd be held up to ridicule. they are unreferenced, not untethered. Untethered is rude and implies I'm full of some solid brown substance that typically doesn't smell good if a third party produced it Ask for references instead of being insulting. Geeze. > Many talking points here have indeed been speculative. Those who believe in > hiding the signature of the synodic day within a shell game of ever shifting > timezones could certainly arrange for prudent research to either demonstrate > or demolish such a scheme. Absent such studies the notion is speculation. It is more than just speculation. One can demonstrate that the error between local time and timezone time remains within the same error bars that we have today, as well as demonstrate the frequency of the shift needed. Perhaps that should be something i write up... > It is not speculation, however, to point out that this notion forms no part > of the actual ITU proposal, which is focused on redefining UTC to no longer > serve as Universal Time, not on the remedies for such action. Those who need > access to interval timescales already have such access. What the proposal > does, rather, is deny access to the current solar timescale, an issue not > directly related to the timezone system. One might therefore infer that the > entire discussion of timezones is a ploy to achieve a short term political > end, but that would be speculation. The old proposal I thought was totally dead. The notion there was to have a leap-hour in UTC, which we both agree is a crazy idea... Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
> E) Leap seconds are tied to observations of the earth's spin, rather than > predicted years in advance. With only 6 months warning for leap seconds, > this produces operational difficulties for many environments that have > burdensome change control policies. What do those organizations do when Congress changes the DST rules? Do they work on UTC/GMT so they can ignore DST? They must have to interact with the rest of the world occasionally. How much notice did people get the last time Congress changed the DST rules? I don't pay attention to summer time in Europe. How often do things change over there and/or how much notice do people get when the rules are changed? -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
Warner Losh writes: > > On Feb 12, 2014, at 7:53 AM, Harlan Stenn wrote: > >> Warner Losh writes: >>> >>> On Feb 12, 2014, at 5:36 AM, Greg Hennessy wrote: >>> >> Um, that is false. All linux kernels did not crash, in fact NONE of >> mine did. > > "all" here was an overstatement, but the impact of the leap second > should never be "your kernel crashes" even if your personal kernels > didn't. You should refrain from making inaccurate claims, it damages your credibility. >>> >>> It still doesn't detract from my point: leap seconds caused aberrant >>> behavior in the linux kernel that everybody wants to nit-pick me on, >>> but the nit-picks don't detract from the point. The point is the >>> aberrant behavior, rather than the slight mischaracterizations of >>> that. Geeze, no wonder no progress can be made, people are arguing >>> over the wrong things. >> >> Bad handling and inadequate testing of leap seconds in those kernels >> (and was some of it libc?) caused the aberrant behavior. > > The linux kernel has been touted by some of its proponents as the most tested > and verified kernel around. Some may quibble with this characterization, but > if not the most, certainly one of the most. And even so, this problem with l > eap seconds managed to escape into released kernels. If that happened, here, > what hope is there for other, less well tested systems. The conclusions I draw from the utter lack of any similar reports from non-linux systems are: - either those kernels/libraries did not do leap-second processing, or - they did and their code worked Do you have different conclusions? H ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
On Feb 12, 2014, at 1:50 PM, Harlan Stenn wrote: > The conclusions I draw from the utter lack of any similar reports from > non-linux systems are: > > - either those kernels/libraries did not do leap-second processing, or > - they did and their code worked > > Do you have different conclusions? Yes. Linux is more popular and examined than other systems. Linux is more open than Windows, so bugs there won't be as well publicized. Linux is more popular than FreeBSD, which also handles leap seconds in the kernel. There have been about half a dozen bugs in FreeBSD's leap second handling that I've fixed over the years. The code mostly works, but I'm sure if it were studied in detail some aspect of leap seconds wouldn't be handled pedantically correctly (absolute timeouts for condvars in posix will, for sure, take a second longer to timeout across a leap second boundary). Linux is also has a higher rate of change and rewrite than FreeBSD, which is another reason it gets tripped up by these issues more often. The number of extant linux kernel versions is quite large compared to most other systems as well. With this much change, there's sure to be something overlooked, and quite often it is the "edge" cases, like leap seconds. Other systems are less open, and sweep this data under the rug is also a valid conclusion. Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
Warner Losh said: >> Yes. I've never been able to understand why facing the guts of this problem >> has been evaded. Its a great computer-science project - it should be fun! > > The problem stems not because one person can't climb the complexity hill to > get it right: several have. The problem comes more from the large numbers of > people in my industry that have failed to climb the complexity hill due to > apathy, incompetence or both. Or they (or their bosses) have done a cost-benefit analysis and concluded it's not worth fixing. -- Clive D.W. Feather | If you lie to the compiler, Email: cl...@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646 ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
Hal Murray said: > I don't pay attention to summer time in Europe. How often do things change > over there and/or how much notice do people get when the rules are changed? The EU has standard rules defined in a Directive. The present Directive is 2000/84/EC and was published in the Official Journal on 2001-02-02. It took effect from March 2002. That Directive didn't actually change the rules; the last one that did was 97/44/EC, which changed the autumn rule from "fourth Sunday in October" to "last Sunday in October". This appeared in the OJ on 1997-08-01 and gave the rules for 1998 to 2001 inclusive. So we're talking a year or so lead time. -- Clive D.W. Feather | If you lie to the compiler, Email: cl...@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646 ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
Brooks Harris said: > D) Clarifying timezone guidelines, including standardizing > "international date line", "UTC offset", and methods of "Daylight > instantiation" Um, timezones are a political matter pure and simple. Who do you think is going to listen to you? -- Clive D.W. Feather | If you lie to the compiler, Email: cl...@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646 ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Pedagogy & Greenwich
Ian Batten said: >> The easternmost point of the London district of Greenwich is a the >> intersection of two roads, Maze Hill and Charlton Way. The coordinates are >> 51° 28.509' N, 0° 0.602' E > > I'm not sure what you're using as a definition of "district". SE2 0AT is in > the > Royal Borough of Greenwich, and is 51° 28' 57.8442"N, 0° 7' 15.0053"E. > There are places slightly east of there that are also in the Borough. Google Maps seems to think that the easternmost point of the Borough is the intersection of Brampton Road and Longleigh Lane. This is at 51.477106,0.123897. Streetmap (using the OS maps) agrees and gives me coordinates of: OS X (Eastings) 547590 OS Y (Northings)177498 Nearest Post Code DA7 5SE Lat (WGS84) N51:28:38 (51.477194) Long (WGS84)E0:07:26 (0.123860) LR TQ475774 -- Clive D.W. Feather | If you lie to the compiler, Email: cl...@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646 ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Pedagogy & Greenwich
On 12 Feb 2014, at 22:22, Clive D.W. Feather wrote: > Ian Batten said: >>> The easternmost point of the London district of Greenwich is a the >>> intersection of two roads, Maze Hill and Charlton Way. The coordinates are >>> 51° 28.509' N, 0° 0.602' E >> >> I'm not sure what you're using as a definition of "district". SE2 0AT is in >> the >> Royal Borough of Greenwich, and is 51° 28' 57.8442"N, 0° 7' 15.0053"E. >> There are places slightly east of there that are also in the Borough. > > Google Maps seems to think that the easternmost point of the Borough is the > intersection of Brampton Road and Longleigh Lane. Indeed. It's something of a mystery which map the original writer was using to make their claims about the "London district of Greenwich" having its eastern limit boundary at Maze Hill and Charlton Way (by the war memorial), or what sort of "district" is being discussed. That's the not even the eastern limit of the westernmost ward of the Borough of Greenwich, which has its eastern limit at Maze Hill's junction with Shooter's Hill Road, slightly south east of the junction with Charlton Way as [3] shows. In terms of postal districts, SE10 extends much further east, to the eastern side of the Blackwall Tunnel Approach Road, east of Westcombe Park station (see [1] [2]). One list [4] implies that SE10 incorporates the historic (pre-1970) postal district of Lewisham, but that's to the south and therefore wouldn't impose an eastern boundary, and a 1:5 map which normally shows all extant legal boundaries doesn't show any boundaries of any description at the cited war memorial. Perhaps someone could explain the original claim: it doesn't match borough boundaries, ward boundaries or postal boundaries, so what is the "district" that is being described? ian [1] http://www.free-postcode-maps.co.uk/postcode-maps/postcode-area/se-london-postcode-map.php#.Uvv6zXnlJhg [2] http://www.streetmap.co.uk/map.srf?x=538910&y=177914&z=0&sv=se10&st=2&pc=se10&ar=N&mapp=map.srf&searchp=ids.srf&sq=1 [3] http://www.royalgreenwich.gov.uk/info/200033/councillors_democracy_and_elections/598/find_your_councillor [4] http://www.maps.thehunthouse.com/Streets/London_Postal_District_and_Area_Name_finding_aid.htm ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
Back in the 1974 oil crisis the US made an 'emergency' change to its DST schedual. I don't recall the legal mechanism used. It was likely an executive order from the President. But it most definitely was with less than 6 months notice so the legal precedent is exists in the US. I also have noticed that 'critical security patches', to which linux is less prone than some operating systems, often require action in less than 6 months from the time issued. Richard Clark rcl...@noao.edu On Wed, 12 Feb 2014, Hal Murray wrote: E) Leap seconds are tied to observations of the earth's spin, rather than predicted years in advance. With only 6 months warning for leap seconds, this produces operational difficulties for many environments that have burdensome change control policies. What do those organizations do when Congress changes the DST rules? Do they work on UTC/GMT so they can ignore DST? They must have to interact with the rest of the world occasionally. How much notice did people get the last time Congress changed the DST rules? ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
Warner Losh writes: > > On Feb 12, 2014, at 1:50 PM, Harlan Stenn wrote: > > The conclusions I draw from the utter lack of any similar reports from > > non-linux systems are: > > > > - either those kernels/libraries did not do leap-second processing, or > > - they did and their code worked > > > > Do you have different conclusions? > > Yes. > > Linux is more popular and examined than other systems. Linux is more > open than Windows, so bugs there won't be as well publicized. Linux is > more popular than FreeBSD, which also handles leap seconds in the > kernel. There have been about half a dozen bugs in FreeBSD's leap > second handling that I've fixed over the years. The code mostly works, > but I'm sure if it were studied in detail some aspect of leap seconds > wouldn't be handled pedantically correctly (absolute timeouts for > condvars in posix will, for sure, take a second longer to timeout > across a leap second boundary). Doesn't pass my "smell" test. I know lots of folks who run Windows, nobody reported seeing this problem there. I run FreeBSD on *lots* of boxes, many different versions. None of them saw this. We're not talking about pedantically correct, we're talking about locking up the box. > Linux is also has a higher rate of change and rewrite than FreeBSD, > which is another reason it gets tripped up by these issues more > often. The number of extant linux kernel versions is quite large > compared to most other systems as well. With this much change, there's > sure to be something overlooked, and quite often it is the "edge" > cases, like leap seconds. So you are saying that Linux is a paragon of quality and design and development, and as proof of this you offer a painful screwup as "the exception that proves the rule"? > Other systems are less open, and sweep this data under the rug is also > a valid conclusion. That implies their customers didn't write about it or complain to anybody. I think I don't have anything more to add to this discussion. H ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] leap second issues in linux kernel
> whether it's code-coverage-based stress tests, symbolic execution, or static > analysis. I think static analysis would do best here What's the state of tools to find things like nested locks? (Assume I'm willing to annotate the code to help.) -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
