[LEAPSECS] leap smear

[Joe Gwinn]

At 9:10 PM +0000 9/18/11, Poul-Henning Kamp wrote:

>In message <p06240806ca9c0133039d@[192.168.1.101]>, Joe Gwinn writes:

>>At 7:56 PM +0000 9/18/11, Poul-Henning Kamp wrote:

>>>In message <p06240805ca9bf8bc07d3@[192.168.1.101]>, Joe Gwinn writes:

>

>>Not really.  The problem with leap seconds is that they are too rare

>>to allow for comprehensive testing of systems, and so such systems

>>tend to fail when a leap second comes along.

>

>The fundamental problem is that a vast majority of the worlds

>software is written as if leap seconds simply do not exist.

>

>The fact that they do, are horribly expensive to test, and tend not

>to get tested because *recently* they have not happened a lot, is

>merely icing on the cake.

>

>>What saved the software is that it is fed

>>only rotating-antenna data, with about 12 seconds between updates, so

>>plus/minus one second wasn't that big a fractional error.

>

>In the ATC system I was involved in, radar data is collected from

>an number of radars in a number of countries and glued togther

>to form a coherent image for presentation.  As far as I recall,

>the timestamp resolution from the radars are 1/128th second.


Actually, the resolution of the software I mentioned is at least that 
good, basically limited by the accuracy of the state vectors provided 
by the radars, many of which are ancient.  But a one-second jump is 
the same regardless.

I've been out of ATC for many rears now, but at least some systems 
use GPS System Time (not UTC) within, thus sidestepping the whole 
leapsecond issue.



>(On one of the runways, certain large planes have not completed

>wheels-up by the time they are in a different countrys air-space.

>This complicates matters so much, that it was one of the main

>reasons to establish joint airspace between the two countries.)


Luxemburg?



>Their solution for leapseconds, for which the system as a whole has

>not been tested, is that they announce to all planes in their

>air-space that they are "on their own, to remain on course until

>further notice" and then they wait for the light-show to calm down.


That also works.



>Modern planes move 300m/s and with P-RNAV, anticollision detection

>is set to pretty hysterical tolerances, so planes jumping 300m

>forward or backward is reason for blinkenlights.


Yep.  A good reason not to use UTC, at least not in the core.

I developed the algorithm for CA (Collision Avoidance) in an ATC 
system 15 years ago, based on a FAA algorithm from the 1970s that was 
being updated to handle far higher traffic densities.  The algorithm 
predicted ahead by two minutes, and warned if any pair of tracks 
would approach closer than something like two nautical miles (if at 
the same altitude) in that period.  A one-second jump would not have 
been a problem then.  The big issue, and what I spent most of my time 
on, was cutting the false alarm rate down to a reasonable level, so 
people would not just disable the CA algorithm because of all the 
false alarms.  This was achieved by use of far more precise 
computations than the computers of the 1970s could handle.

The two-minute limit was a compromise between early detection and 
false alarms due to aircraft maneuvers in dense environments such as 
Chicago or NYC.  In practice, bad radar and/or transponder data was 
the next largest source of false alarms.



>Fortunately, leap-seconds happen in the middle of the night here,

>so there is no commercial passenger traffic in the airport, only

>a couple of DHLs, FEDEX etc.


But what about the other side of the World?



>I'm sure LAX or HND will have much more fun, once they get a

>modern ATC system.


Someday.



>  >I bet it is known, even if we two don't know it.  And the stated

>>reason would be interesting.

>

>I'm sure it's known, and I think the reason is either somebody

>uninformed panicing, on somebody well-informed panicing.

>

>I'd like to know which it is.


Yes.  Perhaps someone on the reflector can tell us the story.


Joe Gwinn