Scroll down for my response. Context seemed important.
On Dec 20, 2008, at 11:33 AM, M. Warner Losh wrote:
In message: <d754ef5c-767a-4ff0-ac64-6e9543aaa...@noao.edu>
Rob Seaman <sea...@noao.edu> 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).
You are arguing with Poul-Henning, not with me.
Just a reminder that not only are astronomers big-time customers for
*both* high precision interval timescales *and* high accuracy earth
orientation timescales, but we *also* have some of the more bizarre
requirements for high reliability, remotely located, long shelf life
systems such as you describe.
Again - why are engineering best practices regarded as an annoyance?
If the real world places a requirement on a system (like - SI seconds
are not civil seconds), then a better solution will result from
actually designing this into the system up front. Perhaps this will
require an update every 6 months. Perhaps it can be longer than
that. Perhaps autonomous, adaptive scheduling can be built in.
Trying to pretend the requirement doesn't exist is naive decision-
making at its worst. One can't claim that systems resulting from such
a decision-making process have been engineered in any real sense at all.
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.
What are those cases? Use cases drive requirements. If we weren't
perpetually trying to squelch the inappropriate rush to a decision of
the ITU, we could focus on the actual system engineering issues.
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 are describing another requirement for untended operation.
Requirements aren't a zero-sum game with one winning over another.
Rather, a coherent set of requirements have to all be honored in a
conforming solution. I said the exact opposite of demanding that they
update. However, if as PHK says, many systems have to update
frequently, those that do could use this as an opportunity to update
broad categories of data tables - not just leap seconds. Those small
number that can't use this commercial update regime, will still
benefit from following a coherent plan.
Truly untended, unnetworked systems likely have no requirement to use
UTC in the first place. An instrumentality of mankind that is
disjoint from the rest of civilization may need timekeeping, but
likely doesn't need civil timekeeping.
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.
Customers pay for solutions. Solutions require problems to be
defined. That definition benefits from engineering. A customer might
attempt to specify an engineering process. (Although it seems more
likely that they would specify some widely known best practice
engineering process, rather than some ad hoc abrogation of same.) A
vendor or engineering firm should take the customer's specifications
into account when preparing a proposal. A wise engineering firm won't
accept a job with unrealistic strings attached.
I don't believe I've called anybody a moron. I apologize if so.
Otherwise, I am not responsible for the inferences of others to what
truly seem to me to be unremarkable statements regarding the
engineering of systems. Naive solutions are bad. Proper engineering
is the best way to avoid naive solutions. Why is this controversial?
It is my college logic professor you are arguing with if the assertion
is that one should defer to experts simply because they are experts.
However, folks do understand perhaps that the astronomers contributing
to this list are predominately members of the astronomical software
community and are experts themselves?
I'm not sure what "these systems" refers to, but timekeeping has often
been a key element of systems I've designed and deployed. I'm well
aware of the mistakes I've made over the years. My goal is to keep
the ITU from making one big whopper of a mistake revising this general
standard. Unless I sit on a design review for a specific system, I
don't have an opinion about the process design choices for that system.
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.
And several of us from the astronomy software side have expressed
interest in exploring options for lengthening the schedule. My
reading of the current UTC standard is that this might even be
completely acceptable with no ITU or government level changes.
Wouldn't this be even easier and quicker to implement than the goal of
eradicating leap seconds, a goal that cannot (apparently) be reached
before 2019?
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....
And yet that is exactly the case with time zones and daylight saving
adjustments. Any government anywhere can change these far more
visible policies at anytime. The sliding time zone solution would
magnify this reality at a quadratically increasing cadence worldwide.
Rob
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
