Solution: TX performance problems with 3Com 905C cards

[David Burns]

Mike Silbersack wrote:

> On Thu, 19 Feb 2004, Marian Durkovic wrote:
> 
> 
>>Hi all,
>>
>>
>>   the performance problem seems to disappear, when the hardware checksuming
>>for TX direction is disabled (RX hw checksuming still on).
>>Here are the results:
> 
> 
> Hm...  This, combined with Matt blaming the Tx checksum for corrupting
> packets seems to spell the end for 3Com 905 checksumming.  I'll turn it
> off in a few days.
> 
> Thanks for the good detective work.
> 

Putting the corrupted packets issue aside I have no problem with a 
3c905c hitting 92 Mb/s on a old celeron 333 using a modified if_xl.c 
under fbsd 4.5:

blah# ttcp -r -s
ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp
ttcp-r: socket
ttcp-r: accept from 192.168.63.20
ttcp-r: 33554432 bytes in 2.91 real seconds = 11262.49 KB/sec +++
ttcp-r: 10210 I/O calls, msec/call = 0.29, calls/sec = 3509.22
ttcp-r: 0.0user 0.5sys 0:02real 18% 15i+207d 196maxrss 0+2pf 10184+9csw

blah# ttcp -t -s -n4096 stink
ttcp-t: buflen=8192, nbuf=4096, align=16384/0, port=5001  tcp  -> stink
ttcp-t: socket
ttcp-t: connect
ttcp-t: 33554432 bytes in 2.90 real seconds = 11309.62 KB/sec +++
ttcp-t: 4096 I/O calls, msec/call = 0.72, calls/sec = 1413.70
ttcp-t: 0.0user 0.6sys 0:02real 24% 19i+299d 246maxrss 0+2pf 10154+1csw

The modification was to reduce the NIC interrupt rate via a rudimentary 
hardware polling scheme based on the 3c905x countdown timer.

Can't find the notes I made on the performance improvement although it 
was reasonable (something like 5-10% if my memory is correct) for my
hardware.

Probably should have someone with more understanding of kernel drivers 
check whether it has any application outside my home office... :-)

David