Re: [gpsd-dev] RC for DRIFT message

[Eric S. Raymond]

Hal Murray <address@hidden>:
> It's probably important to get the context right.  You don't want the High 
> Performance Computing crowd thinking you are trying to steal their thunder.

Oh?  Why not?  :-)

> Many of them have IPC in their inner loop and are paranoid about both cycles 
> and microseconds.  (I assume we are more interested in correctness, 
> simplicity, and portability rather than speed.)

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.

> > "The GPRMC gets pushed over over the boundary into the next second."
> > Interesting.  I can believe this at 4800bps; have you observed it at 9600? 
> 
> Yes, that's 4800.  I haven't tried 9600.  4800 is default for ntpd and NMEA 
> and what gpsmon put it back to after I had poked "i" to get it into SiRF 
> binary so I could check the firmware version.

Years ago I did some time profiling on a SiRF II and, as you note, saw the 
reporting burst slop over into the next second at 4800bps.  9600 shipped
the data enough faster to prevent this.

Where's the Latency? Performance analysis of GPSes and GPSD
        http://catb.org/gpsd/performance.html

   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.

> > Yes. Conveniently, the stripchart library does stacked stripcharts.  It's
> > easy to imagine a display with stacked stripcharts, one for  each active NTP
> > segment. 
> 
> By stacked, do you mean two independent graphs, one above the other?

Yes.

> If you want to compare TOFF to PPS, it would be easier to do that
> if they were both plotted on the same chunk of graph paper.  Mumble.
> No matter what you do, somebody will want something else.

Indeed :-).  I will experiment with different presentations.

> > Where are you proposing I get temperature from?  The temp readout from a
> > fish sounder doesn't seem very relevant...
> 
> I was thinking of something like calling out to a shell script.
> 
> As Gary suggested, CPU temperature is a good start.  I have a few
> very old boxes where most OSes can't read any of the info the BIOS
> prints out.  Most OSes can read the CPU temperature on less old
> boxes.  The disk temperature is also interesting.

Version 2.0, if then.  I want to keep it simple on the first round.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>