Fifth test release of Tigon3 driver
This release is code named "Ginseng" in honor of the healing properties it will have for your machine:
ftp://ftp.kernel.org/pub/linux/kernel/people/davem/TIGON3/tg3-0.94.patch.gz
Healing list:
[FIX] Some DELL variants not monitoring PHY link status properly. [FIX] RX ring could still empty and hang chip. TX/RX paths completely
revamped. People please beat on this sucker hard.
[FIX] Jumbo RX buffer sizing wrong.
[FIX] RX ring replenish threshold settings were inaccurate. [FIX] VLAN layer forgets to set dev->last_rx
[FEATURE] Syskonnect and Altima AC1000 Tigon3's supported. [FEATURE] Full 5703/5702fe/5702x support. Please test if you have
these chips since we don't :(
Have at it.
How does this thing perform for people? In particular lmbench 'bw_tcp' and 'lat_tcp' numbers over gigabit on beefy hardware are considered very interesting...
David S. Miller:
Quoted 3 lines
How does this thing perform for people? In particular lmbench '
bw_tcp' and 'lat_tcp' numbers over gigabit on beefy hardware are considered very interesting...
Ok, here I am again; doing some benchmarking :)
(all this is done with same hardware as before, and your tg3 v0.94 driver in both ends):
test8:/usr/src/LMbench/bin/i686-pc-linux-gnu# ./bw_tcp 129.241.56.160 initial bandwidth measurement: move=10485760, usecs=117352: 89.35 MB/sec move=693633024, XFERSIZE=65536 Socket bandwidth using 129.241.56.160: 104.73 MB/sec
test8:/usr/src/LMbench/bin/i686-pc-linux-gnu# ./lat_tcp 129.241.56.160 TCP latency using 129.241.56.160: 100.0089 microseconds
Do you want any more benchmark; just say so :)
Signature · 1 line
Thomas
Quoted 5 lines · Thomas Langås
David S. Miller:
Quoted 3 lines
How does this thing perform for people? In particular lmbench '
bw_tcp' and 'lat_tcp' numbers over gigabit on beefy hardware are considered very interesting...
Quoted 9 lines
Ok, here I am again; doing some benchmarking :)
(all this is done with same hardware as before, and your tg3 v0.94 driver in both ends):
test8:/usr/src/LMbench/bin/i686-pc-linux-gnu# ./bw_tcp 129.241.56.160 initial bandwidth measurement: move=10485760, usecs=117352: 89.35 MB/sec move=693633024, XFERSIZE=65536 Socket bandwidth using 129.241.56.160: 104.73 MB/sec
Hi guys,
Excuse me for beeing off topic here, but I'm running the LMbench TCP test on a ethernet emulation driver I've written for SCI, and I can't seem to get the correct numbers. This is what I get :
sci3:/root# ./bw_tcp sci4 initial bandwidth measurement: move=10485760, usecs=60059: 174.59 MB/sec move=1365245952, XFERSIZE=65536 Socket bandwidth using sci4: 371.53 MB/sec
The initial measurement seems ok (based on the chipset and so on), but the last one is _way_ too high. Can it be that the bw_tcp test measures it wrongly ? Maybe this is a case for the LMbench maintainer...
Regards,
Signature · 4 lines
Steffen Persvold | Scalable Linux Systems | Try out the world's best mailto:[email protected] | http://www.scali.com | performing MPI implementation: Tel: (+47) 2262 8950 | Olaf Helsets vei 6 | - ScaMPI 1.13.8 - Fax: (+47) 2262 8951 | N0621 Oslo, NORWAY | >320MBytes/s and <4uS latency
Quoted 15 lines · Thomas Langås
David S. Miller:
Quoted 3 lines
How does this thing perform for people? In particular lmbench '
bw_tcp' and 'lat_tcp' numbers over gigabit on beefy hardware are considered very interesting...Ok, here I am again; doing some benchmarking :)
(all this is done with same hardware as before, and your tg3 v0.94 driver in both ends):
test8:/usr/src/LMbench/bin/i686-pc-linux-gnu# ./bw_tcp 129.241.56.160 initial bandwidth measurement: move=10485760, usecs=117352: 89.35 MB/sec move=693633024, XFERSIZE=65536 Socket bandwidth using 129.241.56.160: 104.73 MB/sec
Quoted 4 lines
test8:/usr/src/LMbench/bin/i686-pc-linux-gnu# ./lat_tcp 129.241.56.160 TCP latency using 129.241.56.160: 100.0089 microsecondsDo you want any more benchmark; just say so :)
I am always interested in more benchmarks, never ask this question :):)
A comparison between bcm5700 and tg3 would be interesting, for each new release, if you were willing to do that.
And, what MTU are you using? You may have answered this earlier and I forgot :) If you -are- on a gigabit network, then you [currently] must manually enable an MTU of 9000 (jumbo frames).
Jeff
Signature · 3 lines
Jeff Garzik | Building 1024 | MandrakeSoft | Choose life.
Jeff Garzik:
Quoted 2 lines
A comparison between bcm5700 and tg3 would be interesting, for each new release, if you were willing to do that.
Ok, sure :) We're going to switch our fileserver as soon as this goes into
mainstream-kernel, so I'm always happy to help with the testing to get the best possible driver :)
Quoted 3 lines
And, what MTU are you using? You may have answered this earlier and I forgot :) If you -are- on a gigabit network, then you [currently] must manually enable an MTU of 9000 (jumbo frames).
Ok, I'll try with jumbo frames; and with the bcm5700 driver and come back with results in abit.
Signature · 1 line
Thomas
Thanks much!
Signature · 3 lines
Jeff Garzik | Building 1024 | MandrakeSoft | Choose life.
Jeff Garzik:
Quoted 3 lines
And, what MTU are you using? You may have answered this earlier and I forgot :) If you -are- on a gigabit network, then you [currently] must manually enable an MTU of 9000 (jumbo frames).
First mail with MTU 9000, tg3 in both ends:
test8:/usr/src/LMbench/bin/i686-pc-linux-gnu# ./lat_tcp 129.241.56.160 TCP latency using 129.241.56.160: 146.3539 microseconds
However, there seems to be a problem with the bw_tcp-tool, cause it just hangs, trying to strace it won't gimme me much usefull info about why it hangs either. (it worked like a charm with 1500 MTUs).
Ok, right now I just tried the nttcp tool (which I used to benchmark this driver in an earlier posting), it seems like there's a bug with MTU 9000 and TCP:
[this is UDP, works like a charm]
kiwi:/usr/src# /root/nttcp-1.47/nttcp -t -u -v 129.241.56.161 nttcp-l: nttcp, version 1.47 nttcp-l: Pid=10519 nttcp-l: from 129.241.56.161: "129.241.56.161" (=nttcp-1: Pid=3197, InetPeer= 1) nttcp-l: from 129.241.56.161: "129.241.56.161" (=nttcp-1: Optionline="nttcp@-r@) nttcp-l: from 129.241.56.161: "129.241.56.161" (=dataport: 5038) nttcp-l: send window size = 65535 nttcp-l: receive window size = 65535 nttcp-l: buflen=4096, bufcnt=2048, dataport=5038/udp nttcp-l: try to get outstanding messages from 1 remote clients nttcp-l: transmitted 8388608 bytes l 8388608 0.07 0.02 993.7049 3355.4432 2051 30369.89 102550.0 nttcp-l: try to get outstanding messages from 1 remote clients nttcp-1: got EOF nttcp-1: received 0 bytes 1 0.07 0.00 0.0000 0.0000 1 14.64 100000.0 nttcp-1: exiting
[and this is TCP, doesn't exactly work like a charm]
kiwi:/usr/src# /root/nttcp-1.47/nttcp -t -v 129.241.56.161 nttcp-l: nttcp, version 1.47 nttcp-l: Pid=10520 nttcp-l: from 129.241.56.161: "129.241.56.161" (=nttcp-1: Pid=3198, InetPeer= 1) nttcp-l: from 129.241.56.161: "129.241.56.161" (=nttcp-1: Optionline="nttcp@-r@) nttcp-l: from 129.241.56.161: "129.241.56.161" (=dataport: 5038) nttcp-l: send window size = 27900 nttcp-l: receive window size = 87380 nttcp-l: buflen=4096, bufcnt=2048, dataport=5038/tcp nttcp-l: try to get outstanding messages from 1 remote clients nttcp-1: accept from 129.241.56.160 nttcp-l: try to get outstanding messages from 1 remote clients nttcp-1: send window size = 27900 nttcp-1: receive window size = 87380 nttcp-l: try to get outstanding messages from 1 remote clients nttcp-1: buflen=4096, bufcnt=2048, dataport=5038/tcp
[cause here it hangs]
I can still stop the program with CTRL-C, so I dont' know what it is, someone enlighten me, please? :)
Signature · 1 line
Thomas
From: Thomas Langås <[email protected]>
Date: Mon, 4 Mar 2002 17:26:17 +0100
However, there seems to be a problem with the bw_tcp-tool, cause it just hangs, trying to strace it won't gimme me much usefull info about why it hangs either. (it worked like a charm with 1500 MTUs).
Expect a 0.95 release later tonight, which should fix this.