On Fri, 4 May 2001, Johannes Erdfelt wrote:
> Here's a new updated version. Remove the previous patch first.
Looks good!
Tried all my tests which revealed the problem so far. Nothings breaks
anymore. Seems the HC/HCD-race on qh->element is solved!
Performance is good now, >1 MB/sec again. (Some more benchmarking below)
Numbers are pretty much the same like for usb-uhci.
Very good so far - Thanks.
However, with the transfers now running, I advanced to some new kind of
testing. The interesting one is using the EZ-USB FX with two bulk ep
(2-in, 4-out) to implement an USB loopback device, i.e. the firmware
bounces everything it receives on ep 4 back into ep 2. Driver uses 8
queued bulk urb's for each ep. Transfer length is fixed 512 for 2-in and
alternating 1KB/4KB for 4-out. The test uses this for both performance
measurement in a more realistic bidirectional non-uniform usage pattern
and to verify data consistency by simply diff'ing the bounced data
vs. what was transmitted.
While everything is working and the performance ist always >1 MB/sec
(combined up+downstream) this new test shows some spurious data
inconsistency. On the idle box every few 100MB or so the returned data is
corrupted. Apparently the data corruption probability increases with
interrupt activity. Continously swapping f.e. seems not to influence the
problem. There is no error detected from the USB-layer - the returned
data simply differs from what was sent at some unspecific point
(location not reproducible). I.e. no way to detect this unless you know
what to expect. Unfortunately I have no other information for now.
Repeating the same data consistency test with different HCD gives
absolutely no corruption with usb-uhci under all kinds of concurrent
activity - at least not during the 10GB raw partition (unmounted of
course) which I've just diff'ed over USB. For usb-ohci, there is no
indication of this problem too - however it runs into BUG() sooner or
later...
Martin
-------------------------------------------------
Some benchmarking for raw data throughput into idle box:
First, for comparison, the old non-queued values, turn-time limited
(MB/sec means 1e6/sec, not 1024*1024)
len 256 512 1024 2K 8K 32K
MB/sec 0.13 0.27 0.52 0.68 0.91 0.94
Ok, now for this one - always 2 urb's, queued for same ep:
len 256 512 576 640 704 768 896 1024 2K 8K 32K
MB/sec 0.26 0.51 0.38 0.43 0.70 0.77 0.90 1.02 1.05 1.08 1.09
len <1K deserves >2 urb's
I have no explanation for the drop between 512 and 704?
numbers for usb-uhci are comparable.
same test, but 16 urb's queued for same ep:
len 64 128 256 384 512 576 640 1024 2K 8K 32K
MB/sec 0.09 0.20 0.40 0.59 1.02 1.02 1.09 1.09 1.09 1.08 1.16
The numbers for len<512 are limited by the slow box: 100%CPU (system, in
interrupt) For real fast box I'd expect to get approx. 1MB/sec values down
to len=128, at least.
now another test:
firmware provides two such fast bulk-in ep (2, 4)
read(2) fetches from them both using 16 queued urb's
pattern: 2, 2, 4, 4, 2, 2, 4, 4, ...
transfer_len = 1K/4K alternating
result: 1.15 MB/sec sustained (measured over 100MB=87sec)
well, finally the interesting thing: usb-loopback-device.
average throughput (in+out)
data all zero's all 0xff random
MB/sec 1.09 0.94 1.05
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
