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

[Matt Sealey]

I would say this points to a FIFO alarm level being not to your favor
inside the hub. If pinging makes storage faster, that seems to me that
the USB hub is buffering bulk packets until it hits an alarm
condition, and then sending them as a sequence of transfers. Just
because there is a hub + lan chip doesn't mean they are independent. I
am sure the SMSC parts are tightly combined and sharing buffers
somewhere.

As I've said before, CONFIG_USB_EHCI_TT_NEWSCHED might change the
behavior if there is any Transaction Translator in use on the hub
(implies a USB 1.1 device like a mouse or keyboard). The turbo_mode
option to the SMSC driver may well also change the ethernet behavior..
it may not make it better, but it could be that it makes it much more
stable (evenly slow across the board). By disabling both you can be
sure that whatever data is going into the chip is slowly but surely,
no magic batching up of transactions. If there is a complete lack of
performance improvement then you can basically put that down to FIFO
inside the chip not hitting the alarm level required for the chip to
empty it on the other side..

-- 
Matt Sealey <matt at genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.



On Mon, Jun 6, 2011 at 4:54 PM, Chris Tyler <chris at tylers.info> wrote:
> Today Salman Zafar and I observed something that we hadn't noticed
> before (not sure if it didn't happen, or we didn't notice it) -- the
> PandaBoards in the build farm have high latency, with occasional packet
> drops, when pinged at 1-second intervals (the default for the 'ping'
> command).
>
> Oddly, when flood-pinged, they don't drop any packets, and the latency
> improves. This sounds a lot like the storage performance bug, without
> the storage :-)  Perhaps an IRQ is being missed, and a subsequent IRQ
> (or polling event or something else) is causing the driver to pick up
> the data late? (Just speculating)
>
> Regular ping ...
>
> -------------------------------------------
> $ ping  -c20 5-1
> PING cdot-panda-5-1 (192.168.1.151) 56(84) bytes of data.
> 64 bytes from cdot-panda-5-1 (192.168.1.151): icmp_req=1 ttl=64
> time=0.753 ms
> 64 bytes from cdot-panda-5-1 (192.168.1.151): icmp_req=2 ttl=64
> time=49.8 ms
> 64 bytes from cdot-panda-5-1 (192.168.1.151): icmp_req=3 ttl=64 time=128
> ms
> 64 bytes from cdot-panda-5-1 (192.168.1.151): icmp_req=4 ttl=64
> time=8.21 ms
> 64 bytes from cdot-panda-5-1 (192.168.1.151): icmp_req=5 ttl=64 time=233
> ms
> 64 bytes from cdot-panda-5-1 (192.168.1.151): icmp_req=6 ttl=64 time=646
> ms
> 64 bytes from cdot-panda-5-1 (192.168.1.151): icmp_req=7 ttl=64
> time=0.609 ms
> 64 bytes from cdot-panda-5-1 (192.168.1.151): icmp_req=8 ttl=64 time=248
> ms
> 64 bytes from cdot-panda-5-1 (192.168.1.151): icmp_req=9 ttl=64 time=318
> ms
> 64 bytes from cdot-panda-5-1 (192.168.1.151): icmp_req=10 ttl=64
> time=267 ms
> 64 bytes from cdot-panda-5-1 (192.168.1.151): icmp_req=11 ttl=64
> time=267 ms
> 64 bytes from cdot-panda-5-1 (192.168.1.151): icmp_req=12 ttl=64
> time=268 ms
> 64 bytes from cdot-panda-5-1 (192.168.1.151): icmp_req=13 ttl=64
> time=266 ms
> 64 bytes from cdot-panda-5-1 (192.168.1.151): icmp_req=14 ttl=64
> time=265 ms
> 64 bytes from cdot-panda-5-1 (192.168.1.151): icmp_req=15 ttl=64
> time=153 ms
> 64 bytes from cdot-panda-5-1 (192.168.1.151): icmp_req=16 ttl=64
> time=0.632 ms
> 64 bytes from cdot-panda-5-1 (192.168.1.151): icmp_req=17 ttl=64
> time=61.6 ms
> 64 bytes from cdot-panda-5-1 (192.168.1.151): icmp_req=18 ttl=64
> time=0.628 ms
> 64 bytes from cdot-panda-5-1 (192.168.1.151): icmp_req=19 ttl=64
> time=75.9 ms
> 64 bytes from cdot-panda-5-1 (192.168.1.151): icmp_req=20 ttl=64
> time=23.6 ms
>
> --- cdot-panda-5-1 ping statistics ---
> 20 packets transmitted, 20 received, 0% packet loss, time 19021ms
> rtt min/avg/max/mdev = 0.609/164.416/646.835/159.032 ms
> -------------------------------------------
>
> Notice the 164 mS average latency. No packet loss in this particular
> sample, though.
>
> Now a flood ping:
>
> -------------------------------------------
> # ping -f -c20 5-1
> PING cdot-panda-5-1 (192.168.1.151) 56(84) bytes of data.
>
> --- cdot-panda-5-1 ping statistics ---
> 20 packets transmitted, 20 received, 0% packet loss, time 92ms
> rtt min/avg/max/mdev = 0.373/4.666/19.813/6.597 ms, pipe 2, ipg/ewma
> 4.883/3.134 ms
> -------------------------------------------
>
> Results vary but are generally repeatable.
>
> This kernel (which is a 2.6.35.3) doesn't appear to be built with the
> appropriate /sys/kernel/debug/usbmon bits for tracing with tcpdump.
> (Anyone know offhand the kernel flags for that?)
>
> -Chris
>
> _______________________________________________
> arm mailing list
> arm at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/arm
>