Re: [gpsd-dev] RC for DRIFT message

[Hal Murray]

> What you've actually nudged me into thinking about writing is a practical
> guide to IPC that examines the functional tradeoffs among IPC methods.

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

Extra credit if you provide performance numbers.

It might make sense to structure things so that the open, read, and close 
routines are all owned/maintained by gpsd.  read would fill in a client 
provided struct and return success or an error number.  The idea is 
documentation by real code rather than pseudo code.

We need to include a recipe for transitioning to a new version of the API.

Adding fields is fairly simple if you left "dummy" space in any structs 
and/or include a (sub) version number.  When things get more complicated than 
that, the classic approach is for the server to support both the old and new 
API for a while, giving the client time to update.  I think that works here.


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


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

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.


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

If the IPC stuff gets sorted out, we could export the internal details from 
ntpd.  That might make an interesting test case.




-- 
These are my opinions.  I hate spam.