[TangerineSDR] Update on testing RTLSDR and KA9Q-radio

[Tom McDermott]

WIth awesome support from Franco, K4VZ, there has been a lot of progress in
testing
KA9Q software over a wired home network.

The test setup uses an RTLSDR dongle to send 192 ksps IQ data from a
Raspberry Pi to
an Ubuntu 22.04 core i7 host running gnuradio with Franco's gr-rtp module.
This test
setup may be one where folks have available hardware available from the
junkbox and
thus able to validate their system.

The FFTW wisdom file was computed on each system before starting the tests.
All
connections are using 1 GbE wired connections, no WiFi links in the system.
The GbE
switch is configured with IGMP snooping turned on to avoid multicasting
traffic to
unsubscribed ports. IGMP was verified as working.

Initially a RPi 3B+ with GbE interface was used. At 192 ksps It had a
packet drop rate of over 10 %
resulting in unusable performance. The gnuradio flowgraph was not able to
demodulate
audio from the IQ stream.  It did successfully demodulate audio when the
test was run
at 48 ksps, with lower packet loss rate.

Changing to a Raspberry Pi 4 at 192 ksps improved the drop rate to 0.4%.
This allowed gnuradio
to demodulate audio, but with some artifacts.

Last night the fft-threads=4  line was commented out of the radiod conf
file, allowing
ka9q-radio to use its default of 2 threads for the fft.  This further
dropped to packet loss
rate to 0.1%.  The packet losses are now infrequent (perhaps once every 15
seconds).

Separately all the computers and ethernet connections have been tested with
iperf3.
This is a multi-platform tool (originally Unix / Linux) that sends bursts
of data between the endpoints
measuring the throughput and the TCP retry rate.

The Ubiquiti switch does have retries, sometimes a low number, sometimes a
bit larger number.
A separate small HW switch was substituted and it has zero retries with
iperf3.  All the
tests show a throughput of about 940 Mbit/s regardless, so the retry rates
seem pretty small.

The ka9q-radio packet drop rate is the same (0.1%) using either the test
with the Ubiquiti switch
or the small HW switch, so it doesn't seem to make much difference.

The drop rate was tested with gnuradio running, and with gnuradio not
running. The latter uses
pcmcat {addr/ssrc} > /dev/null to keep the IGMP path open , and the loss
rate is measured with a
tshark script provided by Franco.

The test was repeated with ka9q-radio source and gnuradio both on a single
core i7 computer
(using the loopback data connection). That system runs without drops for a
few minutes
(which was the limit of the test duration).

Franco has tested RPi4 to Linux host with a direct connection without
drops. However he is
using a different SDR receiver than RTLSDR for that test.

A separate test was run with a direct hard wired connection from the RPI4
to the Linux host.
One has to set static IP addresses, and inject static IP routes for the LAN
and the multicast
range 224.0.0.0/4 on both ends.   That setup was unusable with about 50%
packet loss rate,
but this was prior to the fft-threads change (above). It has not been rerun
since the fft-threads change.

Some speculations and observations:

* The different SDR drivers appear to have some significant performance
variations.

* Different switches and links have different iperf3 retry rates, but they
don't seem to affect the
drop rates much.

* The RPI3 B+seems a bit too slow for 192 ksps, but was marginally OK for
48 ksps.

* A faster SBC might be beneficial in place of the RPI4. That would be a
good test to try.

Again, much thanks to Franco, who has provided software instrumentation to
measure the loss rates
both inside of gnuradio and outside of gnuradio (i.e. with gnuradio not
running).

-- Tom, N5EG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/tangerinesdr_lists.tapr.org/attachments/20230912/77326a4a/attachment.html>