On Fri, 4 May 2001, Johannes Erdfelt wrote:
> > 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?
The "device" is an EZ-USB FX development board. The firmware for this test
is a simple implementation of an infinite source of data. The device is
interrupt driven and uses DMA into a double-buffered bulk-in ep. Both the
sustained source data throughput and commit-latency are _much_ (factor 10
or so) better than needed to saturate the whole USB-1.1 fullspeed bus.
This means you'll never see a NAK! It's just a test setup for evaluation.
Without using queued transfers (but large transfer size - say >32KB - to
overcome the turn-time latency) the measured sustained throughput is about
950 kB/sec for both uhci and usb-uhci and 1.15 MB/sec for usb-ohci.
Using queued transfer (2 urbs, 2112 byte each) the number is about
1.05 MB/sec for both uhci-flavours (compared to 550 kB/sec for unqueued
1 urb x 2112 operation) with vanilla-2.4.4. But uhci stops occasionally
due to the race. Your patch fixes this, but the throughput drops to
710 kB/sec. Hadn't the scope at hand, but my guess is as follows:
the len=2112 is typically scheduled into 2 frames x 16 packets + 1 packet
in the next frame. So if the next queued transfer wouldn't immediately
follow the last packet but delayed to the beginning of the next frame, the
expected throughput would be 33/48 x 1.05MB = 720kB, i.e. pretty close to
the observed value. Some unexpected |TERM at bqh->link?
> I can get 805KB/sec with this patch using the usbnet driver which is
Well, I'm not familiar with usbnet - but assuming the transfer size would
be something like 1.5K (=eth-MTU), my above guess would predict (here: 1.5
of 2 frames used) 0.75 x 1.05 MB = 780kB/sec!
I'll go and try len=1984 (2KB - 1 packet). Should give something next to
31/32 x 1.05 MB = 1 MB/sec, if I'm right.
> as fast as usb-uhci. I'm still testing and I'll send an email later
_If_ there is no other bottleneck I would expect 1 MB again for usb-uhci.
> with more tests.
Ok, will try then.
Martin
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
