Re: Ethernet monopolizing LAN9514 upstream USB bus

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux ARM (Vger)]     [Linux ARM]     [ARM Kernel]     [Fedora User Discussion]     [Older Fedora Users Discussion]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Maintainers]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Tux]     [Yosemite News]     [Linux Apps]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]

Powered by Linux