This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 471770 - ath5k wireless driver speed fluctuations and slow
ath5k wireless driver speed fluctuations and slow
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: John W. Linville
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-15 21:41 EST by Andrig Miller
Modified: 2009-04-28 23:36 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-28 14:16:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Andrig Miller 2008-11-15 21:41:18 EST
Description of problem:

I have the AR2425 Atheros wireless chipset, and am connecting to a 802.11g network, and everything works pretty well, including my WPA encryption.

The problem I am seeing is the the speed of the connection fluctuations constantly (up and down), and mostly it ends up running at 1 Mb/s as reported by NetworkManager.  I have seen it run at 54 Mb/s, and lots of values between 54 and 1, such as 12, 18, 24, and 36.  Mostly, it sits at 1 Mb/s, and the speed slowdown is very noticable.

Version-Release number of selected component (if applicable):

kernel - 2.6.27.4-79

How reproducible:

All the time.

Steps to Reproduce:
1. Login.
2. NetworkManager auto connects to the wireless G network.
3.
  
Actual results:

Speeds as low as 1 Mb/s.

Expected results:

Consistent speed of 54 Mb/s.  Most of the time I am within one foot of the wireless access point, and my signal strength shows 98 to 100%.  Even when in other rooms, I see a signal strength of 85% or higher (typically), but the speed is very slow.

Additional info:
Comment 1 Bug Zapper 2008-11-26 00:27:40 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 2 Jussi Eloranta 2008-12-27 03:09:44 EST
In addition to speed fluctuations (which can be overcome by setting the rate explicitly by iwconfig wlan0 rate 11M, for example), I also see odd sudden changes in frequency and long delays in network traffic accordingly (as seen by pinging the base station):

1) When everything is OK, I see with iwconfig:

wlan0     IEEE 802.11abg  ESSID:"Epatto"  
          Mode:Managed  Frequency:2.462 GHz  Access Point: 00:1E:2A:59:7C:BC   
          Bit Rate=11 Mb/s   Tx-Power=23 dBm   
          Retry min limit:7   RTS thr:off   Fragment thr=2352 B   
          Power Management:off
          Link Quality=21/100  Signal level:-80 dBm  Noise level=-94 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

2) With the sudden stop in network access occurs:

wlan0     IEEE 802.11abg  ESSID:"Epatto"  
          Mode:Managed  Frequency:5.26 GHz  Access Point: 00:1E:2A:59:7C:BC   
          Bit Rate=18 Mb/s   Tx-Power=23 dBm   
          Retry min limit:7   RTS thr:off   Fragment thr=2352 B   
          Power Management:off
          Link Quality=21/100  Signal level:-80 dBm  Noise level=-94 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0


It switched back to 1) after few seconds and then network is OK again. This seems to happen in regular intervals.

I am using WPA on SMP system with kernel 2.6.28-3-159. I saw the same problem also with 2.6.27* but I think everything worked OK before that, 2.6.26*.
Comment 3 Jussi Eloranta 2008-12-30 15:49:07 EST
Things work slightly better with kernel-2.6.29-0.6.rc0.git2.fc11. The speed fluctuations are gone but I am stuck at 1Mb/s transfer rate. I can change it by hand to higher rates and it works fine. However, these occasional jumps to 5 GHz range still persist.
Comment 4 Jussi Eloranta 2009-01-04 03:29:06 EST
Just checked. Madwifi (svn version) works fine - no sudden stops in network transfers. I also tried the latest wireless-compat, the problem still persists with that.
Comment 5 John W. Linville 2009-04-28 13:30:03 EDT
This is an old one...can we reset and try a current (2.6.29-based) kernel?  Do you still experience problems with those?
Comment 6 Andrig Miller 2009-04-28 13:53:31 EDT
I just applied the new 2.6.29 kernel for F10, and so far, the speed seem to stay constant at 24 Mb/s.  This is better than before, where it fluctuated a lot and many times was down to 1 Mb/s.  The funny thing is, now it never seems to go above the 24 Mb/s.  At least not for the last several hours.  So, I would say, much better than before, but I would think that I could get better than 24 Mb/s.
Comment 7 John W. Linville 2009-04-28 14:16:27 EDT
Actually, 24Mb/s is pretty good for most networks.  I'm going to close this one since it is no longer egregiously bad.
Comment 8 Jussi Eloranta 2009-04-28 23:36:06 EDT
It still does NOT work. Here is ping output from my laptop to my wireless router:

64 bytes from 192.168.1.1: icmp_seq=99 ttl=64 time=0.967 ms
64 bytes from 192.168.1.1: icmp_seq=100 ttl=64 time=1.04 ms
64 bytes from 192.168.1.1: icmp_seq=101 ttl=64 time=0.905 ms
64 bytes from 192.168.1.1: icmp_seq=102 ttl=64 time=1.12 ms
64 bytes from 192.168.1.1: icmp_seq=103 ttl=64 time=1.06 ms
64 bytes from 192.168.1.1: icmp_seq=104 ttl=64 time=0.971 ms
64 bytes from 192.168.1.1: icmp_seq=105 ttl=64 time=0.956 ms
64 bytes from 192.168.1.1: icmp_seq=106 ttl=64 time=0.982 ms
64 bytes from 192.168.1.1: icmp_seq=107 ttl=64 time=0.905 ms
64 bytes from 192.168.1.1: icmp_seq=108 ttl=64 time=4006 ms
64 bytes from 192.168.1.1: icmp_seq=109 ttl=64 time=3007 ms
64 bytes from 192.168.1.1: icmp_seq=110 ttl=64 time=2007 ms
64 bytes from 192.168.1.1: icmp_seq=111 ttl=64 time=1009 ms
64 bytes from 192.168.1.1: icmp_seq=112 ttl=64 time=8.30 ms
64 bytes from 192.168.1.1: icmp_seq=113 ttl=64 time=0.994 ms
64 bytes from 192.168.1.1: icmp_seq=114 ttl=64 time=0.896 ms

These problems show up only on my laptop with ath5k.

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