Date: Wed, 04 Mar 2009 11:42:44 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: hselasky@c2i.net Cc: freebsd-usb@freebsd.org, thompsa@freebsd.org Subject: Re: Low perfomance when read from usb flash drive Message-ID: <20090304.114244.106970172.imp@bsdimp.com> In-Reply-To: <200903041910.58446.hselasky@c2i.net> References: <200903041001.37376.hselasky@c2i.net> <20090304163343.GD17847@citylink.fud.org.nz> <200903041910.58446.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <200903041910.58446.hselasky@c2i.net>
Hans Petter Selasky <hselasky@c2i.net> writes:
: On Wednesday 04 March 2009, Andrew Thompson wrote:
: > On Wed, Mar 04, 2009 at 10:01:36AM +0100, Hans Petter Selasky wrote:
: > > On Wednesday 04 March 2009, M. Warner Losh wrote:
: > > > In message: <200903040922.48163.hselasky@c2i.net>
: > > >
: > > > : > I am looking at using FreeBSD in an embedded product. I have not
: > > > : > examined your ehci software, but I am aware of how Linux and other
: > > > : > OSes run the controller.
: > > > : >
: > > > : > Why are you taking an interrupt every uFrame SOF?
: > > > :
: > > > : If the transaction completes before 125us we take the interrupt
: > > > : before 125us. The problem is that the interrupt delay becomes
: > > > : critical to performance when the interrupt rate is close to the
: > > > : interrupt limitation.
: > > > :
: > > > : For example:
: > > > :
: > > > : Transferring 13Mbyte/sec at blocksize equal to 65536 bytes generates
: > > > : 600 interrupts. Hence the Mass Storage state machine has three steps
: > > > : the throughput is computed like (600/3)*65536 bytes. If we on the
: > > > : average have to wait 0.5ms for an interrupt we loose throughput.
: > > >
: > > > Shouldn't you be using filters and such to make this less relevant? A
: > > > filter runs on the order of 5us after the interrupt on fast machines,
: > > > and 20us on slower (400MHz) ones. You can feed the pipeline better,
: > > > and handle higher interrupt rates...
: > >
: > > Yes, that's one possibility. It looks like there is some timing slightly
: > > out of sync. I have an AMD box with the same symptoms. I will try to
: > > figure out what is causing it.
: >
: > If you do change to filters then this is much easier with taskqueues as
: > it has a fast variant, otherwise you would need an intermediate step in
: > order to signal the existing usb threading scheme. The taskqueue
: > changeover will be happening soonish anyway.
:
: I am not going to do anything with filters. I'm going to try some other
: things.
Then you will always have the scheduling delay...
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090304.114244.106970172.imp>