Bug 14693 - rt61pci module behaves erratically
Summary: rt61pci module behaves erratically
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Drivers
Classification: Unclassified
Component: network-wireless (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_network-wireless@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-11-26 02:50 UTC by Dan Dart
Modified: 2011-01-21 18:08 UTC (History)
4 users (show)

See Also:
Kernel Version: 2.6.28+
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description Dan Dart 2009-11-26 02:50:40 UTC
My main computer has a D-Link G510 PCI wireless adapter in it - which is rt61pci.

The problem with it is that it will occasionally slow right down, often taking network operations to a standstill.

Apt-get would quite often say a number of tens of kB per second, then hundreds of bytes and then nothing, for a considerable amount of time.

Browsing the Internet often becomes a pain (where pages would not load at all for a few minutes), but I know this is not a connectivity problem, as all the other computers would get proper speed. Even when they're not using it, I am able to receive pages on my laptop at full speed (ipw3945) but not on my desktop, at unpredictable times.

I think this may be a module issue. I have been having this problem since Ubuntu Jaunty (and I think Intrepid), possibly earlier. Has the specific module codebase changed at all in this time?

I doubt it is a network stack problem or a wireless coverage problem, as it works on all other computers with an identical software configuration, and I get a consistent at least 70% signal strength.

Any suggestions?

Cheers
Dan
Comment 1 Dan Dart 2009-12-05 21:40:22 UTC
I think flood pinging the router has helped a little, it helps kickstart downloads again. and helps pages load faster when the connection grinds to a halt.

Any idea what this could be?

Speedguide results if that helps:

TCP options string: 020405b4 
MSS: 1460 
MTU: 1500 
TCP Window: 5840 (multiple of MSS) 
RWIN Scaling: 0 bits  (Under many Linux distributions, the Analyzer only shows the Current TCP Window.)
Unscaled RWIN : 5840 
Recommended RWINs: 64240, 128480, 256960, 513920, 1027840 
BDP limit (200ms): 234kbps (29KBytes/s)
BDP limit (500ms): 93kbps (12KBytes/s) 
MTU Discovery: ON 
TTL: 43 
Timestamps: OFF 
SACKs: OFF 
IP ToS: 00000000 (0)
Comment 2 Ivo van Doorn 2009-12-08 19:54:44 UTC
Could you try disabling powersaving:

iwconfig wlan0 power off
Comment 3 Dan Dart 2009-12-08 21:54:08 UTC
It's off now, but it has behaved all day. Especially, it seems, on the Ubuntu Live CD. Does that have powersaving turned off by default?
Comment 4 Dan Dart 2010-01-18 23:48:54 UTC
The powersaving trick doesn't work - it still behaves slow and erratically - today has been particularly bad for it. Doing ping -f [router] detects many many dropped packets while it is having problems, and next to none when it's not.

In fact I'm having to use my laptop to even get onto this site.

Any more hints?
Comment 5 John W. Linville 2010-03-03 17:01:59 UTC
Dan, does this problem persist w/ 2.6.33?  Ivo & Gertjan, any further advice?
Comment 6 Dan Dart 2010-03-03 18:40:36 UTC
I can't be sure as the computer is moving on now. Anyone else know?
Comment 7 fastaire3 2010-05-18 05:26:22 UTC
Yes this problem persists in 2.6.33.  Confirmed in PCLinuxOS and Archlinux.  It seems the problem is massive packet loss.  Testing at www.pingtest.net and ping on PCLinuxOS averages a packet loss of 30-40%.  Testing with Archlinux using ping shows around the same loss averages (30-40%).
Comment 8 John W. Linville 2010-08-13 15:50:39 UTC
Ivo & Gertjan, is there som info fastaire3 can collect to make this report useful?
Comment 9 Ivo van Doorn 2010-08-22 18:50:01 UTC
Sorry at the moment I don't have ideas on where the problem might come from.
I can look into this further when I completed the rt2800usb project though.
Comment 10 John W. Linville 2011-01-21 18:08:05 UTC
I'm not seeing any other reports like this...closing due to staleness...

Note You need to log in before you can comment on or make changes to this bug.