[RFC] [PATCH] usbatm.[ch]: multiple changes
rkagan at mail.ru
Mon Apr 4 01:06:26 EDT 2005
On Sun, Apr 03, 2005 at 10:48:30PM +0200, matthieu castet wrote:
> Roman Kagan wrote:
> >On Fri, Apr 01, 2005 at 08:05:30PM +0200, matthieu castet wrote:
> >>Roman Kagan wrote:
> >>>Hmm, if you use 1007 bytes == 19 cells per iso frame (you don't use
> >>>padding, do you?) and want 16 iso frames per urb you need buffer size of
> >>>19 * 16 = 304. 503 shouldn't be a problem too, however, from the
> >>>aesthetic POV I'd suggest a multiple of iso frame size, say 494 or 513.
> >>well I need to investigate, I set it to 304 and it work well :)
> >Wow! I'm really glad to hear that! Still, playing with buffer size
> >would be interesting...
> Yes, using the default (64) make it worse : 8Ko/s and lot's of error.
> I think I will try to do a script for doing a test automatically.
> Have you got an idea of the range and the interval of the buffer size
> for the test ?
None whatsoever. IMHO it may make sense to try a multiple of iso frame
size, and something off.
FWIW I've taken a look at the code from eagle-usb.org, and they are
using 16 iso frames per urb in iso mode and 64 atm cells per urb in bulk
BTW are you basing your code on theirs?
> No there still -EILSEQ errors, but in your code there a timer, that
> resubmit in case of error. But yes, your patch ignoring -EILSEQ is needed.
> I also try on an intel chipset and there is the same error...
Then I would seriously consider trying to replace cable / firmware /
modem. There are no workarounds for -EILSEQ in eagle-usb.org code, nor
there's any reference to the kind of errors you see in their forum or
docs, which makes me suspect a hardware problem.
> >Right, I didn't realize that there might be a pattern of repetitive
> >successes on submission and failures on completion. What would be a
> >better way to handle this? Introduce separate counters for subission
> >and completion?
> Yes separate counters could be a solution.
More information about the Usbatm