Conclusion :
As we LimeMicro will use barely the same architecture, does it means that we will be limited by 2MS ?
Is there any way to handle more bandwidth, specially with CPU load ?
I understand that using DietPi instead of Raspbian has proved to be more stable. Perhaps a real-time/low latency kernel might help also. More testing required.
Do you have all other USB devices disconnected (keyboards, mice etc) and you are not using the 10/100 Mbps NIC which also shares the same one and only real USB 2.0 HighSpeed port that is common in all RPi products. (ref: Gqrx for limeSDR on RPI3 for a nice diagram).
The RPi has three main things going for it, cheap, large support base, reasonably number crunching ability, but pushing large amounts of data about fast is not one of its strengths.
I think of the USB configuration of a RPi using a LAN9514 chip (a 4-port USB hub with an integrated 10/100 USB Ethernet controller) like putting 5 funnels into one funnel. The flow rate of the bottom funnel is the limiting factor and using more than one funnel above will only reduce the flow rate available.
Raspberry is working headless : ssh over LAN. Traffic on LAN is only ssh, so a ridiculous bandwidth.
No other peripherals plugged.
So USB is only used for LimeMini. I agree that USB is not the biggest strength of Raspberry, I have to investigate which bandwidth it could handle with other peripherals.
Could also see is other distrib like dietpi could be more efficient.
Network traffic due to the nature of the data transfer being chopped up into packets (MTU 1500 bytes) with a header and a footer being added (IPv4 would have a maximum layer 2 ethernet frame sizes of 1564 bytes) is mostly a Burst transmission, so nothing for ages and then a bunch of packets all in quick succession most of which have to then be chopped up into even smaller chunks (largest USB 2.0 High Speed payload is 512 bytes) for transfer across the USB bus with additional checksums, headers and padded with synchronisation bytes . You also have a stochastic trickle of background packets from network broadcasts (windows machines are particularly noisy in this regard for some reason, sometimes broadcasting the exact same messages three times in a row). So if you are trying to maintain a constant data stream and every now and again the available throughput is reduced by network traffic, that will lower the overall throughput as well as the overall maximum throughput. There are overheads in handling multiple devices that will reduce the maximum throughput for both devices. I don’t have exact numbers because there are so many variables mostly related to size, timing, USB chipset, OS, driver which make that ridiculously difficult for any meaningful numbers, but there could be anywhere from 5% to 70% loss of potential throughput just by handing two devices at once on a USB port via a hub (non intuitively the lower drop in overall throughput would be if the data flow of the devices were predominantly in the same direction and the higher drop in throughput would be if the data flows were in opposite directions, on a full duplex link). There is a relatively new UNIX tool that should give a rough idea of the live throughput of individual USB devices in KiB/second GitHub - aguinet/usbtop: usbtop is a top-like utility that shows an estimated instantaneous bandwidth on USB buses and devices.
ref: https://www.benzedrine.ch/ackpri.html (graphical demonstration how delays in ACKnowledgements of data packets transferred successfully on full duplex data links can severely reduce overall throughput, sorry but I don’t know any good examples for USB 2.0 HS throughput, but the data flows would be similar in most full duplex bulk data transfers)
ref: communication - Why are USB devices slower than 480 MBit/s - Electrical Engineering Stack Exchange (summary of the USB 2.0 HS protocol in relation to throughput, copper wire raw signalling rate is 480 Mbps, but optimal real world data transfer rate is going to be close to 320 Mbps or 39000KiB/sec for the better chipsets and the drivers with most OSes).
