[fedora-arm] smsc95xx performance bug: eth vs usb

[Niels de Vos]

On Sat, May 28, 2011 at 1:53 AM, DJ Delorie <dj at redhat.com> wrote:
> This is a weird bug, has anyone else seen or fixed it?
>
> If you connect storage up to a pandaboard USB port (flash or sata),
> you get about 5 MB/sec throughput.  Now, if you "ping -i 0.001" the
> pandaboard from another host, you can increase the *storage*
> performance to 22 MB/sec (for my disk, max 32 MB/sec on an x86
> desktop).  Note that the ethernet device is itself also on the same
> USB hub (on chip) as the device storage.

In order to find out if the smsc95xx really is the cause, maybe you
can do the same/similar test when the driver is not loaded?

If the driver is compiled in the kernel, you can unbind (similar to a
disconnect) the device with something like:

    # cd /sys/class/net/usb0/device/driver/
    # ls
    bind 1-0:1.0   uevent  unbind
    # echo 1-0:1.0 > unbind

-> do some testing

    # echo 1-0:1.0 > bind

-> and possibly you need to restart the network service

> This tells me that something in the smsc95xx driver is either missing
> an interrupt, or not polling fast enough, but I couldn't find
> anything.

This could be, but maybe there is something going on in the USB-chip
or on the USB-bus itself.

> USB protocol analyzer shows that most of the time, the transfers are
> happening at the full speed, so it's just stopping every once in a
> while, killing performance.

I have seen a 'broken' USB-device once, which was sending 0-size URB's
to the host when there was no data. The host was getting an unexpected
high load. If the firmware from the USB-device was sending a NAK
instead, the handling would have been done in the USB-chip, not in the
driver, which passed the empty data on to the actual module/handler.
The 0-size packet that was send, was actually conforming the
specifications, however the driver was programmed in such an
unsuitable way, that there was no delay in requesting more data (which
resulted in a new 0-size packet....).

It would be interesting to see if there is data going to/from the
smsc95xx if there is nothing to do. If there is data from this device
on the bus, it might affect the bandwidth. Sending a ping would slow
the smsc95xx down while processes the ping, and this might free some
bandwidth for your disk.

> Kernel is 2.6.38.5-23.fc13.armv7l.omap from the Fedora 15 development
> SRPMs.

I don't have access to a PandaBoard, so I can only review code and
give some thoughts. Maybe you can post some of the USB-captures and a
/proc/bus/usb/devices for review? I also don't know of you're familiar
with systemtap (if it works on ARM at all, I haven't tried yet) and
have a -debuginfo package. If so, you might want to try to find out
what functions are being called.

HTH,
Niels