[Note that in spite of the comment "USB Development Mailing List" in your CC: line, in fact you sent this message to the linux-usb-users list. Not to linux-usb-devel.]
On Wed, 9 Mar 2005, Michele Bavaro wrote: > Hello everybody, > I already posted a question before (thanks to Alan for the answer) about > a signal collector I work with. This device asks for initialisation, > then starts collecting data and sending them throughout a bulk endpoint. > My receive requests are continuous synchronous (usb_bulk_msg) bulk > requests, 64 Kbytes long (while the maximum allowed length for the > endpoint is 64 bytes) and *without* USB_QUEUE_BULK flag set. URB_QUEUE_BULK is defined only under Linux 2.4. It has been removed in 2.6. > I investigated the kernel source and found that the original requests > are divided into 1024 TD of 64 bytes each.. Since the device needs about > 90 ms to fill 64 Kbytes, more than one transfer *frame* (1 ms/frame, see > UHCI tech. specs) is unavoidably implied. My device is the only device > attached to the USB bus, so this "frame deadline overrun" should not be > a problem (please fix me if I'm wrong). That's right. With no other load present, a full-speed bus can transfer 19 64-byte TDs per frame, which gives 54 ms to transfer 64 KB. > Besides, after a little (random) while, some packets get lost. Then, > packet losses become more and more frequent. > My questions: > 1) Must I schedule transfers that respect the 1ms deadline? I don't understand the question. Are you asking if your URB should only transfer 19 * 64 = 1216 bytes? No, that's not necessary. > 2) How the use of USB_QUEUE_BULK flag could change this unperfect behavior? You should submit more than one URB, so that when one finishes the next one will be available to transfer more data immediately. If you only use one URB then there will be a gap between the time it completes and the time it's ready to transfer some more data. Under 2.4 you have to set URB_QUEUE_BULK to submit more than one URB; under 2.6 you don't have to. So instead of submitting one URB for 64 KB, you could submit two for 32 KB each (i.e., double-buffering). If the completion handler resubmits each URB, you shouldn't lose any packets. Alan Stern ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
