Proposal - drop the GPSD JSON driver

[Eric S. Raymond]

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.

> > JSON reflects one set of priorties: extensibility of the protocol and
> > eyeball-friendless are more important than minimizing latency or jitter in
> > most cases. 
> 
> But it doesn't add significant latency or jitter.  Latency isn't critical in 
> the below 1 ms range.  There is much more latency in SHM.  Where do you think 
> the jitter is coming from?  All the time critical work is done in gpsd.  It 
> sends deltas.

Interesting assertions.  I see what you mean about the polling latency now.

There's an easy way to take GPSD's heavy computation work out of the
budget that we haven't used yet.  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.

You're no longer shipping raw device time, but that's OK.  You're
shipping GPSD's assertion that it belives clock time was X at system
time Y, and the maximum distortion is due to a constant number of
simple arithmetic instructions.

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.

> > but the same amount of time spent on (say) a POSIX SHM driver would have
> > paid off better
> 
> What does "POSIX SHM" mean?
> 
> I think there are two parts to SHM.  One is setting up a chunk of shared 
> memory.  The other is passing data from one process to another.  That part 
> needs memory barriers or semaphores or something like that.
> 
> My man page for shmget says:
>          shmget - allocates a System V shared memory segment
> CONFORMING TO
>        POSIX.1-2001, POSIX.1-2008, SVr4.
> 
> Is that POSIX?

Yes.

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

> 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.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>