OSX - figure out good default buffer size

[ghost]

Server is Ubuntu 14.04 32 bits Client is CubicSDR on OSX 10.10.5

All latest manual builds.

SDR thread starting.
device init()
[INFO] SoapyRemote::setupRxStream(remoteFormat=CS8, localFormat=CF32, scaleFactor=128, mtu=8192, window=16384000)
[INFO] Client side stream bound to 192.168.1.21:54160
[INFO] Client side status bound to 192.168.1.21:54160
[INFO] Using format CS8.
[INFO] Client side stream connected to 192.168.1.19:59808
[ERROR] StreamEndpoint resize socket buffer FAIL: setsockopt(SO_RCVBUF) [55: No buffer space available]
[INFO] Configured receiver endpoint: dgram=8144 bytes, 4060 elements @ 2 bytes, window=16000 KiB
[INFO] Server side stream bound to 192.168.1.19:59808
[INFO] Server side stream connected to 192.168.1.21:54160
[INFO] Server side status connected to 192.168.1.21:56720
[WARNING] StreamEndpoint resize socket buffer: set 16384000 bytes, got 1048576 bytes
[INFO] Configured sender endpoint: dgram=8144 bytes, 4060 elements @ 2 bytes, window=1024 KiB
[WARNING] Set thread priority 0.5 failed: Operation not permitted
Calculated optimal 6 channel element count of 85338
starting readLoop()
Calculated optimal 6 channel element count of 42666
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS

[guruofquality]

I may have recently "fixed" something in regards to reporting the error from setting the socket buffer. Has any behaviour actually changed other than the error message appearing. I assume the stream of SSSSS's were not there prior?

[ghost]

I never tried remote before, so i cannot tell you.

Ton.

On Sun, Nov 1, 2015 at 7:49 PM, Josh Blum notifications@github.com wrote:

I may have recently "fixed" something in regards to reporting the error from setting the socket buffer. Has any behaviour actually changed other than the error message appearing. I assume the stream of SSSSS's were not there prior?

— Reply to this email directly or view it on GitHub https://github.com/pothosware/SoapyRemote/issues/15#issuecomment-152857438 .

[guruofquality]

OSX is a little strange with the socket buffer sizes. We tried to pick a default on that would be acceptable. Some notes here: https://github.com/pothosware/SoapyRemote/blob/master/common/SoapyRemoteDefs.hpp#L38

So then the resize fails like this, the actual size isnt known, and the flow control may not properly protect the socket buffer from overflow (thats the S printed). On linux, the resize never fails, it just comes up short. @cjcliffe When we last looked at this, did you have to change any OSX parameters to allow for the 16k buffer size?

So we need to figure out an acceptable default size, or some algorithm to determine the size-cap without erroring out, and to make the size readback robust as well, so we always know the actual size, even in the event of failure to set the size.

[guruofquality]

This commit should readback the proper window, even after buffer resize fails. Plus better logging: https://github.com/pothosware/SoapyRemote/commit/9f7a887918b40f4bdcd6cbd923e46cf6ed70346b

@Toontje Can you experiment with reducing #define SOAPY_REMOTE_DEFAULT_ENDPOINT_WINDOW (16*1024)? Im curious at what value it stops failing.

[cjcliffe]

I assume it's an RTL dongle since I see the remote format as CS8 -- Not sure if it's related, but the following hack from when we were trying to figure out what was up with SoapyRemote+RTLSDR+OSX is still active on the version of CubicSDR that @Toontje is using:

    if (deviceArgs.count("rtl") != 0) {
        streamArgs["remote:mtu"] = "8192";
        streamArgs["remote:format"] = "CS8";
        streamArgs["remote:window"] = "16384000";
    }

That code has already been removed in my local commits as I'm adding all the stream and device settings into the device selection dialog which will let you change this stuff manually.

[guruofquality]

Really old bug. OSX has different ifdef sizes here for this reason.