Re: [gpsd-dev] RC for DRIFT message

[Gary E. Miller]

Yo Hal!

On Wed, 25 Feb 2015 02:13:21 -0800
Hal Murray <address@hidden> wrote:

> 
> > Yes.  But the only practical reason to write a HOWTO rather than
> > just saying "Sockets everywhere.  Done." is that System V IPC could
> > cut latency by eliminating serialization/deserialization overhead
> > and buffer lag.  So speed is an issue, and performance numbers are
> > probably indicated. 
> 
> Are we confusing two issues here?  There is a transport mechanism as
> in TCP or SHM, and there is encoding as in JSON or raw binary.  If
> you are timing things, please time sending the same chunk of binary
> stuff over all transport mechanisms and time the JSON
> encoding/decoding without any transport.

True that.

I vote for JSON, even though it add complexity, as it is human readable
and very portable.

> From ntpd's view, file descriptors can be fed to select so they get
> prompt response while SHM gets polled with the obvious latency.

But it is easy to add a semaphore around the SHM and then use sem_wait().

I lean toward the socket, but the SHM has nice debug potential as tools
like the new ntpmon can easily snoop that data.

> JSON encoding gets interesting in the sense of API changes.  It
> offers the opportunity to hide the real changes since all the data is
> in a string.  It might make sense to have two API version numbers,
> one for how to get at the JSON strings, and another for the contents
> of the string.

Yeah, lots of upside.

> TCP (JSON or binary) allows remote monitoring, or even use from
> another machine if you are after location rather than time.

Even the dumbest hosts have some TCP stack.

> >    With the SiRF chips still used in most consumer-grade GPSes at
> > time of writing, 9600bps is the optimal line speed. 4800 is
> > slightly too low, not guaranteeing updates within the 1-second cycle
> >    time. 9600bps yields updates in about 0.45sec, 19600bps in about
> >    0.26sec. Higher speeds would probably not be worth the extra
> >    computation unless your sensor is in rapid motion. Even
> > whole-cycle latency, most sensitive to transmission speed, is only
> > cut by less than 200ms by going to 19200. Higher speed will exhibit
> > diminishing returns.
> 
> The default SiRF data fits into 1 second at 4800.  It overflows into
> the next second when GPGSV is present because it starts in the middle
> of the second.

Similar other GPS.  The data just does not fit in 4800.

> Has anybody looked at the data from the multiple-updates-per-second
> devices? Are they actually collecting new data at sub second times,
> or are they just extrapolating using the velocity from the previous
> second?

They seem to compute new PVT data at the higher rate.  Hard to confirm
given the data is probalby also smoothed.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
        address@hidden  Tel:+1(541)382-8588