On Tue, Oct 05, 2004 at 03:46:09PM -0400, Alan Stern wrote:
> > > > 90% of the time, I can
> > > > work around by re-issuing the request (once). But the other 10% of the
> > > > time, *both* requests succeed--even the original one that returned
> > > > -EPIPE.
> > >
> > > How do you know the request succeeded? What _was_ the request anyway?
> >
> > Good question: I know because I've pulled my hair out trying to debug it. ;)
> >
> > The request is "please send me the next x bytes of data". Normally, you
> > would issue a bulk transfer immediately after the control message to
> > fetch the actual data. If you don't, it just skips those x bytes.
> >
> > You can tell when two requests succeeded because "end of file" arrives
> > early, and the downloaded file is completely missing a block.
>
> 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?)
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.)
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?
> > I don't know enough about the usb subsystem to speculate.. but a busy
> > disk would keep the system bus and interrupt controller busy. Could
> > that be it?
>
> Something like that definitely could affect timing. It's unlikely to have
> any other effects though, and not on the contents of the data packets.
But how could it effect timing in a *bad* way? (Where 'bad' in this
context means 'delays that are way too short'.)
Anyways, I'll have to experiment more later.. let me know if you have
any thoughts on the subject. Thanks,
Geoff
--
PGP fingerprint: 8ADC 92E1 6782 D034 E0E3 8EF4 EA4D 25E3 C17C 48D2
"If you want to learn more about guns, get a job at [an American]
convenience store or visit our website at ... " --Michael Moore
-------------------------------------------------------
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
