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@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@uqconnect.edu.au
From: osmocom-sdr osmocom-sdr-bounces@lists.osmocom.org on behalf of Mr Anthony Arnold anthony.arnold@uqconnect.edu.au Sent: Saturday, 9 May 2015 10:12 AM To: ew; osmocom-sdr@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@uqconnect.edu.au
From: osmocom-sdr osmocom-sdr-bounces@lists.osmocom.org on behalf of ew la@tfc-server.de Sent: Saturday, 9 May 2015 4:19 AM To: osmocom-sdr@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