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