Proposal - drop the GPSD JSON driver

[Gary E. Miller]

Yo Eric!

On Wed, 19 Oct 2016 21:30:28 -0400
"Eric S. Raymond" <esr at thyrsus.com> wrote:

> Hal Murray <hmurray at megapathdsl.net>:
> > It has a different type of noise.  There is no "ready" signal on
> > SHM so the driver polls and the timing on that is just the luck of
> > when ntpd was started.  
> 
> Same thing with JSON.  The client can't predict when JSON will come
> up the wire.

Yes, but it can block until it happens.  With SHM it has to stay away
and poll.

> NTP is a very different case.  Minimizing jitter in the delivery chain
> is all-important, extensibility and eyeball-friendliness matter barely
> at all.  The overhead of formatting the JSON at one end and decoding
> at the other should be avoided if it can be.

I'm not sure why the jitter is important?  The timing dependent stuff
is done before the JSON is sent.

> You and others modeled my thought processes incorrectly.  I left a
> clue to what I was actually thinking in that communication between
> GPSD and its client libraries can actually have any of three
> transports - JSON, DBUS, or shared memory.  I put in the
> shared-memory transport specifically for use by real-time embedded
> systems.

So, a shared memory driver for ntpd?

> From my point of view, the JSON driver in ntpd is a cute stunt that
> doesn't really fit the context very well.  I'm mildly flattered that
> somebody thought GPSD JSON was cool enough to want to play with, but
> the same amount of time spent on (say) a POSIX SHM driver would have
> paid off better.

Hmm, I thought I mentioned JSON encoding inside the POSIX SHM driver?
Or you want to invent anotehr wheel?

> > Would pipes work better?  Or a network connection passing the same
> > (binary) info as is in the SHM segment?  
> 
> As Gary just found out in connection with ntpviz, pipes pretty much
> suck for this kind of work due to unpredictable buffering overhead.
> I don't know whether or not that would be true of sockets.

Yeah,  major suckage.

> I don't think either is going to match the performance of a
> shared-memory drop.

So, we all vote for JSON in POSIX SHM?

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/20161019/17245d79/attachment.bin>