Re: [Linux-usb-users] USB: Non zero status

Alan Stern schrieb:
> On Fri, 17 Aug 2007, Martin Bachem wrote:
> 
>> sending more than 8 packets per ISO URB is quite problematic regarding
>> the flow control implemented in the driver. The Fifos are just capable
>> of 128 bytes, and I have to make sure they never run empty and never
>> overflow while sending one HDLC frame.
>> The ISDN controllers status information of each fifo's threshold reached
>> is retrieved in every rx-iso URB, so I get this asynchronously to the TX
>> ISO completions. To forecast the outgoing data rate in order to predict
>> the threshold-reached event is also not very simple due to the ISDN
>> Controller's HDLC encoding, because the ISDN controller is adding Flags,
>> bit-stuffing, etc., but has a constant data rate of 64Kbit/s...
>>
>> whatever, I think I can boost the num-packets per ISO URB from 8 up to
>> 12. Do you think this matters regarding the -EXDEV Error? If it's not
>> likely that this will relax the situation, I'll keep the flow control as
>> is ;)
> 
> Another way to avoid problems would be to keep 8 packets per URB and
> use more URBs per endpoint.
> 
> The missing-packet-data problem occurs when the host controller reaches
> the end of the endpoint's queue of URBs, and that happens when an IRQ
> is delayed long enough for the queue to drain completely.  By keeping
> more total packets in the queue, no matter how they are divided up
> among URBs, you make it less likely that a delay will cause the queue
> to drain.  The disadvantage is that you also increase the latency for
> new data fed into the queue.

yes, for me it does not matter if I use more URBs (I already use 2 per
endpoint), or if I use more packets per URB. The problem of too much
pending data which might produces a fifo overrun is the same than.

> The real issue here is that drivers don't have any way to specify, when 
> they submit an Iso URB, whether the URB's packets should be allocated 
> 
>     (1) into the time slots immediately following the end of the 
> 	previous URB, even if those slots have already expired, or
> 
>     (2) into the next available time slots, even if that means leaving
> 	a gap between the last URB and this one.
> 
> Right now uhci-hcd always uses (1) and the other HCDs use (2).  You 
> probably want to use (2), right?  And you get these errors because 
> sometimes your URBs are submitted too late and the time slots have 
> expired.

many thanks for your explaination. The issue occures at ehci-hcd
currently. And if the error code -EXDEV could mean the ISO packets are
transmitted too late, than no Data could be lost at all, right? The
fifos should buffer that gap in the ISO stream...

Martin Bachem



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel