[BETA-0.94] Fifth test release of Tigon3 driver

[BETA-0.94] Fifth test release of Tigon3 driver

[David S. Miller]

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...

Re: [BETA-0.94] Fifth test release of Tigon3 driver

[Thomas Langås]

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

Re: [BETA-0.94] Fifth test release of Tigon3 driver

[Jeff Garzik]

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.

Re: [BETA-0.94] Fifth test release of Tigon3 driver

[Thomas Langås]

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

Re: [BETA-0.94] Fifth test release of Tigon3 driver

[Jeff Garzik]

Thanks much!
-- 
Jeff Garzik      |
Building 1024    |
MandrakeSoft     | Choose life.

Re: [BETA-0.94] Fifth test release of Tigon3 driver

[Thomas Langås]

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

Re: [BETA-0.94] Fifth test release of Tigon3 driver

[David S. Miller]

   From: Thomas Langås <tlan@stud.ntnu.no>
   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.

Re: [BETA-0.94] Fifth test release of Tigon3 driver

[Steffen Persvold]

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:sp@scali.com |  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