On Thu, 17 May 2001, David Brownell wrote:
>> 2.Polling interval
>
>I don't see why this is a different issue than #3 ... it argues
>that treating interrupt urbs as bulk is incorrect, but that's
>not news.
Becuase some low-speed devices can't handle fast polling. When I say "can't
handle", I mean they stop doing anything except NAKing, regardless of what they
should be doing.
>> 3.Guaranteed polling
>> Interrupt URBs are (supposed to be) guaranteed to poll at certain intervals.
>> Bulk URBs are not, so it is possible that under high bus load the device
>> is starved and data is lost. I know this is a very unlikely, remote case,
>> but it is possible.
>
>Umm ... interrupt urbs are periodic, bandwidth guaranteed
>once the URB is scheduled. Bulk fits into the 10-20% chunk
>of bandwidth reserved for bulk/control (see usb 2.0 spec
>section 5.5.4), and whatever is left after periodic schedule
>commitments are obeyed.
That 10% is for Control. If there is time left after Control is done, Bulk gets
the rest. If there is no time left, Bulk doesn't go. Bulk is not guaranteed at
all (see USB spec sec 5.8).
>No device may expect better bulk service than seeing
>that the transfer "eventually" happens; that's not something
>that USB guarantees.
Right, that's the problem. Interrupt service is guaranteed, bulk isn't.
--
Dan Streetman
[EMAIL PROTECTED]
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
