Future drivers

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> esr at thyrsus.com said:
> > My intention is to officially deprecate refclocks 20 and 48 in favor of 28
> > (SHM), explaining that the way 1PPS and in-band information is mingled
> > produces bad behavior on 1PPS dropouts.   Actual deprecation will wait on
> > confirmation from Gary's tests. 
> 
> Why did you pick SHM rather than JSON?  I thought the party line was to 
> switch to JSON?

It was, until I leaned of this problem:

> Is the only problem with 48 that the default is to mingle/mangle the PPS and 
> serial info?  Other than that I think the results are the same as SHM.

Gary says he thinks the problem can be fixed with better configuration.
I'd like to see that.

> I'm happy to go with SHM.  I hate the verbosity of JSON.

It has its uses.  It makes an excellent metaprotocol for the user-facing side,
where the added latency isn't so important.

There was always a lartency-minimization case for SHM that I took seriously.

> > Hal, I hope you're paying attention to this.
> 
> I can't figure out what time scale you are talking about.

At least a year out, probably.

> In the long term, I'm happy to cleanup the refclock stuff by switching to 
> refclockd, whatever that turns out to be.  That's assuming we take time to do 
> it right.  We should start by collecting ideas for a requirements list.
> 
> In the short term, I think it's important to maintain compatibility with NTP 
> classic.  So I vote against deprecating any of the current drivers and 
> probably against minor tweaks (like changing defaults) that would 
> simplify/clean-up ntp.conf.

I concur on all this.  The time to be bold in adding new features and major
refactoring like refclockd is not yet - we need to (a) get our testing act
together and (b) earn the political cred from wider-scale adoption first.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>