Re: [libusb] Data loss with libusb async (libusb 1.0.22)

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

On 10/1/22 08:44, Dan Cimpoca via libusb-devel wrote:

> My program blocks 4.16ms reading from a timerfd file descriptor. It then calls libusb_handle_events_timeout_completed(); this invokes callback function OnReadCompleted() when a transfer is completed. The callback function OnReadCompleted() clears a flag and uses the data received from device. Then, if the flag is cleared, it triggers a new interrupt transfer; the buffer/length of the transfer is set large enough, so that the there's no chance of it becoming full before the transfer timeout (8ms) expires.

That's not the right design.  You should submit one transfer with no 
timeout and leave it outstanding.  As soon as it is completed, you 
immediately resubmit and then go process the packet.

Here's the problem.  USB frames are scheduled in advance.  The host 
controller driver makes up a schedule of all of the transfers to be 
completed during the next frame and submits that schedule to the 
hardware, which then executes the list on its own.  The HCD then starts 
thinking about the next frame.

What that means is, if you don't have a read request already submitted 
and waiting when the HCD is scheduling the frame, you will miss that 
frame.  The HCD will not send an IN token, and your device will not be 
given a chance to transmit, even if it is your scheduled interval.  If 
your device doesn't have enough buffering, things overflow and packets 
are dropped.

So, don't try to outguess the frame timing.  Just leave a request 
permanently queued.

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