Fixing to MTU is the wrong approach

[sjkelly]

#22 papered over a few issues for the sake of making progress on a few bugs and under the auspice of latency, but I realize my premise was wrong. A few short reasons:

1. MTU may be asymmetric for read and write on the same device.
2. It has little bearing on OS abstractions.
3. We are not strictly optimizing for latency, but rather balancing latency, throughput, and bandwidth.
4. We are only at the foothills of a mountain here.

--
Elaborated:

1. A few SDR devices have different read and write MTUs which opens up a can of worms that we currently pass to the user. This can be confusing and a footgun.

2. I started a month ago by reading transciever datasheets, then skipped about a dozen levels of abstraction up to Julia. In general it seems most protocols are not exposed as explicit duplex transfers. For USB, PCIe, etc, a read and write is done and the OS will handle the duplexing (or will pass it to hardware than can). SPI at the kernel level is anomalous with a transfer. So the abstraction is wrong for a radio transceiver IMO, but it is wrong through many layers of hardware and abstraction that we can't change (yet).

3. Latency, throughput, and bandwidth are not simply viewed at the bus, but at the whole software-hardware integrated stack. We therefore should not strictly optimize one characteristic at the bus as it may have the opposite effect in the software.

4. We may have top-down requirements for e.g. a filter window, that drive the transaction size. See:
   https://static.squarespace.com/static/543ae9afe4b0c3b808d72acd/543aee1fe4b09162d0863397/543aee20e4b09162d0863578/1380223973117/gr_scheduler_overview.pdf
   Aside: Dagger may be a good way to chain these things together.

So we still need to go back and handle all flags, and likely patch Soapy modules if need be. We should still expose MTU options for things like data capture with minimal processing, where high throughput are concerns. For general use, we need flexible data transfer sizes.

[mbaz]

Does it make sense to take an incremental approach? That is, first get to the point where we can read and write to the radio consistently (even if not at top speed), and get Overflow and Underflow notifications. Once that is done, keep adding functionality and improving efficiency.

I think our main priority for now should be to get to the point where we can run experiments on the radios with some consistency, even with suboptimal performance.

[sjkelly]

I like incremental development :). Main branch should work for large buffer sizes consistently. Can you see if this works: https://juliatelecom.github.io/SoapySDR.jl/dev/#Transmitting-and-Receiving ? Feel free to ping me on Slack if you have issues.

The gain and antenna APIs are my immediate priority as we are not handling these well right now. See: #8 for tracking on those issues.

[sjkelly]

Fixed in #31.