We transfer a stream of four 16 bit channels over USB. In one channel there is a sample number that increases every sample period. We use this "counter" to detect errors in a stream. With my ehci patch I can transfer aproximately 3 MB of data without any error. It's quite small number, but this is due to a bug in our USB device (buffer overrun). When I use your ehci iso patch, an error apears every 10 kB on average. It seems to me that this "error rate" depends (not lineary) on number of packets per urb.
You should explain more about your tests. Sounds like IN transfers with two 1KB packets per uframe. How big are your URBs ... how many uframes each? And how deep is your URB queue? Are these "errors" paired with urb->iso_frame_desc[i].status faults, or do you just see strange looking data landing in the buffers? Do you maybe have any CATC confirmation what's going on?
It might help if you were to post copies of the EHCI debug files, made while your tests are running. They're found in /sys/class/usb_host for the bus (probably "usb1"), and they most interesting ones here will be called "periodic" and "registers". And of course, if there were any debug messages from EHCI that'd be good too.
The ehci is made by Intel and the stream is high-bandwith (16 MB/s). You wrote that you had done lots of testing of your patch, so I'm wondering why there are so big differences. Do you have any explination of this.
Not without some details to go with your report!
I tested IN and OUT transfers at a variety of periods and transfer sizes. The 16 MB/s rate was covered, as was 24 MB/s and various rates that could also be handled by full speed transfers. Right now I see a test script that uses 32 KB/URB and a queue depth of 8 URBs, which will run 10,000 times (32*8*10000 KB, streamed). Gave no errors in iso_frame_desc[], no scheduling glitches (uframes skipped) ... nothing like that.
At one point I noticed schedule glitching if the URB queue got short enough to empty; for now, that'll force a big (10 msec!) gap in the stream. If that's an issue, the fix is using deeper queues in your host side driver.
- Dave
------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
