Date: Wed, 4 Mar 2009 14:18:51 -0800 From: Steve Calfee <stevecalfee@gmail.com> To: Hans Petter Selasky <hselasky@c2i.net> Cc: freebsd-usb@freebsd.org Subject: Re: Low perfomance when read from usb flash drive Message-ID: <4a5ff6bc0903041418g1a26c046sbc7ae2459ba48044@mail.gmail.com> In-Reply-To: <200903040922.48163.hselasky@c2i.net> References: <200903010045.44904.man@email.com.ua> <200903032243.31914.hselasky@c2i.net> <4a5ff6bc0903031415s16158407m386b8321a5082996@mail.gmail.com> <200903040922.48163.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Mar 4, 2009 at 12:22 AM, Hans Petter Selasky <hselasky@c2i.net> wrote: > 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. > Hi Hans, Ok I have looked a little at your ehci.c code and the ehci spec. I see that you are talking about the "interrupt threshold control" field which Intel added to the ehci to keep the high speed controller from flooding the cpu with interrupts. It has nothing to do with SOF interrupts. > 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. > I think here you are referring to the awkward synchronous scsi protocol embedded in usb mass storage devices. In this protocol the host does a IN and gets a USBS... status data block, does an OUT with a USBC... data block and then the data transfer (either IN or OUT). I don't think I have seen Linux or Windows transfer (in one scsi xfer) more than about 40K, but ok lets say 65K is possible. This means 128 -- 512 byte packet transfers. The max number of transfers I have seen in a microframe is about 11, but lets say it is 16 with some super ehci/dma controller. That says you can transfer 65K in 128/16 == 8 uFrames (this is higher than the 60Mbyte/sec bus speed of light, but it is easy to calculate). In this same super computer/ehci hardware the 3 packets (USBS, USBC, data) will most likely all be in different microframes. So in this scenario there will be 3 interrupts in 10 microframes = 1.250 milliseconds. In practice the USB mass storage device is the limiting factor and will be much slower than this. So what I am getting at is it is hard to believe the interrupt rate which will limit your xfer speed. Now the interesting question (for me a FreeBSD novice) is how does the OS limit the number of interrupts? Usually they would be limited by the available CPU power, and unlikely be limited to some arbitrary number per second (1000 or 8000). Does FreeBSD run all interrupts out of what Linux would call a bottom-half or tasklet? In that case latency for sequential I/O in the 3 step scsi protocol could add up to hurt you. Regards, Steve
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4a5ff6bc0903041418g1a26c046sbc7ae2459ba48044>