Pivoting
Eric S. Raymond
esr at thyrsus.com
Sun Apr 23 21:44:20 UTC 2017
Achim Gratz <Stromeko at Nexgo.DE>:
> 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.
More information about the devel
mailing list