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 >> throughout. >> >> Cheers, >> Magnus > > 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 > solution. > > 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. Cheers, Magnus _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
