Low perfomance when read from usb flash drive

[Hans Petter Selasky]

On Wednesday 04 March 2009, Steve Calfee wrote:
> On Wed, Mar 4, 2009 at 12:22 AM, Hans Petter Selasky <hselasky at 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 Steve,

> 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.

I think there is no limit. It is the EHCI hardware that is responsible for 
limiting the IRQ rate. Usually it is limited by some bits in the command 
register like 1,2,4,8.. x 125us. I'm currently using 1x125us yielding max 
8000 IRQs/second.

The operating system is probably not the bottleneck in this case. It's 
something in the hardware hanging or waiting.

--HPS