On Tue, 5 Oct 2004, Geoff Oakham wrote: > > Could it be that the timing of your commands isn't suitable for the > > device? If it gets another "send next data block" command too soon or too > > late after the last one, it may not be ready so it replies instead with a > > STALL. And maybe sometimes when it does that, it does prepare the next > > block of data anyhow. > > I've been wondering about this myself. What troubles me about that > possibility is: > > 1) isn't "please wait, I'm not ready yet" built-into the USB > protocol? (So shouldn't it be transparent to me?)
It _is_ in the protocol, but that doesn't mean the device supports the protocol correctly! > 2) why isn't this happening when the system is lightly loaded or > when the device is connected to an alternative controller? (As > I understand it, the ohcl controllers are slightly faster than > the uhcl ones.) I really don't know. And by the way, it's OHCI and UHCI, not OHCL and UHCL. The acronyms stand for "Open Host Controller Interface" and "Universal Host Controller Interface". I can't imagine any way the UHCI controller would give you a -EPIPE without actually receiving a STALL from the device. Unless the controller itself was malfunctioning... > Here's a quick batch of tests I ran: > > wall time | speed Bps | EPIPEs > ------------------------------ low load, no limit > 37.628157 | 544772 | 0 > 37.797504 | 541835 | 1 > 37.613491 | 544984 | 0 > 37.807000 | 542195 | 0 > ------------------------------ low load, ohcl host > 51.061969 | 401449 | 0 > 50.537478 | 405615 | 0 > 50.677527 | 404494 | 0 > 50.502911 | 405893 | 0 > ------------------------------ no load, schedule() > 37.810688 | 542142 | 0 > 37.868029 | 541321 | 0 > 37.958808 | 540026 | 1 > 37.770085 | 542725 | 0 > ------------------------------ high load, no limit > 45.54988 | 450029 | 1 > 56.863098 | 360493 | 1 > 83.509111 | 245467 | 1 > 82.827214 | 247488 | 0 > ------------------------------ high load, sleep(50ms) > 100.767380| 203427 | 0 > 100.870890| 203218 | 0 > 100.739756| 203482 | 0 > ------------------------------ high load, sleep(10ms) > 50.597539 | 405134 | 0 > 50.372042 | 406947 | 0 > 50.594270 | 405160 | 0 > ------------------------------ high load, sleep(5ms) > 44.373462 | 461960 | 0 > 44.576646 | 459854 | 0 > 44.452869 | 461135 | 0 > ------------------------------ high load, schedule() > 78.141574 | 262328 | 0 > 76.179661 | 269084 | 0 > 79.868304 | 256657 | 0 > 84.962858 | 241267 | 0 > > (In the above tests, I call schedule() or sleep() just before the > control command is issued.) > > At first glance, it looks like you could be right, that the device can't > handle speeds above.. 500000Bps-ish. > > Thoughts? It also looks like the OHCI controller is significantly slower than the UHCI controller, which is not what one would expect. Maybe your best bet is simply always to use msleep(10) or msleep(5). Alan Stern ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
