David Taylor <david-tay...@blueyonder.co.uk.invalid> wrote: > On 14/08/2013 17:14, David Malone wrote: > [] >> Possibly - this was a handy timestamp to use, but there may be a >> better choice. It's also possible that this should be an optional >> flag to the driver, so that people with perfectly good GPS units >> won't ever trip over the code ;-) >> >> David. > > Yes, I would prefer to see a flag which enables this, with the default > being "off". All being well, the number of NTP installations with > "good" receivers should be increasing over the number with "problem" > receivers.
How does a "good" receiver know the correct time? Does it rely on local (backed-up) storage, or is there some way of receiving it via the almanac? Or are "good" receivers hardwired as well, only with a different valid span? I would not be surprised when "good" receivers turn out to have just a different moment or mode of failure. I think the firmware authors have just coded in arbitrary boundaries where weeknumbers above that boundary are considered to be in the previous week span, and numbers below the boundary are in the current span. This particular firmware just happened to be one of the first in which this effect was noticed. It is like the solution often chosen to convert 2-digit to 4-digit years: all years above (say) 80 are handled as 19xx, below 80 is 20xx. So in 2080 there suddenly is a problem. The difference is that the span is one century in that case, while with GPS it is only 20 years. _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions