<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>