[ntp:questions] Start of new GPS 1024 week epoch
unruh at invalid.ca
Wed Aug 14 13:59:39 UTC 2013
On 2013-08-14, David Malone <dwmalone at walton.maths.tcd.ie> wrote:
> unruh <unruh at invalid.ca> writes:
>>Surely if the receiver is delivering the wrong date, it is the receiver
>>manufacturer that needs to make the changes, not ntp, including sending
>>you a new receiver if necessary. Warrenty limits notwithstanding, this
>>fails that "fitness for purpose" test, and you could hardly have
>>detected it when you bought it.
> Certainly - though the company I bought mine from is long gone, and
> I wanted more time to think about replacement options.
>>Except of course if the rd_timestamp.l_i is way out (that is why one
>>would want to use a gps clock to fix it-- eg on bootup with the
>>Raspberry Pi say),
> Indeed - you need to have a timestamp within about ten years of
> correct before you start up, otherwise the problem will be worse.
> Ntp has the same problem in figuring out the ntp epoch, though we've
> yet to see an ntp timestamp wrap around.
Agreed. But then by the time the wraparound occurs, ntpd may for example
be using 64 bit integers rather than 32. (of course I am giving far more
credit to the chances for incompatibly altering the software than they
probably deserve-- once a design decision has been make, it tends to
stick around long after the reasons have evaporated. Look at the
problems getting IPV6 going, even though the "wraparound" in that case
is here now. People wouuld rather pile NAT upon NAT rather then switch)
More information about the questions