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.
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).
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?
2) How the use of USB_QUEUE_BULK flag could change this unperfect behavior?
Please help me!
Michele
-- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 266.6.4 - Release Date: 07/03/2005
------------------------------------------------------- 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
