From owner-freebsd-arm@FreeBSD.ORG Sun Jul 7 03:32:35 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D28B9B72 for ; Sun, 7 Jul 2013 03:32:35 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id 572811F54 for ; Sun, 7 Jul 2013 03:32:35 +0000 (UTC) Received: from [207.6.254.8] (helo=[192.168.1.65]) by id.bluezbox.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UvfiA-000G2A-Jf; Sat, 06 Jul 2013 20:32:33 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: USB Performance on Raspberry Pi From: Oleksandr Tymoshenko In-Reply-To: Date: Sat, 6 Jul 2013 20:32:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <433DF541-8C6C-4A51-9277-01F2B99F2077@bluezbox.com> References: <20130707031732.GS39302@server.rulingia.com> To: Warner Losh X-Mailer: Apple Mail (2.1503) Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 2013-07-06, at 8:23 PM, Warner Losh wrote: > > On Jul 6, 2013, at 9:17 PM, Peter Jeremy wrote: > >> Hi Hans, >> >> USB performance on the Raspberry Pi is rather lacking. This is important >> because pretty much everything goes via USB. Do you have any suggestions >> on how to fix the bottlenecks? I suspect one is that FreeBSD is using >> PIO, whereas Linux is using DMA. >> >> I've previously commented about the sawtooth pattern in ping times: >> 64 bytes from 192.168.123.231: icmp_seq=6 ttl=64 time=2.701 ms >> 64 bytes from 192.168.123.231: icmp_seq=7 ttl=64 time=1.465 ms >> 64 bytes from 192.168.123.231: icmp_seq=8 ttl=64 time=10.589 ms >> 64 bytes from 192.168.123.231: icmp_seq=9 ttl=64 time=9.688 ms >> 64 bytes from 192.168.123.231: icmp_seq=10 ttl=64 time=8.673 ms >> 64 bytes from 192.168.123.231: icmp_seq=11 ttl=64 time=7.330 ms >> 64 bytes from 192.168.123.231: icmp_seq=12 ttl=64 time=6.857 ms >> 64 bytes from 192.168.123.231: icmp_seq=13 ttl=64 time=5.946 ms >> 64 bytes from 192.168.123.231: icmp_seq=14 ttl=64 time=3.955 ms >> 64 bytes from 192.168.123.231: icmp_seq=15 ttl=64 time=2.079 ms >> 64 bytes from 192.168.123.231: icmp_seq=16 ttl=64 time=1.072 ms >> >> Whereas pinging a Linux RPi gives: >> round-trip min/avg/max/stddev = 0.276/0.373/0.455/0.049 ms >> >> yongari@ gave me same patches for the SMSC NIC but they didn't have >> any noticable effect. >> >> And the network throughput is also well below what Linux can achieve. >> >> If I connect an external USB disk to a Linux RPi, I get 20.6 MBps >> read. The same disk on FreeBSD RPi gives 6.3 MBps - with ~50% >> interrupt time. > > sure sounds a lot like the USB polling issues... Maybe we have a problem with the USB controller generating the proper interrupts, or some interrupt delivery problem? [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: bsdimp.com] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: freebsd-arm@freebsd.org, Hans Petter Selasky X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 03:32:35 -0000 On 2013-07-06, at 8:23 PM, Warner Losh wrote: >=20 > On Jul 6, 2013, at 9:17 PM, Peter Jeremy wrote: >=20 >> Hi Hans, >>=20 >> USB performance on the Raspberry Pi is rather lacking. This is = important >> because pretty much everything goes via USB. Do you have any = suggestions >> on how to fix the bottlenecks? I suspect one is that FreeBSD is = using >> PIO, whereas Linux is using DMA. >>=20 >> I've previously commented about the sawtooth pattern in ping times: >> 64 bytes from 192.168.123.231: icmp_seq=3D6 ttl=3D64 time=3D2.701 ms >> 64 bytes from 192.168.123.231: icmp_seq=3D7 ttl=3D64 time=3D1.465 ms >> 64 bytes from 192.168.123.231: icmp_seq=3D8 ttl=3D64 time=3D10.589 ms >> 64 bytes from 192.168.123.231: icmp_seq=3D9 ttl=3D64 time=3D9.688 ms >> 64 bytes from 192.168.123.231: icmp_seq=3D10 ttl=3D64 time=3D8.673 ms >> 64 bytes from 192.168.123.231: icmp_seq=3D11 ttl=3D64 time=3D7.330 ms >> 64 bytes from 192.168.123.231: icmp_seq=3D12 ttl=3D64 time=3D6.857 ms >> 64 bytes from 192.168.123.231: icmp_seq=3D13 ttl=3D64 time=3D5.946 ms >> 64 bytes from 192.168.123.231: icmp_seq=3D14 ttl=3D64 time=3D3.955 ms >> 64 bytes from 192.168.123.231: icmp_seq=3D15 ttl=3D64 time=3D2.079 ms >> 64 bytes from 192.168.123.231: icmp_seq=3D16 ttl=3D64 time=3D1.072 ms >>=20 >> Whereas pinging a Linux RPi gives: >> round-trip min/avg/max/stddev =3D 0.276/0.373/0.455/0.049 ms >>=20 >> yongari@ gave me same patches for the SMSC NIC but they didn't have >> any noticable effect. >>=20 >> And the network throughput is also well below what Linux can achieve. >>=20 >> If I connect an external USB disk to a Linux RPi, I get 20.6 MBps >> read. The same disk on FreeBSD RPi gives 6.3 MBps - with ~50% >> interrupt time. >=20 > sure sounds a lot like the USB polling issues... Maybe we have a = problem with the USB controller generating the proper interrupts, or = some interrupt delivery problem? We use PIO mode which is *really* slow. Linux uses DMA mode. I have this=20= half-baked patch I've been sitting on for months: http://people.freebsd.org/~gonzo/patches/dwc_otg-dma-nosplit.diff There seems to be stability issues under heavy load and SPLIT = transactions=20 does not work which affects USB keyboards. I didn't have enough = time/motivation=20 to finish it :(=20=