[RFC] [PATCH] usbatm.[ch]: multiple changes

[Roman Kagan]

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
mode.

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.

OK.

Cheers,
  Roman.