[PATCH][RFC] usbatm.[ch]: cleanup and OAM F5 loopback

[Roman Kagan]

Sorry for being slow replying, was too busy lately...

On Mon, Mar 14, 2005 at 07:02:18PM +0100, matthieu castet wrote:
> Roman Kagan wrote:
> >On Sun, Mar 13, 2005 at 11:21:35PM +0100, matthieu castet wrote:
> >
> >>I wasn't able to reproduce crc errors, but I have "bogus pdu_length" and
> >>all the status are correct.
> >>"bogus pdu_length" indicate it miss data in the atm trame ?
> >
> >
> >Then the modem doesn't seem to be guilty.  The message means that your
> >ISP sends data in bigger units than was requested by the ATM layer or
> >userspace (e.g. pppd), and from your log I gather that the difference
> >is no greater than 48 bytes (usbatm aligns the PDU to ATM payload).
> There are all greater that 48 bytes [1].
> And because ATM_CELL_PAYLOAD is 48, it seem there are missing atm cells.

Yep, I should have looked at the code before replying...  You're right,
cells are lost somewhere.

> >I guess you need to check MRU setting in pppd (or similar stuff in
> >whatever higher level protocol you are using).
> I use IP over atm.
> I change the mtu with ifconfig and it does nothing.

No wonder, my advice was total nonsense :(

> $sudo grep "bogus pdu_length" /var/log/syslog | awk '{printf "%d %d %d 
> %d\n", $10 - $12,($10 - $12)/48, $10, $12}' | sort -n | uniq
> 48 1 1008 960
> 48 1 1440 1392
> 48 1 1536 1488
> 96 2 1008 912
> 96 2 1440 1344
> 96 2 1536 1440
> 144 3 1008 864
> 144 3 1440 1296
> 144 3 1536 1392
> 192 4 1440 1248
> 192 4 1536 1344
> 240 5 1440 1200
> 240 5 1536 1296
> 288 6 1440 1152
> 288 6 1536 1248
> 336 7 1440 1104
> 336 7 1536 1200

The cell loss seems to happen for rather big PDUs.  Sounds like the host
computer is sucking the data from the modem too slowly, so the latter
has to drop cells on the floor.  Haven't you tried increasing the
buffer size and the number of urbs?  This might help for big PDUs.

Roman.