[ntp:questions] Start of new GPS 1024 week epoch
david-taylor at blueyonder.co.uk.invalid
Sat Aug 17 16:02:38 UTC 2013
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. :-(
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.
More information about the questions