From owner-freebsd-usb@FreeBSD.ORG Wed Mar 4 23:07:20 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 574B8106566C for ; Wed, 4 Mar 2009 23:07:20 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id B2D7F8FC12 for ; Wed, 4 Mar 2009 23:07:19 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=Ma5krZdYoiIA:10 a=-DXRHlJb_54A:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=8kQB0OdkAAAA:8 a=6I5d2MoRAAAA:8 a=gvOMmpoZNh3WImVdzuEA:9 a=WZqWRaXQd78en5NKbM6zDKrvElIA:4 a=LY0hPdMaydYA:10 a=9aOQ2cSd83gA:10 a=YYtyPbemraNutXIM:21 a=KM4DycbHs61dn12O:21 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 154320870; Thu, 05 Mar 2009 00:07:18 +0100 From: Hans Petter Selasky To: Steve Calfee Date: Thu, 5 Mar 2009 00:09:47 +0100 User-Agent: KMail/1.9.7 References: <200903010045.44904.man@email.com.ua> <200903042311.00403.hselasky@c2i.net> <4a5ff6bc0903041437l52a58387v1735e34ebc383847@mail.gmail.com> In-Reply-To: <4a5ff6bc0903041437l52a58387v1735e34ebc383847@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903050009.48188.hselasky@c2i.net> Cc: freebsd-usb@freebsd.org Subject: Re: Low perfomance when read from usb flash drive X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 23:07:20 -0000 On Wednesday 04 March 2009, Steve Calfee wrote: > On Wed, Mar 4, 2009 at 2:10 PM, Hans Petter Selasky wrote: > > On Wednesday 04 March 2009, Artyom Mirgorodsky wrote: > >> I forgot to write, that a similar problem was observed in FreeBSD 7 with > >> usb4bsd patches. > > > > Here is a patch which I think will address your problem. It is EHCI > > hardware related. Different models behave differently. Try this: > > > > http://perforce.freebsd.org/chv.cgi?CH=158692 > > Wow, that is bizarre. The "doorbell" is usually used so the software > knows that the cpu vs dma race is complete when moving qtds off the qh > - ie dequeueing requests. What you have done is asked the guy doing > the photo finish at the end of a horse race to press the shutter a > little before the horse crosses the line - so the shutter latency will > allow a picture right as the horse crosses the line. Unfortunately, > this (like all races) is affected by the object doing the racing - > horse speed and camera speed are variable! > > I believe something else must be wrong. The new USB stack _is_ doing things faster than the old one. I have gone through a large range of tests before I landed on the doorbell trick. Actually the new USB stack doesn't use the doorbell, we use software timers instead. The hardware certainly behaves different from vendor to vendor. Probably somone making the chips have to explain what is wrong. In my (Nvidia+AMD64+EHCI) test case I tried: No doorbell: 12 Mbyte/sec Doorbell after transfer (after QH removal): 14 Mbyte/sec Doorbell after next transfer (after QH insertion): 21 Mbyte/sec On my other reference Intel chip I did not get any noticable performance increase by doing this trick ... I think this trick is the best I can do. I've seen peculiarities before regarding the doorbell not behaving like it should .... --HPS