Re: [Libusb-devel] bulk/interrupt semantics

[Tim R. <ti...@pr...>]

Lou wrote:
> Is there semantically any difference between bulk and interrupt
> functions in libusb?  I know that one should use the correct one for the
> endpoint type, but I am designing the device (full speed, in case that
> matters), too, and can control whether my IN endpoint is bulk or interrupt.
> >From the point of view of my program using libusb (0.1 until 1.0 gets into
> Ubuntu), is there any semantic difference?
>   

No.  There is no difference in usage.  In the kernel, they both funnel 
to the same handler.  Functionally, the ONLY difference between a bulk 
endpoint and an interrupt endpoint is in the scheduling.  An interrupt 
endpoint gets reserved bandwidth, and can only transfer during its 
assigned slot.  The protocol exchange is absolutely identical.

So, you are both guaranteed a slot, and limited only to that slot.

> What exactly _is_ the difference?  I assume the host will send IN tokens
> to the endpoint at the interval rate for an interrupt endpoint.

Yes, if a read request from a driver is pending.

> But,
> then it will send IN tokens at some unspecified rate (maybe once per
> frame) for a bulk endpoint that is NAKing.  So maybe the difference is a
> matter of reducing bus traffic by using an interrupt endpoint with an
> interval greater than 1ms.  By the same logic, using an interrupt
> endpoint would seem to increase latency and limit my throughput, which
> is expected to be quite bursty and may include long periods of no traffic
> whatsoever.
>   

That's a pretty good summary.  Consider a keyboard.  You don't want 
keyboard packets to be deferred indefinitely if video is streaming.  As 
a result, it's a perfect candidate for an interrupt endpoint, and that 
is in fact what HID devices use.

> Does the host controller
> or its driver somehow prioritize tokens for endpoints that have previously
> NAKed lower than those which have not, possibly even omitting them when
> the frame is full?  It's been awhile since I had my head that deeply in
> the low-level workings of the USB protocol.
>   

I don't think the protocol specifies to this level.  Perhaps the UHCI or 
EHCI specs do, but I'd be surprised.  The spec certainly does delineate 
what percentage of the frame may be chewed up by bulk packets.

> My application is a command/response scheme, which would be suited to
> bulk, except that it also allows for (quite possibly interleaved)
> unsolicited messages, which might suggest interrupt.  All input traffic
> (unsolicited messages and command responses) is asynchronous relative to
> the command calls.
>   

If the traffic is irregular and occasionally high-volume, as you seem to 
imply, then it would seem to be a perfect candidate for a bulk pipe.  
Just keep a read pending at all times, and as soon as your device is 
ready to transmit, it will come across.

> So far, it is working fine with bulk, but if I can make it more
> efficient without undue latency or otherwise limiting throughput, I'm, of
> course, interested in doing so.

Efficient for who?  It's not really hurting anything to have NAK tokens 
bouncing back and forth on the wire.

-- 
Tim Roberts, ti...@pr...
Providenza & Boekelheide, Inc.