On Sunday 27 May 2007, Michael Buesch wrote: > On Sunday 27 May 2007 21:25:17 Maximilian Engelhardt wrote: > > 2.6.22-rc3: > > > > [ 5] local 192.168.1.2 port 46557 connected with 192.168.1.1 port 5001 > > [ 5] 0.0-60.4 sec 58.9 MBytes 8.18 Mbits/sec > > [ 4] local 192.168.1.2 port 5001 connected with 192.168.1.1 port 51633 > > [ 4] 0.0-63.1 sec 7.27 MBytes 967 Kbits/sec > > Why do we have two different measurements here? Is one TX and one RX? > Which one? Yes, the first is TX (BCM4401 --> e100) and the second is RX. Both are tcp connections. I think iperf does display the ip addresses wrong in the second connection, but that's another issue. > > > koala:~# ping -c10 192.168.1.1 > > PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. > > 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.243 ms > > 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.234 ms > > 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.238 ms > > 64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.235 ms > > 64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=0.230 ms > > 64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=0.317 ms > > 64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=0.232 ms > > 64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=0.232 ms > > 64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=0.228 ms > > 64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=0.238 ms > > > > --- 192.168.1.1 ping statistics --- > > 10 packets transmitted, 10 received, 0% packet loss, time 8997ms > > rtt min/avg/max/mdev = 0.228/0.242/0.317/0.031 ms > > > > System responsiveness was the same as with 2.6.21.1. > > > > wget got 11.23M/s, again same as 2.6.21.1. > > > > > > 2.6.22-rc2-mm1: > > > > [ 5] local 192.168.1.2 port 42198 connected with 192.168.1.1 port 5001 > > [ 5] 0.0-60.1 sec 402 MBytes 56.1 Mbits/sec > > [ 4] local 192.168.1.2 port 5001 connected with 192.168.1.1 port 48598 > > [ 4] 0.0-63.0 sec 177 MBytes 23.6 Mbits/sec > > So with -mm (with ssb) you actually get better performace > then with plain 2.6.22-rc3? > > Can you elaborate a bit more about what you get an what you expect > on which kernel? When I ran 2.6.21.1 or 2.6.22-rc3 without any debugging tools just in normal use I didn't notice any problems. It did work fine as I would expect it. I think the wget and ping tests here are as they should be. With 2.6.22-rc2-mm1 I noticed that connections seem to be slower. The ping test does confirm this, because here response times are very high. As far as I can remember the wget download rate was a bit slower than 2.6.21.1 or 2.6.22-rc3 till it stalled. I would expect it to be someting like the other two kernels. The two problems I see are the high ping times and the fact that the card stopped working. I don't know why the iperf results are so different from my personal experience. I guess the fact that I get so bad results with 2.6.21.1 and 2.6.22-rc3 is that iperf does something that causes the system to be extremely slow and thus degrading performance. This could be a bug somewhere in the b44 driver of 2.6.21.1 and 2.6.22-RC3 that has unintended been fixed by the ssb switch, but that's only a roughly guess. Maxi
Attachment:
signature.asc
Description: This is a digitally signed message part.
- Follow-Ups:
- Re: b44: regression in 2.6.22 (resend)
- From: Michael Buesch <[email protected]>
- Re: b44: regression in 2.6.22 (resend)
- References:
- Re: b44: regression in 2.6.22 (resend)
- From: Maximilian Engelhardt <[email protected]>
- Re: b44: regression in 2.6.22 (resend)
- From: Michael Buesch <[email protected]>
- Re: b44: regression in 2.6.22 (resend)
- Prev by Date: Re: [2.6.21.1] soft lockup when removing netconsole module
- Next by Date: [PATCH] Update isdn tree to use pci_get_device
- Previous by thread: Re: b44: regression in 2.6.22 (resend)
- Next by thread: Re: b44: regression in 2.6.22 (resend)
- Index(es):