[ntp:questions] Start of new GPS 1024 week epoch
magnus at rubidium.dyndns.org
Sun Aug 18 08:19:55 UTC 2013
On 08/18/2013 07:51 AM, David Taylor wrote:
> On 17/08/2013 18:31, Magnus Danielson wrote:
>> 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
> It will be interesting to see what folks come up with for the patch.
> I must admit to feeling that a fault in GPS receivers should /not/
> have to be fixed in NTP, but I accept that's likely to be the best
> It should certainly be an option that has to be specifically enabled
> (command-line switch or fudge command), and one which has no impact
> otherwise on the reliability and maintainability of NTP.
But this isn't an actual "receiver bug" in that context. The receivers
can't always to the right thing.
If a receiver has backup-power, then it can remember from different
power-ups the latest year, and that's enough to "guess right". Trouble
is that most receivers don't have that installed, and most of them
having it isn't using that knowledge anyway to resolve it.
The problem is that it is a system bug (misfeature really), for which
some receivers have more or less smart ways of dealing with, and we need
to make handle the case when their ways of fixing it does not work
anymore. Thus, we are really talking about patching on a patch, which is
ugly, but if you want continuous operation that is what it takes.
If you want this feature to be disabled by default, you end up with
causing the disruption that the fix is there to avoid. Few will know
that they need to fiddle with that bit, and it becomes a continuous
support thing, rather than letting the default being that it fixes the
problem and then let the really cautious people turn it off. Default
disabled is a bad idea.
Yes, you change the default behaviour of NTP this way, but it's done
because it has been analyzed and it's more likely to fix a problem than
cause a problem for the majority of the users.
More information about the questions