Consumption of rtl_tcp too slow?

historical

Hello,

i have same problem with gr-osmosdr when using gqrx and rtl_tcp over ethernet.
It eats too much cpu on client side with gnuradio 3.7.5.1 and it is
unusable.

I tried to patch it and remove that deinterleave/reinterleave code. It
works for me. But sometimes when i start dsp in gqrx too late it looks
little laggy. I must restart gqrx and start dsp asap, probably some
problem with buffering.

Anyway, you can test my gr-osmosdr, if it works for you i can send
it upstream probably.
https://github.com/stanojr/gr-osmosdr/tree/rtl_tcp_refactor

On Sat, 9 May 2015 01:39:01 +0000 Mr Anthony Arnold
<anthony.arnold at uqconnect.edu.au> wrote:

> OK, update!
> 
> I'm pretty confident that it's the deinterleave stage that's causing
> the drama.  I ran callgrind and found that around 7% of processing
> time was spent in the deinterleave block.
> 
> So the rtl_tcp_source_f block is outputting a stream of interleaved
> floating point values, and then the rtl_tcp_source_c block is
> deinterleaving them and then converting each pair into a complex
> number.
> 
> The problem with this is that the stream is being deinterleaved and
> then effectively reinterleaved! The entire
> deinterleave/float_to_complex process is redundant, because the
> original stream is already in the order required. 
> 
> Anthony Arnold | Programmer
> 
> b:  http://anthony-arnold.com/
> t:   http://twitter.com/anthonyarnold_/
> e:  anthony.arnold at uqconnect.edu.au
> 
> 
> ________________________________________
> From: osmocom-sdr <osmocom-sdr-bounces at lists.osmocom.org> on behalf
> of Mr Anthony Arnold <anthony.arnold at uqconnect.edu.au> Sent:
> Saturday, 9 May 2015 10:12 AM To: ew; osmocom-sdr at lists.osmocom.org
> Subject: Re: Consumption of rtl_tcp too slow?
> 
> The count on rtl_tcp keeps increasing until it reaches the default
> limit for the "-n" options (500).
> 
> When the gr-osmosdr source block is created, the first thing gnss-sdr
> does is to set up the sample rate, frequency, and gain parameters. It
> then connects the block up to the flowgraph and the flowgraph is run.
> 
> I tried a little experiment by writing my own block for consuming
> rtl_tcp. It's mostly the same as the gr-osmosdr one, except that it
> runs a separate thread for TCP reads. The producer thread continually
> reads from the socket, translates the incoming bytes to the float
> values via the LUT, then stuffs the floats into a circular buffer.
> The work function on the gnuradio thread just pulls data from the
> circular buffer. This gave a barely-noticeable improvement.
> 
> I did some tracing, and found the the producer thread gets held up;
> the buffer is almost constantly full. The hints that the network
> stack is not the issue, because the producer thread is reading faster
> than gnuradio can consume it.
> 
> This is all very confusing, because when I'm reading from the USB
> dongle directly on the same machine, gnss-sdr handles 1.2Msps in
> realtime without trouble and no overflows. It's only when it's
> reading from the network that it can't keep up, but the network
> itself doesn't seem to be the bottleneck.
> 
> Is it possible that the deinterleave and/or float_to_complex stages
> are what's holding this up?
> 
> Anthony Arnold | Programmer
> 
> b:  http://anthony-arnold.com/
> t:   http://twitter.com/anthonyarnold_/
> e:  anthony.arnold at uqconnect.edu.au
> 
> 
> ________________________________________
> From: osmocom-sdr <osmocom-sdr-bounces at lists.osmocom.org> on behalf
> of ew <la at tfc-server.de> Sent: Saturday, 9 May 2015 4:19 AM
> To: osmocom-sdr at lists.osmocom.org
> Subject: Re: Consumption of rtl_tcp too slow?
> 
> By the looks of it I'd say the gnss-sdr source is the problem, does
> the count keep increasing or does it stop at a certain number?
> 
> The explanation for the latter would be that the Application connects,
> but does not read, rtl-tcp has no starting or stopping. As soon as a
> client connects it tries to pump out samples until the client
> disconnects, so buffers are going to pile up if there is a delay
> between connecting and reading and the count will stay the same if the
> application does not read the data faster than real time to empty the
> list. If it keeps increasing the most probable explanation would be a
> sample rate mismatch or some other reason why the client does not
> read fast enough.
> 
> The "known to work" rates are just that - values that are known to
> work without any side effects, but most other rates should work, too.
> Frequent tuning, gain adjustments, or other commands  might cause
> those commands to pile up, but neither of those would cause the
> dongle to produce more samples than anticipated unless your app
> accidentally sends out a command to set a higher sample rate...
> 
> 
> - Hoernchen

-- 
[ Ohodnotte kvalitu mailu:
https://www.nicereply.com/websupport/4afafd34 ]

Pavel Stano | Troubleshooter

http://WebSupport.sk
*** BERTE A VYCHUTNAVAJTE ***