Achim Gratz <[email protected]>: > I don't think ntpd needs to do any pivoting _except_ at startup time, where > it is unavoidable and it should attempt to do anything after it has started > up.
Huh? Potentially you need to apply a pivot to every packet that comes in; different sources could even have different epochs. > For setting the initial time you'll want to have as many independent bounds > on the time as you can provide, since you potentially cannot trust _any_ of > the possible sources. Short of an authoritative and trusted time that is > within about 68 years of the true time, the only thing you can do is a > maximum likelyhood estimate and that always means that there is a non-zero > chance to resolve to the wrong NTP era since any assumption that you make > can turn out to be wrong for any number of reasons. True. But it is not clear what we can do about this other than what we are already doing - that is, pull in lots of sources, discard outliers, make a best guess. > One assumption delivering a single bound. The other assumption is that the > system time is already close enough for ntpd to not need to pivot again. > Getting time over HTTPS[*] could deliver a third venue to start doing a > majority vote. > > [*] http://phk.freebsd.dk/time/20151129.html Instead of trying to use this for precise time, we could try using a Date just at startup to figure out what era we are in. > >What's a reasonable life of a program like ntpd? 20 years seems like the > >right ballpark. After that, we have to check the GPS drivers. The magnovox > >driver just checks for before. I haven't checked the NMEA driver. 50 would > >be more conservative for IoT type devices. (Many GPS devices lasted long > >enough to hit the week roll over bug.) Configure options, both build and > >run-time, could help but they would probably be ignored by the few people who > >should use them. > > Given that there are still PDP8 and VAX systems running production plants > (albeit increasingly as virtual machines), I'd say you vastly underestimate > the longevity of something that is mostly out-of-sight and "just works". > Even if you only consider physical hardware, based on the projected lifetime > of automotive qualified systems (15 years or longer) you have to expect a > much longer actual lifetime in the field. Agreed. -- <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a> Please consider contributing to my Patreon page at https://www.patreon.com/esr so I can keep the invisible wheels of the Internet turning. Give generously - the civilization you save might be your own. _______________________________________________ devel mailing list [email protected] http://lists.ntpsec.org/mailman/listinfo/devel
