Arcron clock driver in NTP

[Eric S. Raymond]

Putting this on the record on the devel list...

Nigel Roles <nigel at 9fs.org>:
> On 16/06/2016 12:10, Eric S. Raymond wrote:
> >You're listed as the last person to touch the Arcron clock driver in NTP.
> >
> >Does the hardware for which this driver was made still exist?  What,
> >if anything, can you tell me about it?
> >
> >If this driver is a fossil I want to remove it.
> 
> Eric,
> 
> There may be hardware around, but you can't buy it, and mine long ago went
> to land-fill.
> 
> I say remove it.
> 
> Nigel
> 

In a followup mail, Nigel adds:
>Actually you did ask what I could tell you about it.... it was a serially
>connected MSF/Colorado/DCF receiver. Mine was headless, but you could get ones
>with displays. This is all that is left of the name:
>http://www.radiocontrolledclock.com/aratwa.html. It worked very nicely in the
>days when I only had dial up Internet.

For values of "worked" equaling samples at 300bps and 63ms of jitter,
heh. The doc page warns: "By default this clock reports itself to be at
stratum 2 rather than the usual stratum 0 for a refclock, because it
is not really suited to be used as other than a backup source."  Indeed,
a $30 GPS can do nearly two orders of magnitude better.

Internet search does not turn up even the faintest trace of these
things. (Other than lots of hits in old NTP documentation, that is.)
I think this tells us they passed out of use before 2006.

I'm going to say this is 1.5KLOC of dead weight and goes *PLONK*.  Mark,
this is just a hair more aggressive than our previous policy about
legacy hardware that might still *conceivably* be running somewhere, but
the last maintainer just told us to shoot it.

Nigel: we're NTPsec, a security-focused fork of the Mills
implementation.  A main thrust of our technical strategy is to strip
out as much legacy and dead code as possible to reduce attack surface.
With what you just advised us to drop I think we'll get to 59% of the
old code removed.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>