Re: [gpsd-dev] RC for DRIFT message

[Hal Murray]

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

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

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.

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


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

I'm not sure what you mean by "extra computation".  Higher link speeds don't 
use more cycles.  It's the same data to process, the work just gets done in a 
different timing pattern.

Some devices can (optionally?) send their data multiple times per second.  
Depending upon which sentences are enabled, that probably requires a higher 
link speed and would require more computation.

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?



-- 
These are my opinions.  I hate spam.