tg3 (netgear 302t) performance numbers

tg3 (netgear 302t) performance numbers

[Ben Greear]

After placing my Netgear 302t NICs into my SS50 P-IV (1.8Ghz)
machine, they seem to work fine.  (They had various problems in
my AMD machines, but that could all just be coincidence and other,
non-related, problems)

My test-bed has two of these NICs connected to each other via
a cross-over cable.  Both NICs are in the same machine...

Here are some performance numbers I see:

tcp/ip send + receive in user-space:
   112Mbps on each port (does not count any packet over-head,
     and my generator/receiver is not the fastest thing around)

pktgen (kernel pkt generator module):
   60-byte packets, sending 1kpps in one direction, and maximum possible
   in the other.  Was able to generate 122,000 packets-per-second.
   (A tulip 10/100 NIC can do 140kpps in this configuration)
   Average Latency: 22 micro-seconds.
   0 dropped packets over 10+ minute run.

   1514-byte packets, sending 1kpps in one direction, max possible in
   the other.  25.8kpps (310Mbps) in the fast direction.
   Average Latency:  17 miliseconds (127 micro-seconds for the 1kpps direction)
   2000 dropped pkts, 5.8 million sent during this test.


So, not too bad, probably the 32/33 PCI bus is most of the bottle-neck.
The good part is, no errors or other strangnesses were seen with the driver.

Enjoy,
Ben

-- 
Ben Greear <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: tg3 (netgear 302t) performance numbers

[Ben Greear]

Ben Greear wrote:

> pktgen (kernel pkt generator module):
>   60-byte packets, sending 1kpps in one direction, and maximum possible
>   in the other.  Was able to generate 122,000 packets-per-second.
>   (A tulip 10/100 NIC can do 140kpps in this configuration)
>   Average Latency: 22 micro-seconds.
>   0 dropped packets over 10+ minute run.

An update to this.  This previous test, I was allocating a new skbuf
each time.  For pure pkt crunching (ie sending the same pkt over and over
again), the throughput was more like 170kpps.


-- 
Ben Greear <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear