# Raspberry Tx / LimeMini : throuput not reliable above 2MS

**URL:** <https://discourse.myriadrf.org/t/raspberry-tx-limemini-throuput-not-reliable-above-2ms/4002>\
**Category:** LimeSDR\
**Created:** [14 January 2019 11:27 UTC](https://discourse.myriadrf.org/t/raspberry-tx-limemini-throuput-not-reliable-above-2ms/4002 "2019-01-14T11:27:02Z")\
**Posts on this page:** 1\
**Showing post:** 5

<div class="post-metadata">

**Author:** ![mzs](https://yyz2.discourse-cdn.com/flex034/user_avatar/discourse.myriadrf.org/mzs/32/2678_2.png) [@mzs](https://discourse.myriadrf.org/u/mzs)\
**Post date:** [25 January 2019 02:14 UTC](https://discourse.myriadrf.org/t/raspberry-tx-limemini-throuput-not-reliable-above-2ms/4002/5 "2019-01-25T02:14:13Z")

</div>

> [@f5oeo](#):
>
> Raspberry is working headless : ssh over LAN. Traffic on LAN is only ssh, so a ridiculous bandwidth.

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](https://app.netrounds.com/static/2.26.1/support/defs-notes/l2-eth-frame-sizes.html)) 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](https://en.wikipedia.org/wiki/Kibibyte)/second [GitHub - aguinet/usbtop: usbtop is a top-like utility that shows an estimated instantaneous bandwidth on USB buses and devices.](https://github.com/aguinet/usbtop)

ref: [https://www.benzedrine.ch/ackpri.html](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](https://electronics.stackexchange.com/questions/24700/why-are-usb-devices-slower-than-480-mbit-s) (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).

---

_[View the full topic](https://discourse.myriadrf.org/t/raspberry-tx-limemini-throuput-not-reliable-above-2ms/4002)._