[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[linux-tr] ibmtr.c error.
Mike Phillips writes:
> 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.