Future drivers

[Gary E. Miller]

Yo Eric!

On Mon, 9 May 2016 09:15:03 -0400
"Eric S. Raymond" <esr at thyrsus.com> wrote:

> 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:

There are so many drivers because there is diversity in the problem.

I think we will need both solutions going forward.

For example, SHM will not work in Windows, but sockets will.

> > 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.

No, more problems than that.  I've some bug reports on those.

First ones already in.  A bug in the undocumented configuration that
almost works:

https://gitlab.com/NTPsec/ntpsec/issues/57

And a documentation bug so the user knows of the best configuration:

https://gitlab.com/NTPsec/ntpsec/issues/58

Looks like somewhat easy ones to fix.

> > 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.

Uh, no.  The latency of the JSON is not relevant.  JSON reports the
time, and time offset, of its time measurements.  As long as ntpd
eveluates the time within a few seconds there is no latency issue.
 
> > 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.

Yes, NTPsec needs to prove it can make the exising ntpd better in a
side-to-side bake-off.  Only when it has a following will the followers 
follow to a better place.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160509/55a73262/attachment.bin>