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:
> 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 :)
--
Thomas
Thomas Lang?s wrote:
>
> David S. Miller:
> > 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 :)
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
--
Jeff Garzik |
Building 1024 |
MandrakeSoft | Choose life.
Jeff Garzik:
> 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 :)
> 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.
--
Thomas
Thanks much!
--
Jeff Garzik |
Building 1024 |
MandrakeSoft | Choose life.
Jeff Garzik:
> 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? :)
--
Thomas
On Mon, 4 Mar 2002, Thomas Lang?s wrote:
> David S. Miller:
> > 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
>
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,
--
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
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.