[LEAPSECS] W1K GPS rollover for some time servers

[Martin Burnicki]

Hi Tom,

Tom Van Baak wrote:
>> As seen at
>> http://lists.ntp.org/pipermail/hackers/2015-May/006866.html
>> and also as experienced at Keck Observatory last night, some models
>> of GPS time servers just did their firmware's W1K rollover, so those
>> are saying the date is 1995-09-17.
>>
>> But the leap second is, inappropriately, getting the blame!
>
> Steve,
>
> No need to take it personally. At some level it doesn't matter if
> it's leap seconds, or the GPS spec, or one GPS manufacturer, or one
> particular GPS receiver model, or one OS, or one line of code that
> doesn't handle rollover correctly. To the person who wants and
> expects time to work right, it's all the same. And any of us who work
> with precise time are part of the problem and share the blame.

Hm, in my opinion this is somewhat similar to when a good product sold 
via an online shop gets a bad rating even though the product itself is 
very good, but it took very long for the vendor to ship the product.

Of course leap seconds can cause lots of trouble, but nevertheless it's 
not OK if the leap seconds are blamed for every firmware bug.

I've recently seen a 3rd party GPS puck which applied the UTC correction 
parameters wrong, and thus the generated 1 PPS signal was off by more 
than 1 microsecond. After a discussion with the manufacturer it turned 
out that they had computed the time (t - t0t) from the UTC correction 
parameters wrong during a certain week number and thus the polynomial 
which computes the time correction returned a wrong value.

Even though these correction parameters are in the same parameter set 
the UTC seconds offset, this is not related to leap seconds, just to 
incorrect handling of the week numbers.

So eventually week numbers should also be avoided since some developers 
are unable to work with them correctly. ;-))

> What you can do is represent the astronomical community and do what
> you can in your professional career to promote clean, robust, and
> redundant timekeeping. That can either be passive education or active
> steering the future away from sextants, s/w radio, and other outdated
> methods of astronomical timekeeping. That doesn't make problems
> vanish right away, it helps reduce risk in the future.
>
> As you know the GPS folks enlarged the 10-bit week number in the next
> signal spec so receiver manufacturers have less rope to hang
> themselves. One step at a time, but at least it's a step.
>
> The shame in today's example rests on makers of TymServe 2100, who
> either didn't test their firmware, or who knowingly allowed a product
> to have this bug. And worse yet, are now refusing to support it,
> because it's "out of warranty". Hopefully a two-line fix to NTP can
> be used to get around the bug. OTOH, I can't believe the Keck guys
> are reliant on a single GPS receiver for their time? May I bring them
> another clock or two for them to use?

Isn't the TymServe 2100 just using a GPS puck from a different 
manufacturer? Then the manufacturer of the TymServe has to rely on the 
GPS puck to work correctly, and the manufacturer of the GPS puck is to 
blame, and the TymServe guys don't even know if the GPS puck will show 
up with some other bug at some time.

Of course it's also a shame that the TymServe manufacturer just says the 
device is out of support.

Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burnicki at meinberg.de
Phone: +49 (0)5281 9309-14
Fax: +49 (0)5281 9309-30

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, 
Andre Hartmann, Heiko Gerstung
Web: http://www.meinberg.de