4 RTL dongles operable on RPi3? Many buffer overruns.

[thowe-switzerland]

Hello together

Although I have several years of experience in using RTLSDR-Airband, I am now in need of your advice.

I'm helping a colleague set up his LiveATC feed system:

• Raspberry Pi 3
• Raspberry Pi OS Lite
• Current Unstable RTLSDR-Airband with GPU-Support compiled
• 4 x RTL SDR dongles

The configuration binds all 4 RTL dongles each with 2.5MHz bandwidth. FFT size is standard 512, no NFM support. Each dongle outputs 3 Icecast streams. Additionally some channels go into a mixer, which is also output as an Icecast stream. Total of 13 output channels as Icecast stream. No local recording to MP3 files.

Basically the setup works and the CPU is less than 25% utilized and cool. However, we notice buffer overflows, which are noticeable in swallowed syllables. Below the overrun counters after about 12h of operation.

# HELP buffer_overflow_count Number of times a device's buffer has overflowed.
# TYPE buffer_overflow_count counter
buffer_overflow_count{device="0"} 19332
buffer_overflow_count{device="1"} 19244
buffer_overflow_count{device="2"} 15965
buffer_overflow_count{device="3"} 19508

# HELP output_overrun_count Number of times a device or mixer output has overrun.
# TYPE output_overrun_count counter
output_overrun_count{device="0"} 0
output_overrun_count{device="1"} 0
output_overrun_count{device="2"} 0
output_overrun_count{device="3"} 0
output_overrun_count{mixer="0"} 0
output_overrun_count{mixer="1"} 0

# HELP input_overrun_count Number of times mixer input has overrun.
# TYPE input_overrun_count counter
input_overrun_count{mixer="0",input="0"} 1223
input_overrun_count{mixer="0",input="1"} 1261
input_overrun_count{mixer="0",input="2"} 1302
input_overrun_count{mixer="0",input="3"} 1051
input_overrun_count{mixer="0",input="4"} 1030
input_overrun_count{mixer="0",input="5"} 1038
input_overrun_count{mixer="0",input="6"} 2141
input_overrun_count{mixer="0",input="7"} 2232
input_overrun_count{mixer="1",input="0"} 0

Can anyone give a hint from experience where our bottleneck could be?

1. is it the USB connection of the four dongles? Can we optimize something there?
2. is the GPU performance at the limit with executing FFT for the 4 x 2.5MHz bandwidth?
3. is a RPi3 simply too weak for 4 RTL dongles?
4. should we consider an RPi4 for the task?

Thank you very much for any advice.
Tom

[szpajder]

RPi GPU is not fast enough for this task. Use RPi4 (or any other, more capable hardware).

[thowe-switzerland]

Thank you. I was afraid of this. I will advise him to either stay with the already purchased RPi 3 and reduce the load by reducing the bandwidth per dongle or the number of dongles. Or to switch to a more powerful RPi 4.

[charlie-foxtrot]

Some thoughts:

• Make sure you're using multiple_demod_threads = true; and multiple_output_threads = true;. This will run each dongle in its own thread, I would expect top -H to show 4 threads (one per dongle) all using about the same CPU
• Watch for low voltage system messages. Drawing enough current to run 4 dongles through that micro USB power port may drop the voltage and that will slow down the CPU. On RPI4s I've wired power directly to the 5V / GND pins on the GPIO port and that seems to work for me.
• RPI3 ports are USB 2, running 4 dongles at 2.5 MHz (and I think the ethernet chip is also on the USB bus?) may be too much. Can you drop the bandwidth on some of the dongles?

[thowe-switzerland]

Thanks for the points.

One question of understanding: parallel demodulation threads cannot be used with FFT on the GPU, as far as I know, right? Would you expect the RPi3 to work better without GPU support. I wouldn't expect it to.

We are now testing whether an RPi4 works better.

[charlie-foxtrot]

I would test it, but would not be surprised if 4 parallel CPU threads is better than one GPU given the amount of data your trying to process. 4 slow trucks can carry more payload than one fast car

[jayant4001]

I'm running a Pi 3B+ with 4 RTL-SDR dongles, 3 on a USB3.0 hub, one connected directly to the Pi. They receive 14 (sometimes 15) frequencies concurrently in multichannel mode, no nfm support. I have also configured 6 mixers. That makes it 20 icecast2 streams. I get stable output with no drops (zero buffer overruns) as long as I am listening live. If I try to setup additonal file outputs, I get syllables chopped off in the recordings but still no buffer overrun. rtl_airband consumes about 52% CPU, which isn't too bad. The Pi is also running nodeexporter, prometheus and grafana for my system and airband dashboard.

[thowe-switzerland]

Thanks for the success report!

In fact, with the switch from GPU FFT to CPU FFT and the two options for multithreading, we also had success. The RPi3 can demodulate and stream 4 RTL dongles at 2.5 MHz each.

Only rarely were there overruns. Since we want to increase the FFT size to 1024 to achieve more selectivity, we decided to switch to RPi4 anyway.