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

[Andy Green]

On 05/31/2011 09:36 PM, Somebody in the thread at some point said:
>
>> Can you put the ethernet and storage on different hubs? (it may not be..)
>
> No, it's all on-board.  No other hubs, all board-powered.
>
>> Or do you see similar crappy performance with the nic adapter
>> unplugged and unused?
>
> I see the same crappy performance with the smsc95xx driver unloaded,
> net down, cable unplugged.
>
> That gave me an idea, though... I unloaded the smsc95xx driver, and
> plugged in a serial port connected to a 9600 baud character generator,
> and got good performance.  Likewise with a usb mouse, as long as I
> wiggled the mouse during the test.
>
> Note: I get crappy performance with the network *up*, as long as
> there's no traffic.
>
> If I plug in *two* usb-storage devices (er, flash stick and sata
> dock), I get the same crappy performance for both of them (i.e. same
> per-drive throughput as the single-drive crappy performance).

cc-ing Felipe Balbi (whole thread here 
http://comments.gmane.org/gmane.linux.redhat.fedora.arm/1266 ) in case 
he has an idea.

I had a go a reproducing this also on a 2.6.38-based kernel on Panda.  I 
was thinking it sounds a bit like USB suspend (not the same as kernel 
suspend) because evidently there is deadtime after idle from device. 
You showed that traffic to the device doesn't count with your "two usb 
storage device" test.

First two goes are with ethernet idle, then two goes with pingflood

root at linaro:~# dd if=/dev/zero of=/media/FAD8-72F0/dump bs=4096 count=10240
10240+0 records in
10240+0 records out
41943040 bytes (42 MB) copied, 17.4684 s, 2.4 MB/s
root at linaro:~# dd if=/dev/zero of=/media/FAD8-72F0/dump bs=4096 count=10240
10240+0 records in
10240+0 records out
41943040 bytes (42 MB) copied, 17.219 s, 2.4 MB/s
root at linaro:~# dd if=/dev/zero of=/media/FAD8-72F0/dump bs=4096 count=10240
10240+0 records in
10240+0 records out
41943040 bytes (42 MB) copied, 11.4112 s, 3.7 MB/s
root at linaro:~# dd if=/dev/zero of=/media/FAD8-72F0/dump bs=4096 count=10240
10240+0 records in
10240+0 records out
41943040 bytes (42 MB) copied, 11.8075 s, 3.6 MB/s

This is the same tests done with CONFIG_USB_SUSPEND disabled, no real 
difference.

root at linaro:~# dd if=/dev/zero of=/media/FAD8-72F0/dump bs=4096 count=10240
10240+0 records in
10240+0 records out
41943040 bytes (42 MB) copied, 15.8717 s, 2.6 MB/s
root at linaro:~# dd if=/dev/zero of=/media/FAD8-72F0/dump bs=4096 count=10240
10240+0 records in
10240+0 records out
41943040 bytes (42 MB) copied, 17.0267 s, 2.5 MB/s
root at linaro:~# dd if=/dev/zero of=/media/FAD8-72F0/dump bs=4096 count=10240
10240+0 records in
10240+0 records out
41943040 bytes (42 MB) copied, 10.6266 s, 3.9 MB/s
root at linaro:~# dd if=/dev/zero of=/media/FAD8-72F0/dump bs=4096 count=10240
10240+0 records in
10240+0 records out
41943040 bytes (42 MB) copied, 11.9173 s, 3.5 MB/s

I had a look at the smsc lan9514 and ULPI PHY datasheets

http://www.smsc.com/media/Downloads_Public/Data_Sheets/3320.pdf

to see if there was something obvious to hack suspend disabled but 
didn't see anything useful.

-Andy