Date: Wed, 4 Mar 2009 10:01:36 +0100 From: Hans Petter Selasky <hselasky@c2i.net> To: "M. Warner Losh" <imp@bsdimp.com> Cc: freebsd-usb@freebsd.org Subject: Re: Low perfomance when read from usb flash drive Message-ID: <200903041001.37376.hselasky@c2i.net> In-Reply-To: <20090304.014655.1820405796.imp@bsdimp.com> References: <200903032243.31914.hselasky@c2i.net> <200903040922.48163.hselasky@c2i.net> <20090304.014655.1820405796.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200903041001.37376.hselasky>