On Sun, Oct 23, 2016 at 7:36 AM, Bernardo Donadio <bcdonadio@xxxxxxxxxxxxx> wrote: > Is there a way to stop the Ethernet controller from monopolizing the > upstream USB channel, while in high usage, in detriment of other USB devices > on LAN9514 (Raspberry Pi 2 USB-Hub/Ethernet chip)? Not really. You might try putting it into polling mode as opposed to the standard interrupt mode but I'm not even sure the usb NICs would support that. > Basically, if you have a USB-attached storage device and start writing data > that comes from the Ethernet into this USB disk, the Ethernet chip will > always have priority on the USB bus and the kernel will never have the > chance to use it to write on the storage device. > > As a result, the data incoming from the Ethernet gets stored in the kernel > IO buffer until memory runs out, and then the transfer stops for a while (as > the kernel starting dropping TCP packets and the TCP flow control algorithm > kicks in). On the other hand, if you stop the network transfer before the > buffer is filled, the content on it is immediately flushed to disk. > > This would not be a huge problem if the USB-attached storage devices didn't > have a timeout: after not receiving some keepalive packets from the system > it's attached to, it dies. With my USB disk, at least, you have to unplug > its USB cable and plug it again to convince its controller that the system > is back up. > > Of course, this is a even bigger issue on Raspberry if the system's root is > installed on this USB disk. > > I'm not sure that this is fixed in the Raspberry Pi Foundation's remix of > Debian, but I'm definitely hitting this bug on Fedora 25 beta with Linux > 4.8.0-0.rc7.git0.1.fc25.armv7hl. Well I have no interest in doing kernel archaeology on a fork of an old kernel. we use the upstream kernel for a reason. You probably want to "dnf upgrade" to the latest 4.8.3 kernel although I doubt it'll have any effect. > How to reproduce, considering /dev/sda is some USB-attached storage on the > rasp2: > desktop$ dd if=some_big_file bs=8M | ssh root@rasp2 dd of=/dev/sda bs=8M > > Meanwhile, you may watch the kernel buffer's filling up on the rasp2 with > htop or free. You may also notice that if you cancel the SSH transfer before > the rasp2 kernel buffer is filled (and also before your USB disk gives up > waiting on the keepalive packet), the content stored on the buffer is almost > immediately flushed to the disk. > > How can we fix this? We probably can't, but ultimately the RPi has a single, some what buggy, usb interface with a hub attached, it's not designed for high throughput data IO workloads. You're probably better off getting a device that's more suited to those sorts of workloads. Even the Orange Pi series of devices are better in this regard as they have a dedicated SoC attached NIC and 3 usb root devices. Peter _______________________________________________ arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx
