gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] RC for DRIFT message


From: Eric S. Raymond
Subject: Re: [gpsd-dev] RC for DRIFT message
Date: Thu, 26 Feb 2015 06:15:05 -0500
User-agent: Mutt/1.5.23 (2014-03-12)

Hal Murray <address@hidden>:
> 
> > 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.

Yeah, sure.  There are two latency components here which I'nm *not* confusing:

* serialization/deserialization overhead - zero we're doing memcpy of
  a struct, nonzero for JSON encode/decode.

* transport lag - cost of memcpy for SHM, cost of the socket layer for TCP.

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

Yes, I phrased that badly.  At higher timing speeds the process will have
slightly higher *transient* utilization - same work done in less time.

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

I've never seen one myself, and have no basis for a guess.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]