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 2:10 PM, Hans Petter Selasky <hselasky at c2i.net> 
wrote:
> > On Wednesday 04 March 2009, Artyom Mirgorodsky wrote:
> >> I forgot to write, that a similar problem was observed in FreeBSD 7 with
> >> usb4bsd patches.
> >
> > Here is a patch which I think will address your problem. It is EHCI
> > hardware related. Different models behave differently. Try this:
> >
> > http://perforce.freebsd.org/chv.cgi?CH=158692
>
> Wow, that is bizarre. The "doorbell" is usually used so the software
> knows that the cpu vs dma race is complete when moving qtds off the qh
> - ie dequeueing requests. What you have done is asked the guy doing
> the photo finish at the end of a horse race to press the shutter a
> little before the horse crosses the line - so the shutter latency will
> allow a picture right as the horse crosses the line. Unfortunately,
> this (like all races) is affected by the object doing the racing -
> horse speed and camera speed are variable!
>
> I believe something else must be wrong.

The new USB stack _is_ doing things faster than the old one. I have gone 
through a large range of tests before I landed on the doorbell trick. 
Actually the new USB stack doesn't use the doorbell, we use software timers 
instead. The hardware certainly behaves different from vendor to vendor. 
Probably somone making the chips have to explain what is wrong.

In my (Nvidia+AMD64+EHCI) test case I tried:

No doorbell: 12 Mbyte/sec
Doorbell after transfer (after QH removal): 14 Mbyte/sec
Doorbell after next transfer (after QH insertion): 21 Mbyte/sec

On my other reference Intel chip I did not get any noticable performance 
increase by doing this trick ...

I think this trick is the best I can do. I've seen peculiarities before 
regarding the doorbell not behaving like it should ....

--HPS