In message: <[email protected]> Rob Seaman <[email protected]> writes: : Poul-Henning Kamp wrote: : : > Steve Allen writes: : > : >> Please identify the operations which need one second predictability : >> over a time span of six months. : > : > Wrong question. : > : > Try: Please identify computer communications where it is not : > guaranteed that all involved computers will have their software : > updated every six months. : : Meant as a bon mot, I guess? Seems to emphasize Steve's point in any : event. : : However, you've actually identified a potential mechanism for : distributing scheduling data of all sorts, including for leap : seconds. Instead of building computer hardware, operating systems and : applications that pretend the relentless update cycle doesn't exist, : build such systems to expect scheduled updates to software and key : data structures. Leap seconds are just one from a large class of non- : static information that needs to be widely shared in common for : infrastructure to work.
Sadly this is well divorced from reality. People can and do build systems that have a long shelf life. It is routine in certain sectors to buy 10 of something and put 8 into the field. The other 2 are spares and sit on the shelf for a long period of time. The software is rarely updated on systems like this (why should it be, they are simple and bug-free enough to run for years). These systems are expected to run for 10 years with < .001% (so called 5 9's) downtime. Upgrades make that nearly impossible to meet. When one fails, another one gets swapped in. Otherwise the system is up all the time. To force an upgrade every 6 months would force a down time, which is unacceptable. It would also, in many cases, for someone to physically go to the location where the systems are running to do the upgrade since many of these systems aren't on public networks (and the private ones are oversubscribed with their current data loads, no room for extra software updates). The non-regularity of leap seconds makes this very hard to do. Even with a GPS receiver in hand, it can be hard to start cold, and there's no way to startup reliably if you've been off as little as one year. These systems routinely exchange data with timestamps, some of which is historical. Without leapsecond knowledge, you get degraded performance. Systems that are off for a year have no clue when the last leapsecond(s) were, unless there weren't any in that time. This can and does lead to degraded performance in some cases. : Perhaps my frequent observations about the wisdom of following system : engineering best practices simply need to be redirected to a broader : class of problem to find more acceptance :-) Except, of course, in this case good system engineering is that these systems will run, unattended (and unnetworked), for years doing the job they need to do. To force them all to upgrade just because of leap seconds is silly. You've constantly poo-pooed the notion that people that have actually written and deployed dozens of these systems know what they are talking about. You all but call such people morons for not following good system engineering practices. Yet, you show a surprising ignorance of how things actually work and of system engineering practices demanded by customers. The root cause of all of this is the irregularity of the scheduling of leap seconds. If they were on a schedule, known years in advance, then these systems could be built. Imagine if you have to find out from the pope every year if this year was going to be a leap year or not? There's all kinds of problems *THAT* would cause, and nobody would debate it.... Warner _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
