I think you should leave it until we get our act together, and I think you
should put that on the back burner until 1.0 is out.
> For communication with GPSD, the SHM driver seems superior; it certainly has
> lower processing overhead and therefore introduces less noise into the
> delivery chain
Hal Murray :
> 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.
> I'm missing the big picture. The JSON dr
Yo Eric!
On Wed, 19 Oct 2016 21:30:28 -0400
"Eric S. Raymond" wrote:
> Hal Murray :
> > 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'
Gary E. Miller :
> So, a shared memory driver for ntpd?
It already has one. I think the one it has would be as good as we need
if not for the fact that that version of SHM is obsolete and unstandardized.
> > I don't think either is going to match the performance of a
> > shared-memory drop.
>
>
e...@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.
> Originally GPSD JSON wasn't really supposed to be an externally exposed
> protoco
e...@thyrsus.com said:
>> So, we all vote for JSON in POSIX SHM?
> I don't. I think this is one of the very rare cases where passing a C stru=
> ct as a binary blob makes sense. We want to minimize offset and jitter and
> there's no cross-architecture problem.
Don't forget to include a version
