Eric S. Raymond
esr at thyrsus.com
Tue Apr 25 17:03:22 UTC 2017
Hal Murray <hmurray at megapathdsl.net>:
> gem at rellim.com said:
> > I'd have ntpd reject any time prior to EPOCH.
> How do you decide whether to reject it or pivot it into the future?
This is indeed a problem, and it's fundamental whenever you're trying to
work with devices that have time conters that can roll over within their
expected lifespan. It's foolish to pretend that *any* workaround will
never have perverse consequences.
> >> Allow the user to specify the pivot time and/or life time, either
> >> at build time or at run time or both.
> > EPOCH is used for NMEA, so that is covered at build time.
> > I could see adding an option to specify the EPOCH at run time too.
> My build time comment was mostly for life time. I was assuming that EPOCH
> would be used for pivoting.
> I know about three pivots to consider. One is GPS 10 bits for weeks with a
> 20 year step size. Another is 2 digit year numbers with a 100 year step
> size. The third is 32 bits of seconds in NTP packets with a 136 year step
> size. Are there any others I've overlooked?
> If we want our software to last more than 20 years while talking to crappy
> GPS receivers, we need a way to update the pivot date at run time. (I'm
> using "last" to mean without rebuilding.)
> If we want our software to reject bogus time, we have to balance the tradeoff
> between long life and good filtering. Run time parameters will allow the
> user to choose.
As I think more about this, I become more nervous about these
prospective "run-time parameters". They seem like asking for trouble -
not easy to explain, easy to misconfigure.
> > As mentioend earlier, PDP-8s still run. That is late 1960's. Call it 50
> > years.
> It would be interesting to see what those setups are actually doing and if
> they have documentation for something as obscure as NTP.
> There is a lot of lab gear running embedded software. I wonder how much of
> it will be running at its 25th or 50th birthday. I have a pre-software scope
> that's over 35 years old.
> The combination of long life and crappy GPS seems obscure enough that I'm
> willing to document it as a limitation. It's the kind of code that Eric
> would love to rip out if he found it a year ago.
You're right enough about *that*. What kept my hands off it was
defensive conservatism - I've managed to not fuck us up while removing
almost 75% of the C code by being extremely careful about messing with
things I didn't understand.
As I remarked in my last mail, I'm coming around to the view that trying
to work around old crappy GPSes is a swamp that we're best out of. There
are no right answers, just differently wrong ones - what you get to choose
is the distribution of your failure cases.
> The documentation issue gets interesting. A feature isn't any good if you
> can't figure out how to use it. I wonder if the web will solve that problem.
> Will NTPsec still be online 20 years from now? Will we maintain online
> versions of 20 year old releases?
I think we have to plan for a longer than 20-year lifetime; after all the code
is about 20 years old now.
> Would anybody notice a warning message from a program that's been running for
> 19 years?
That is imponderable. But I think we have to emit whatever messages
will give future admins the most useful information *assuming* they
<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