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: [email protected]
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
_______________________________________________
LEAPSECS mailing list
[email protected]
https://pairlist6.pair.net/mailman/listinfo/leapsecs
