Low perfomance when read from usb flash drive

[Hans Petter Selasky]

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

--HPS