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.
>
Lets say we have a USB device with a 32ms interrupt endpoint. The
device has data ready at the interrupt endpoint every 1s. All
requests in between will be answered with a NAK.
If we service this device with a periodic interrupt request every 32 ms
we have exactly one transfer every 32 ms. All of them with a NAK and
after a second we get data (about 30 transfers / s).
Now if we schedule a BULK transfer for the interrupt transfer we get an
arbitrary number of BULK requests every frame. All of them with a NAK
and after one second we get data (about 1000*n transfers / s).
That's the difference.
- Roman
> > 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.
>
> If any HCD is so unfair with its scheduling that reserved bandwidth
> that a bulk request gets starved, that's a bug in the HCD (IMO).
>
> No device may expect better bulk service than seeing
> that the transfer "eventually" happens; that's not something
> that USB guarantees.
>
> - Dave
>
> _______________________________________________
> [EMAIL PROTECTED]
> To unsubscribe, use the last form field at:
> http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
