Proposal - drop the GPSD JSON driver

Gary E. Miller gem at
Sun Oct 23 01:14:36 UTC 2016

Yo Eric!

On Sat, 22 Oct 2016 09:21:59 -0400
"Eric S. Raymond" <esr at> wrote:

> Hal Murray <hmurray at>:
> > >> I assume that using a pipe or socket rather than SHM would fix
> > >> that.  
> >   
> > > Probably, but then we run unto buffering jitter again.  
> > 
> > Are we on the same wavelength yet?  Have we agreed that latency is
> > not critical?  If so, why is jitter important?  
> It is possible that I am confused.

Now we agree.  :-)
> What ntpd gets from a clock source is a series of pairs asserting
> "at system time X I believe it was UTC time Y".


> Are you telling me there is no value in minimizing the time from X to
> when the sample triggers a correction, and the variation in that time?

Yes. ntpd sits on the data, by default, for 32 seconds average, and 64
seconds max.  The big ntpd loop only goes around every second.  A few
micro seconds is not releavnt.  Long term tests on GPSD-JSON confirm this.

> Basic servocontrol theory tells me that control lag is the enemy of
> precision and tends to produce whiplash effects.  Does that not apply
> here?

With all the averaging, filtering and polling, the transit time from
delta generation to ntpd input is way less then 3 orders of magnitude
less than the ntpd control loop cycle (one second).  Then when 
ntpd averages the deltas over 64 seconds all immmediacy is lost.

But don't believe me, or my long term GPSD-experiments, set up your own.
Not hard.

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at  Tel:+1 541 382 8588
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the devel mailing list