[LEAPSECS] Reliability (was Re: it's WP7A week in Geneva)

[Rob Seaman]

Tom Van Baak wrote:


>> when all is said and done).  A 12.5 minute down time means your  

>> annual reliability can only be 4 9's, not 5 9's...  This is why  

>> many receivers remember the last UTC offset values and warm start  

>> with them if they have only been off a short period of time...

>> Warner

>

> User code can usually handle being told by a GPS receiver that "UTC  

> is not known yet; use GPS time instead". But when a GPS receiver  

> says "sorry, by the way, all the UTC time stamps

> I've sent you in the past quarter hour were off by one second", that  

> might be a little more trouble to deal with.


Could somebody comment on the reliability of GPS receivers to deliver  
GPS time itself?

It is clearly aberrant design for any system to ever lie about a  
return value.  This is why error handling exists.  There are any  
number of quite desirable reasons a specific model of GPS receiver  
might be designed to behave idiosyncratically.  If there is no  
separate channel to convey errors properly, then it should at least  
return a non-legal value (-1 or such) pending this 12.5 minute start- 
up interval.  The three behavioral issues (choice of timescale,  
potentially lengthy initialization procedure, proper error handling)  
are orthogonal.

That said, client applications often have to deal with less than  
perfect hardware or software components.  In this case it sounds like  
the app (or a system like NTP) would be wise to manage restarts by  
marking a restarting receiver as invalid for 12.5 minutes (or until  
some other condition is met).  I'm sure I'm about to hear why this is  
a naive statement :-)

However, is it a true assertion that currently deployed GPS receivers  
return GPS time significantly more reliably (all those 9's) than they  
do UTC?  (Assuming a particular model supports both?)

It's hard to see this as supporting a position that "Only UTC can be  
disseminated"...

Rob