ipw3945 slow and buggy with linux-restricted-modules-2.6.22-14-generic_2.6.22.4-14.10_amd64.deb

[ski]

ipw3945 is slow and unreliable to point of not being usable after upgrading to linux-restricted-modules-2.6.22-14-generic_2.6.22.4-14.10_amd64.deb

even ping is slow, and seems to be caught in some uninterruptable state as ^C doesn't kill it for a second or two. The odd thing is once a tcp connection is established, things seem more or less okay - for example, I can shell into a machine on my lan *over the wireless*, and ping normally, but while simultaneously pinging from my laptop, the difference in speed is stark.

ganiodayo is my laptop, deskaheh is my desktop machine (both running gutsy amd64). note that, although the lateny reported from each packet isn't significantly different, the total elapsed time on the laptop is 4 times slower. I've tried with similar results on 2 other networks - same results.

ski@ganiodayo:/var/cache/apt/archives$ date ; ping -c 10 google.com ; date
Tue Nov 13 18:30:23 EST 2007
PING google.com (64.233.187.99) 56(84) bytes of data.
64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=1 ttl=240 time=64.7 ms
64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=2 ttl=240 time=93.2 ms
64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=3 ttl=240 time=148 ms
64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=4 ttl=240 time=59.7 ms
64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=5 ttl=240 time=60.2 ms
64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=6 ttl=240 time=59.4 ms
64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=7 ttl=240 time=80.7 ms
64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=9 ttl=240 time=117 ms
64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=10 ttl=240 time=89.6 ms

--- google.com ping statistics ---
10 packets transmitted, 9 received, 10% packet loss, time 41975ms
rtt min/avg/max/mdev = 59.493/85.931/148.386/28.802 ms
Tue Nov 13 18:31:15 EST 2007

ski@deskaheh:~$ date ; ping -c 10 google.com ; date
Tue Nov 13 18:30:24 EST 2007
PING google.com (72.14.207.99) 56(84) bytes of data.
64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=1 ttl=242 time=221 ms
64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=2 ttl=242 time=299 ms
64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=3 ttl=242 time=46.9 ms
64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=4 ttl=242 time=56.0 ms
64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=5 ttl=242 time=52.4 ms
64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=6 ttl=242 time=384 ms
64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=7 ttl=242 time=86.9 ms
64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=8 ttl=242 time=47.5 ms
64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=9 ttl=242 time=47.7 ms
64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=10 ttl=242 time=52.4 ms

--- google.com ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9003ms
rtt min/avg/max/mdev = 46.998/129.559/384.575/118.986 ms
Tue Nov 13 18:30:33 EST 2007

Seems likely to be related to this bug on x86:

https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.22/+bug/134193

I'm happy to produce lspci, dmesg, or anything else that helps, but from my quick glance they don't seem relevant.

[ski (skibrianski)]

Forgot to mention - despite being connected (although poorly), nm-applet is still showing the spinning icon with 2 green lights, instead of the connection meter. I've restarted the appropriate services and even rebooted a few times, and the problem persists.

[ski (skibrianski)]

It appears I was too hasty to point the finger at this package, as I've downgraded to .9 (via the alternate CD) and I'm still having the problem. What else has changed recently and could be wrong? Help?

[ski (skibrianski)]

It's not a hardware issue, as $non_free_operating_system has no problems whatsoever when I boot into it.

[Nicolas Deschildre (ndeschildre)]

Thanks for your bugreport.

This bug has been here for quite a while, see the bug 103210 (https://bugs.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.22/+bug/103210 ), and a bug has been filed upstream. You may try some of the proposed workarounds.

Nicolas

[ski (skibrianski)]

On further reading I'm not convinced this bug actually is a duplicate. Certainly the latency issue is not the one that is being dealt with upstream.

...

More information on the latency bug - it seems clear after more use that the issue is one of latency on each initial connection.

Each connection is fine once it is established but there is some 2-20 second delay in initiated the connection (or even getting a ping back).

For example, on a system connected physically to the ethernet:
ski@deskaheh:~$ time sudo ping -f -c 10 google.com
PING google.com (64.233.187.99) 56(84) bytes of data.

--- google.com ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 119ms
rtt min/avg/max/mdev = 57.694/67.463/95.618/11.344 ms, pipe 6, ipg/ewma 13.309/67.140 ms

real 0m0.200s
user 0m0.000s
sys 0m0.004s

But on a system connected via ipw3945 (and affected by the bug):

ski@ganiodayo:~$ time sudo ping -f -c 10 google.com
PING google.com (72.14.207.99) 56(84) bytes of data.

--- google.com ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 30423ms
rtt min/avg/max/mdev = 52.250/68.772/92.240/11.990 ms, pipe 6, ipg/ewma 3380.390/72.389 ms

real 0m55.716s
user 0m0.004s
sys 0m0.008s

What's more, ping cannot be interrupted via control-C on the affected system.

However, thruput is fine (circa 2.2MBps).

[ski (skibrianski)]

Nevermnd this. The problem I'm having is with networkmanager, and I will re-file appropriately.