On 2013-08-14, David Malone <[email protected]> wrote: > unruh <[email protected]> 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) > > David. _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
