Date: Sat, 2 Oct 2010 08:41:57 +0200 From: Hans Petter Selasky <hselasky@freebsd.org> To: freebsd-usb@freebsd.org, pyunyh@gmail.com Subject: Re: Network TX/RX fairness is not honored by USB stack Message-ID: <201010020841.57474.hselasky@freebsd.org> In-Reply-To: <20101002001100.GL10521@michelle.cdnetworks.com> References: <20101002001100.GL10521@michelle.cdnetworks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 02 October 2010 02:11:00 Pyun YongHyeon wrote: > Hi, > > I don't know how long it had been there but it seems current USB > stack does not honor fairness of TX/RX on USB ethernet controller. > Unidirectional performance test(UDP) or most-unidirectional > performance(TCP) test works well without problems. However if heavy > TX/RX traffic hits controller at the same time either TX or RX is > not served at all. I'm under the impression that whenever TX work > is done it seems USB reschedules next pending TX again instead of > processing RX such that RX is starved to death. This can be easily > reproduced on two hosts with the netperf performance test. > Whenever both hosts send tiny UDP datagrams to the other host > either TX or RX packet counters are not increasing until the end > of the UDP torture test. The number of EHCI interrupt is about 8K/s > while test is in progress so I think it reached its maximum > processing limit. After netperf testing, it can still process TX/RX > packets even though it dropped too many RX packets. But these > dropped packets are not counted so netstat(1) shows 0 dropped > frames even though it lost millions of packets. > > Hans, do you have any idea what's going on here? > You can use the following netperf command on both hosts after > running netserver. > %netperf -c -H ip_addr_of_other_host -tUDP_STREAM -l 300 -- -m 1 > > Another odd thing I noticed is number of interrupts does not go > down to 0 after the testing. It constantly generates 1k/s > interrupts after that. Maybe we are triggering a bug. Can you enable USB debugging to figure out what data lengths are transmitted or received. USB EHCI uses round robin, so this is either USB device problem or a test- program software failure. Check the CPU usage of the host computer during the test. Do you see anything? > The only way I stop that interrupts was to > down the ue0 interface with "ifconfig ue0 down" command. --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201010020841.57474.hselasky>