On Fri, May 04, 2001, Martin Diehl <[EMAIL PROTECTED]> wrote:
> On Thu, 3 May 2001, Johannes Erdfelt wrote:
>
> > On Thu, May 03, 2001, Georg Acher <[EMAIL PROTECTED]> wrote:
> > >
> > > This is exactly the cause, why usb-uhci is always using a "bottom QH" (bqh)
> > > as the last element in the vertical TD list when queuing bulks. With this
> > > last QH, UHCI enters a new context and doesn't update the element pointer of
> > > the old "top" QH. So there's no race when appending new TDs, the old bqh is
> > > recycled as the top QH of the new TD list. Of course, there's a slight
> > > memory cost, but absolutely no race window.
> > >
> >
> > Ahh, so that's what the code was doing. I looked at your driver to see
> > what you were doing but couldn't figure it out. That makes perfect sense
> > and is definately a better solution. Thanks for the explanation. My patch
> > makes uhci.c operate like that.
>
> Tested as before. Nothing breaks. All transfers rock solid even under
> heavy interrupt activity. I would say this is the clean way to remove this
> HC/HCD race.
Excellent.
> However, now uhci looses in performance compared to usb-uhci: With my
> usual 2 queued bulk transfers, len=2112, both to same endpoint,
> usb-uhci provides >1MB/sec av. throughput - for uhci this number was the
> same without this patch (until the race happened) and has now dropped to
> about 700KB/sec.
1MB/sec is very impressive. I forget exactly what your device did, does
it connect 2 hosts together?
I can get 805KB/sec with this patch using the usbnet driver which is
as fast as usb-uhci. I'm still testing and I'll send an email later
with more tests.
JE
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
