NetSDR rate-test anomaly

[gvanem]

Using this command to do a rate-test of my Afedri-SDR LAN receiver:

  SoapySDRUtil.exe --args=driver=netsdr --rate=2E6 --direction=RX

gives:

######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

Found hostAddr 10.0.0.50, port 50000.
Using Afedri AFEDRI-SDR SN 31351F39 BOOT 1 FW 106 HW 5
getNativeStreamFormat
Stream format: CF32
Num channels: 1
Element size: 8 bytes
Begin RX rate test at 2 Msps
getStreamMTU
Starting stream loop, press Ctrl+C to exit...
activateStream + start 00000002 0 0 0
0 Msps  0 MBps
-deactivateStream
closeStream

The report on the transfer rate is always 0 MBps and no report on dropped packets or anything.

Looking at the code in NetSDR_Streaming.cpp, the call to ::select() looks funny:

int ret = ::select((int)(_udp+1), NULL, &fds, NULL, &tv);

Should it not test for a readable socket?

Tracing the rate-test, I off-course see a huge amount of calls to the above ::select().
But the ::recvfrom() never gets called!?

I'm on Win-10 using a x86 version of Soapy.

[zuckschwerdt]

Looking at the commit a60291a it was indeed meant to test the readfds, but somehow arguments got mixed up?

[gvanem]

... but somehow arguments got mixed up?

Correcting that, rebuilding and running again, there is still no reported rate. And no calls to recvfrom().

[gvanem]

By just changing this function into:

size_t SoapyNetSDR::getStreamMTU (SoapySDR::Stream *stream) const
{
  return 1;
}

the rate-test works:

getStreamMTU
Starting stream loop, press Ctrl+C to exit...
activateStream + start 00000002 0 0 0
0.589214 Msps   4.71371 MBps
0.598596 Msps   4.78877 MBps
0.60989 Msps    4.87912 MBps
0.614733 Msps   4.91787 MBps
0.617771 Msps   4.94217 MBps
0.618627 Msps   4.94902 MBps
\deactivateStream
closeStream

But what does it really do?

[guruofquality]

getStreamMTU is a hint for applications to be efficient. The rate tester app happens to use it

    /*!
     * Get the stream's maximum transmission unit (MTU) in number of elements.
     * The MTU specifies the maximum payload transfer in a stream operation.
     * This value can be used as a stream buffer allocation size that can
     * best optimize throughput given the underlying stream implementation.
     *
     * \param stream the opaque pointer to a stream handle
     * \return the MTU in number of stream elements (never zero)
     */

This MTU value of 0 should be replaced with however many samples per network packet are the default.

[gvanem]

Something like return (((1500 - 20 - 8) / _datasize) + 1);?
With this I still there are a ridiculous amount of calls to select() for each recvfrom() (around 34).

And I see my Afedri never sends UDP-packets bigger than 1444 on this LAN.

[zuckschwerdt]

That 1440+4 seems to be the magic number. The buffer in processUPD() looks wrong (but too big isn't a problem), it should be 4 (header) + 720 (elements) * 2 (element size). Just a guess though. MTU would be 720 then. Not too sure how big the elements are though.

Did you see the many select() calls with the fix from above or without? Select on the UDP writefds would surely always return 1.

[gvanem]

Did you see the many select() calls with the fix from above or without?

With. A return (1); gives me 230 calls to select() for each recvfrom().

[zuckschwerdt]

Sorry, I meant the fix to select() on readfds, instead of writefds. That should be fixed too.
But yes, reading with an (element) MTU of 1 will touch the buffer 720 times, only then do another recv(), likely.

[zuckschwerdt]

I'd say we shouldn't even select() if (numElems <= datacount). It's a rare special case, but we should not impose a timeout on too small reads.
Do you want to PR those three changes, or should I just apply those?

[zuckschwerdt]

Ah, selecting on readfds we will return with SOAPY_SDR_TIMEOUT for small reads ;) It just works now because select on writefds always comes back with 1. Basically the select is now just a no-op. Needs to be fixed but also skipped if there is still enough data in the datasave buffer.

[gvanem]

, or should I just apply those?

👍

[guruofquality]

Few thoughts

• PR good idea
• moving select to after if(datacount)
• dont return timeout if select fails if data has been read, return the number of elements read

[zuckschwerdt]

I'm on it but it might take a day or two. There are other piece perhaps wrong or at least obfuscated, e.g.
float datasave[256 * 2 * sizeof(float)];

[zuckschwerdt]

Gisle, did you have a chance to test #8 ? Relevant changes are in ed31a70

[gvanem]

Looks okay with SoapySdrUtil --args=driver=netsdr --rate=2E6 --direction=RX.
Number of select()== recvfrom() now.