> I'm puzzled about this thread. As I understand the discussion, seems that > someone is using an interrupt out for a small amount of data and, for some > unknown reason, the last data packet is being resent on each "interrupt" > interval. ...
There are some known reasons this failure mode might happen ... > So, if the hardware is working correctly, the only thing that should cause > the last packet to be resent is if the driver has made a mistake. Yes. Such as not unlinking the interrupt URB when all the INTR-OUT data had been sent. (Such a mistake is somewhat understandable, considering the history of INTR-OUT transfers, and the fact that it's currently rude to unlink these portably.) But if this were happening for an INTR-IN transfer, I'd suspect a device firmare bug. > BTW, the purpose of the interrupt endpoint is to provide guaranteed latency. > When combined with an allowed packet size, this just happens to give > guaranteed bandwidth. However, because of the possibility of errors and > retries, the bandwidth is not the guaranteed throughput but simply a > guarantee of access to bandwidth. So likewise, it's not exactly a "guarantee" of latency ... at least, not from the perspective of the drivers that want it! Neither maximum latency (due to error recovery) nor minimum latency (period 20 often shrinks to 16) is guaranteed for interrupt transfers. :) But that's a good clarification. Both kinds of periodic transfer (INTR and ISO) pre-schedule transfers, so best (and typical) cases see better latency and throughput. Since ISO doesn't retry, it gets more consistent driver-visible latency, but the cost is more reports of failed transfers. But in both cases, the bandwidth is reserved, so if there are no errors at least bus-level latency is guaranteed. - Dave _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
