http://comsec.com/wiki?UniversalSoftwareRadioPeripheral
Our goals are to maximize throughput on the USB and to minimize the interpacket jitter that we see at the peripheral. The peripheral uses the cypress FX2.
Looks interesting; and there ought to be no problem making that work well with Linux.
I'm using the QUEUE_BULK flag. The symptom I'm seeing is that although all of the output urbs specify the same endpoint, it appears that what's being transmitted on the bus is some kind of round robin selection of portions of all of the urbs outstanding, instead of all 16K associated with a single urb, and then on to the next.
That should certainly not be happening! Can you reproduce this with a pure kernel driver that doesn't use usbfs/devio? And with the current 2.4.23 code? (Or better yet, 2.6.0-test9...)
My first guess would be that the usbfs async urb mechanism has problems, and that's what you're seeing. There may be other applications that have that many buffers in flight, but if so I've not heard of them before.
Do you have any suggestions? Am I misunderstanding the function of the QUEUE_BULK flag?
QUEUE_BULK should be ignored except by the two 2.4 UHCI drivers. The bulk endpoint model is that there's a FIFO request queue (of urbs); so you shouldn't ever need to use it, except if you're falling back to a full speed connection that might go through UHCI.
(That is, the urb-level flag has those semantics. The flag you pass through usbfs has a different name, same role.)
It seems that this requirement (in order execution of outstanding requests) is common to many other usb devices. USB tape drives and disk drives have the same requirement. For disks the need is derived from requirements for file system integrity (write file data before meta data).
Yes, that commonality is exactly why that's the standard model for bulk endpoints. And we have plenty of reason to believe that model is implemented correctly by the EHCI code, else we'd hear a lot more problems with the 2.6 usb-storage code (which uses very deep queues too, not quite as deep as yours!) ... and that core EHCI code should be the same on 2.6.recent and 2.4.recent.
The only other possibility that comes to mind is that VT6202 hardware (but not the newer VT6212, or southbridge EHCI like VT8235/VT8237) has been problematic, including some of what have always seemed to me like errata. If you're using VT6202, see if different EHCI hw helps. (Most NEC controllers won't sustain 31+ MB/sec throughput, fwiw, but 20+ MB/sec is usually achievable.)
- Dave
------------------------------------------------------- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
