Proposal - drop the GPSD JSON driver

[Gary E. Miller]

Yo Eric!

On Thu, 20 Oct 2016 07:34:18 -0400
"Eric S. Raymond" <esr at thyrsus.com> wrote:

> Hal Murray <hmurray at megapathdsl.net>:
> > 
> > esr at thyrsus.com said:  
> > > Same thing with JSON.  The client can't predict when JSON will
> > > come up the wire.   
> > 
> > The client is normally waiting in the big select.  It will get
> > woken up as soon as data is available.  
> 
> Oh, now I see what you mean.  You're right.
> 
> Hm.  That's an argument for something with a wait or ready signal.
> Not an argument for JSON in SHM.  Might mean we need an auxiliary
> semaphore to do sem_wait on; not a problem.

Huh?  POSIX in SHM has a semaphore!  So there is an argument for
JSON in POSIX SHM.

> There's an easy way to take GPSD's heavy computation work out of the
> budget that we haven't used yet.

Uh, what heavy commputation?  Prolly less than 100 LOC from KPPS to
done out the door to ntpd.


> You take a nanosecond-precision
> timestamp on the first read of data from the device. You take a second
> timestamp just before you ship.  You bump the fix time by the
> difference between the second and first timestamps.

Oh, you mean like itt already does?

> You might be right that the noise from JSON encoding/decoding time
> does not add significantly to the jitter budget.  We should test and
> see.

NO added noise.  Obvious by inspection of the protocol.

> > The problem with semaphores is that I don't see a clean way to
> > initialize them and/or recover from crashes.  
> 
> Pre-POSIX SHM has the same problem and the same mitigation
> strategies.  It hasn't been a problem in practice.

I disagree.  PSOIX HSM is much better thought out.

> > The advantage of a pipe or socket is that they fit in to the select
> > we have. I don't believe the cycles associated with either will be
> > significant, but I don't have numbers to back that up.
> > 
> > Maybe we should start a side project to write some clean sample
> > code an/or collect some timings.  
> 
> You are quite right.  We should do exactly that.

So, we are bock to JSON (or something not binary) in POSIX SHM?

I suggest after 1.0 given the uncertainies...

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: 455 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20161020/0a6ad26c/attachment.bin>