On Tue, Apr 10, 2001, Sancho Dauskardt <[EMAIL PROTECTED]> wrote:
> I had major performance problems reading the SSFDC mapping table: that
> involed to usb_stor_bulk_msg() for each of the 4096 blocks and took around
> 17 sek (and only around 6 sek same device under Win98 ).. I guessed that
> this could possibly be a schedluing issue, and tried following:
>
> master_XXX is supposed to be the 'Command URB'
> slave_XXX is supposed to be the 'Data URB' which results out of the command
> urb.
[snip]
> And is got a speedup factor 2 (same device now only takes around 8 sek to
> read mapping table). I still dont quite understand why this ist faster ?
> Does it do one schedule() less, due to the second URB already being finished ?
Could be. Also, there's a 1ms delay for notification that an URB
finished completing. The fact you submit two now eliminates one of them.
> I guess all devices using plain bulk interface will suffer from this
> problem, only with no so large impact;
> How should usb_stor_bulk_combo_msg() react, when the first fails ?
It shouldn't try transferring data on the slave I would guess. This is
probably up to the spec or device to say if that's a bad idea.
> If we can make this reliable, then it should be used in
> usb_stor_Bulk_transport() ?
I'll leave that up to Matthew to determine :)
JE
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
