[LEAPSECS] Schedule for success

[M. Warner Losh]

In message: <m3prjlxz5z.fsf at lugabout.jhcloos.org>
            James Cloos <cloos+leapsecs at jhcloos.com> writes:

: >>>>> "Warner" == M Warner Losh <imp at bsdimp.com> writes:

: 

: Warner> You are under the fundamental misimpression that all systems are

: Warner> or can be upgraded every 6 months.  That simply isn't possible

: Warner> for a large class of systems.

: 

: But how many of the systems which do not have such a regular update

: procedure in place care about time?


I'm personally responsible for hundreds.


: Of those who do, how many do not

: use networking to keep their clock?


All of them.


: And of those which are left, how

: many need earth-time-of-day to 1 second accuracy?


1-second accuracy?  They need microsecond level accuracy over periods
of months.


: Are there any left which meet all of those criteria?


All of them.


: Most long-term systems do not care about time of day.


Control applications for timing systems for LORAN-C slaved to GPS *DO*
care about time of day (but not local time of day), because the local
time of day (UTC) must be displayed on the GUI and on the atomic
clocks at the stations.


: Anything which uses a remote system to sync its time is good; leap

: second announcements are part of getting a time sync.


Correct, but only part of the problem.  Leap seconds announcements
aren't given to systems that are powered down.  You might ask 'so
what?' and I'll reply "these are the cold spares kept on sight and at
HQ for CPU failure scenarios."  These systems sit on the shelf for
many years, and then need to work right when plugged in, as quickly as
possible.  Leap seconds mean a CPU failure is at least 1/2 hour while
the GPS receiver (which is also a cold spare) gets the latest
almanac.  This means that your timing system is off the air for 1/2
hour, and in the LORAN chain this is bad.  Of course, things are
mitigated by having two systems so when one is off, the other can take
over.


: Anything which does not require <=1 sec time-of-day accuracy is also

: good.  They simply do not care.

: 

: So what is left?


A large class of systems similar to the LORAN-C timing software.
These systems monitor time, report UTC, but use an internal time scale
without leap seconds to give them a continuous count of seconds.  To
fully come up, these systems need to know the number of leap seconds.
To operate properly, they really need a full table, to ensure that
some historical queries work properly, but the can operate in a
degraded mode when the full table isn't available...

I'll grant that emacs could care less about leap seconds, but we
aren't talking about those systems that don't care.  We are talking
about the ones that do, that need to implement leap seconds, or
interact with them operationally, and the real, observed problems that
many people on this list have experienced first had.

Warner