[ntp:questions] Start of new GPS 1024 week epoch

Magnus Danielson magnus at rubidium.dyndns.org
Sat Aug 17 17:31:58 UTC 2013


On 08/17/2013 06:02 PM, David Taylor wrote:
> On 17/08/2013 09:30, Terje Mathisen wrote:
>> David Taylor wrote:
> []
>>> Thanks for the pointers to the documents.  A pity that they haven't
>>> been
>>> able to find two or three spare bits to reduce the 1024 week ambiguity
>>> to nearer a half-century or even 100 years.  Oh, well!
>>
>> That would be even worse:
>>
>> Exceptional events like the 10-bit week rollover needs to happen often
>> enough that every programmer is forced to write code to handle them
>> correctly, or it should not happen at all!
>>
>> I.e. a fault-tolerant server setup is only fault-tolerant if you are
>> comfortable doing monthly fire drills where you pull the power cord (or
>> network cable(s)) from either half.
>>
>> For GPS 19+ years was probably intended to be long enough that every
>> given receiver would only live to see a single epoch, meaning that a
>> simple test against the firmware generation time would suffice, right?
>>
>> Well, now we've seen a lot of timing receivers that just keep on
>> working, and that 19+ year range turned out to be not quite long enough.
>>
>> If this has happened every year or so (i.e. a 64-week rollover), then
>> every GS would have had some method to enter the current epoch, and a
>> way to remember it across reboots.
>>
>> Personally I think the (Trimble?) hack to use the TAI-UTC offset field
>> as an epoch guess table index is pretty nice:
>>
>> As long as the offset keeps increasing this will suffice to handle at
>> least one or two epoch rollovers.
>>
>> OTOH, the firmware timestamp method I outlined above will work perfectly
>> as long as (a) somebody is still willing to generate new firmware
>> versions and (b) you still have some machine with compatible
>> hardware/software to allow you to load it onto the GPS.
>>
>> Combined remote antenna/GPS receivers with an RS422 or similar
>> connection to an NTP server requires that firmware update capability to
>> be included in the NTP box. :-(
>>
>> Terje
>
> Thanks for your thoughts, Terje.
>
> Using a 12-bit (or even 16-bit) field to send the current year would
> be a preferable solution - at least until they start messing with
> leap-seconds and change the whole time scale.  But I take your point -
> once every 19 years it will be remembered a lot more easily than once
> every 76 years.
>
> Having a multiplicity of different GPS sources from different
> manufacturers may at least improve the chance of the problem being
> spotted.
True. You can make better decisions by looking at more sources, so when
a particular model flips, all the other sources and likelyhood of
flipping makes it reasonable to correct for the systematic effect and
then continue. Most GPS receivers will continue to operate correctly
after a flip, so as long as we correct for the 1024 week flip period, we
can continue to operate.

What might be useful is to store the corrected 1024 weeks offsets, since
if the NTPD is restarted, those corrections can be applied up-front and
then can these corrected values be used to provide good basis for
majority decisions about "correct time". When a particular receiver
flips, then it is the only one (possibly a few of them changing at the
same time) which shift by 1024 weeks, and then it is easy to use the
1024-week assumption as a priori knowledge to correct them. When you
wake up the flipped receivers may form a majority, which would be
unfortunate, as we already know they have flipped, but we forgot it in
the re-start process. Doing this, the system integrity can be maintained
throughout.

Cheers,
Magnus


More information about the questions mailing list