Date: Wed, 04 Mar 2009 02:13:11 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: hselasky@c2i.net Cc: freebsd-usb@freebsd.org Subject: Re: Low perfomance when read from usb flash drive Message-ID: <20090304.021311.-705197428.imp@bsdimp.com> In-Reply-To: <200903041001.37376.hselasky@c2i.net> References: <200903040922.48163.hselasky@c2i.net> <20090304.014655.1820405796.imp@bsdimp.com> <200903041001.37376.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <200903041001.37376.hselasky@c2i.net>
Hans Petter Selasky <hselasky@c2i.net> writes:
: On Wednesday 04 March 2009, M. Warner Losh wrote:
: > In message: <200903040922.48163.hselasky@c2i.net>
: >
: > Hans Petter Selasky <hselasky@c2i.net> writes:
: > : Hi Steve,
: > :
: > : On Tuesday 03 March 2009, Steve Calfee wrote:
: > : > > I think the reduced performance can be explained by a clamp on the
: > : > > interrupt rate around 1000 interrupts per second instead of 8000.
: > : > > Maybe someone has an explanation for this?
: > : > >
: > : > > The EHCI is being programmed to interrupt at 125us intervals, but
: > : > > there seems to be limits other places.
: > : > >
: > : > > It is possible to workaround this in the umass driver by doing the
: > : > > cmd + read in one operation.
: > : >
: > : > Hi Hans,
: > : >
: > : > 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.
Maybe there's just good, old-fashioned lock contention going on? 7.x
has more Giant use than 8.0 will, and in the past this has been a
source of problems. Something else to check into. Maybe enabling
lock profiling might yield some good data?
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090304.021311.-705197428.imp>