[linux-tr] ibmtr.c error.

[Paul Norton <pnorton@ccnusa.com>]

Mike Phillips writes:
 > Paul,
 > 
 > I may have found a bug in in the ibmtr.c code relating to dhb and mtu sizes.  I was playing around with mtu size testing throughput to/from the new pci driver.
 > 
 > ibmtr.c started giving xmit ret_cde 28 (length > dhb) error messages when I set the mtu size to 18000.  Playing around with the mtu size, I isolated it down to the exact mtu size = 17933.
 > 
 > Makes sense, 17932 + TR_HLEN = 17960 = 16mb_dhb for 64K shared ram.

Hmmm...I thought I put in (and tested) a bounds check.  I'll check it...

 > Also, interestingly ibmtr.c (or my isa card) is fastest with the mtu set around 8000 (I didn't test exhaustively, so I would think entire frame < 8192), increasing it over this almost halved the transfer times.
 > 
 > The pci card handles any size - but then it is using system memory, which is far, far easier to use than having to copy from/to shared ram. Utmost respect to all who battle with the shared ram monster.

Actually it won't handle any size since there are limitations built
into the protocol - namely the maximum time allowed for a token to
circumnavigate the ring.  That puts an upper bound on the size of a
frame. (Am I being pedantic?)

 > FYI: On a dedicated hub with only the two machines running I was getting bit rates upto 15,054,663 bits / sec, 89% of maximum ring speed - not too shabby.

Is that PCI->PCI, or PCI->Shared-RAM?

 > On a more ambigious note - Peter and I are looking into the multicast stuff, any suggestions, helpful hints etc.

I'll dig up what I've got and send it to you.