<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body>
<div dir="auto">Thank you, Tom, Phil, and Franco. This really great news. </div>
<div dir="auto"><br>
</div>
<div dir="auto">73 Nathaniel W2NAF </div>
<div><br>
</div>
<div id="ms-outlook-mobile-signature" dir="auto">Sent from my Verizon, Samsung Galaxy smartphone<br>
Get <a href="https://aka.ms/AAb9ysg">Outlook for Android</a></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> TangerineSDR <tangerinesdr-bounces@lists.tapr.org> on behalf of Tom McDermott via TangerineSDR <tangerinesdr@lists.tapr.org><br>
<b>Sent:</b> Saturday, September 30, 2023 11:12:39 AM<br>
<b>To:</b> TAPR TangerineSDR Modular Software Defined Radio <tangerinesdr@lists.tapr.org><br>
<b>Cc:</b> Tom McDermott <tom.n5eg@gmail.com><br>
<b>Subject:</b> [TangerineSDR] Packet drop problem fixed</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div>The packet drop problem that I have been having has been resolved.</div>
<div>Phil Karn, KA9Q recently made several additions to the ka9q-radio package</div>
<div>while going through this.</div>
<div><br>
</div>
<div>The problem did not occur when the two computers (server and client) <br>
</div>
<div>were directly wired together with a GbE cable. It only occurred when</div>
<div>going through an Ethernet switch between the two. The problem was</div>
<div>confirmed on 3 different brands of widely available gigabit ethernet switches.</div>
<div><br>
</div>
<div>This problem only occurred on higher-data-rate demodulators, <br>
</div>
<div>those 48k and faster. These are used commonly for sending wider</div>
<div>spectra in IQ format to another program such as gnuradio.<br>
</div>
<div><br>
</div>
<div>1. Jumbo frames did not resolve the issue. The packet drop rate was</div>
<div>the same with normal or jumbo frames. The signature of the dropped</div>
<div>packets was a little different due to the greater number of samples per packet,</div>
<div>but the drop rate ended up being pretty much the same.</div>
<div><br>
</div>
<div>2. Phil then added 'packet pacing' to his code. This can be turned on with</div>
<div>an option pacing = yes in the particular demodulator. With the option</div>
<div>turned off, each 20 milliseconds there can be a burst of packets sent</div>
<div>contiguously representing the previous 20 ms worth of samples. With it</div>
<div>turned on there is a delay inserted between each of the packets in the burst.</div>
<div><br>
</div>
<div>Turning on the pacing option resolved the packet loss problem for me with</div>
<div>a Ubiquiti switch. The Netgear switch also runs well - 1 dropped packet in more</div>
<div>than 256000 packets. Unfortunately the Linksys burned up when I plugged it</div>
<div>into the wrong AC power adapter, so no retest there.<br>
</div>
<div></div>
<br>
<div>This was then tested with Franco's gr-rtp module in gnuradio, and that works</div>
<div>also without packet drops. This worked with 384k sample rate and normal frames.</div>
<div>Jumbo frames work with Franco's module at lower sample rates but not at</div>
<div>384k due to buffer exhaustion. I don't see Jumbo+384k being a real need</div>
<div>at this time.</div>
<div><br>
</div>
<div>Both Phil and Franco have been tremendously helpful in resolving this problem.</div>
<div>They have each spent a lot of time instrumenting gr-rtp. tshark, and the radio code</div>
<div>to narrow down what was happening. I would like to express my thanks to both </div>
<div>for all the expert help in working through this.<br>
</div>
<div><br>
</div>
<div>-- Tom, N5EG</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
</div>
</body>
</html>