[LEAPSECS] [time-nuts] Leap Quirks

[M. Warner Losh]

In message: <51302552-875A-4E99-937C-BDBA26AE0BBD at noao.edu>
            Rob Seaman <seaman at noao.edu> writes:

: Tony Finch wrote:

: 

: > On Mon, 5 Jan 2009, Rob Seaman wrote:

: >>

: >> The recent leap second passed (yet again) with no major issues.

: >

: > Wrong.

: >

: > Loads of Oracle RAC servers crashed because of a bug triggered by the

: > clock going backwards.

: >

: > http://www.merit.edu/mail.archives/nanog/msg13857.html

: 

: Where the statement is:

: 

: 	"I had a couple of Oracle servers (Solaris 10) reboot a couple of  

: minutes just before the leap second. All my other Solaris 10 boxes  

: appear to have stayed up fine."

: 

: The phrasing doesn't even make it clear that this was causally  

: connected to the leap second.  I assume that later messages in the  

: thread clarify this.


Yes.  When time goes backwards, like ntpd forces for a leap second,
oracle servers reboot.


: It might help to standardize a definition of "major issue".  Our group  

: uses JIRA to track issues.  We have two levels above major issue,  

: namely "critical" and "blocker".  Leap seconds are clearly not a  

: blocker, since we have moved past this one just like the previous  

: ones.  Given that the current standard is viable for hundreds of  

: years, it is also hard to rate them as critical.


The Oracle bug is a critical bug.  It is a show stopper for anybody
that wants to keep up time high (which is everybody).  Saying that you
are forcing people to reboot just because there's a leap second is
clearly wrong.  It should have been fixed before the last one, and
needs to be fixed before the next one.  Trouble is that they are rare
enough that people think they have all the time in the world.  So they
get bumped down in priority and forgotten when the 6-month warning
comes.

I'm not sure that I'd rate the current system as 'viable' except in
the narrowest definition of the word meaning "the DUT1 drift rate
means we'll not likely need more than 2 leaps a year for hundreds of
years."


: > Many time dissemination systems got it wrong, as usual.

: >

: > I wonder why OS vendors don't ship ntpd preconfigured with a  

: > leapseconds

: > table that is updated as part of the OS's normal patching process. I  

: > hope

: > that would reduce the amount of manual maintenance required for  

: > stratum 1

: > servers and increase the reliability of NTP's leap second handling.

: 

: Sound like good ideas.  Fix the bug.  Improve the processes.


Let's make the disease more tolerable by frequent shots of whiskey. :)


: > Obviously leap seconds are so important that we can't do without them,

: > but so unimportant that it doesn't matter that we can't get them to

: > work properly.

: 

: Stabilizing civil time with respect to the slowly evolving diurnal  

: rate is important.  You say so yourself:

: 

: 	http://catless.ncl.ac.uk/Risks/25.50.html#subj1


I don't say so :).  And even if I did, there's better ways than the
currently implemented leap seconds to do it.  It is clearly showing
signs of strain...

Also, stopping the accumulation of leap seconds does not necessarily
mean that civil time will drift beyond tolerance of people since time
zones are a lot easier to adjust...  What the heck do I care if we're
6 hours behind UTC or 7, just so long as everybody I have to deal with
in my local area agrees.


: If leap seconds are truly failing to satisfy a requirement for  

: ignorability, we have mentioned many different possibilities over the  

: years for stabilizing civil timekeeping.

: 

: The ITU proposal to simply ignore the whole thing for a thousand years  

: is not one of these.


I think that this is actually a good thing.  We've only had precision
atomic time keeping for like 50 years.  We've only had leap seconds
for 35 years.  At best we have data for maybe a couple of hundred
years of the length of day trends with any high precision.  We have OK
data ranging back only a couple of thousand of years (average changes
based on the drifting of eclipses).  With this paucity of data, I'm
not sure that we can do planning for thousands of years.  Especially
since we know that our dance partner is fickle and prone to
tantrums...

Warner