I have recently installed OpenSuse 11.1 and decided to bite the bullet and try to get the native RTL8187 driver to work rather than resorting to Ndiswrapper.
I can get a connection ok but the performance soon falls off to the point where I receive data at b/s rather than kb/s or mb/s. When I try to download a 12 Mb file, I get up to 9Mb fairly rapidly then the download freezes.
I get the following outputs:
lsusb
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root
Bus 001 Device 002: ID 0846:6a00 NetGear, Inc. WG111v2 54 Mbps Wireless [RealTek RTL8187L]
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
linux-68an:/home/alex # iwconfig
lo no wireless extensions.
eth0 no wireless extensions.
wmaster0 no wireless extensions.
wlan0 IEEE 802.11bg ESSID:“HomeNet”
Mode:Managed Frequency:2.462 GHz Access Point: 00:14:6C:68:EB:96
Bit Rate=54 Mb/s Tx-Power=27 dBm
Retry min limit:7 RTS thr:off Fragment thr=2352 B
Encryption key:F701-7433-F87B-F7CC-2CB9-A787-1E15-237A-54FA-7C01-A21A-777A-2A31-D8FF-D3C0-E948 [3] Security mode:open
Power Management:off
Link Quality=63/100 Signal level:32/65
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
linux-68an:/home/alex # iwlist scan
lo Interface doesn’t support scanning.
eth0 Interface doesn’t support scanning.
wmaster0 Interface doesn’t support scanning.
wlan0 Scan completed :
Cell 01 - Address: 00:14:6C:68:EB:96
ESSID:“HomeNet”
Mode:Master
Channel:11
Frequency:2.462 GHz (Channel 11)
Quality=58/100 Signal level:37/65
Encryption key:on
IE: WPA Version 1
Group Cipher : TKIP
Pairwise Ciphers (1) : TKIP
Versys wrote:
> Hi,
>
> I have recently installed OpenSuse 11.1 and decided to bite the bullet
> and try to get the native RTL8187 driver to work rather than resorting
> to Ndiswrapper.
>
> I can get a connection ok but the performance soon falls off to the
> point where I receive data at b/s rather than kb/s or mb/s. When I try
> to download a 12 Mb file, I get up to 9Mb fairly rapidly then the
> download freezes.
>
> I get the following outputs:
>
> lsusb
> Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root
> Bus 001 Device 002: ID 0846:6a00 NetGear, Inc. WG111v2 54 Mbps Wireless
> [RealTek RTL8187L]
> Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
>
> linux-68an:/home/alex # iwconfig
> lo no wireless extensions.
>
>
> eth0 no wireless extensions.
> wmaster0 no wireless extensions.
> wlan0 IEEE 802.11bg ESSID:“HomeNet”
> Mode:Managed Frequency:2.462 GHz Access Point:
> 00:14:6C:68:EB:96
> Bit Rate=54 Mb/s Tx-Power=27 dBm
>
> Retry min limit:7 RTS thr:off Fragment thr=2352 B
>
> Encryption
> key:F701-7433-F87B-F7CC-2CB9-A787-1E15-237A-54FA-7C01-A21A-777A-2A31-D8FF-D3C0-E948
> [3] Security mode:open
> Power Management:off
>
> Link Quality=63/100 Signal level:32/65
>
> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
>
> Tx excessive retries:0 Invalid misc:0 Missed beacon:0
>
> linux-68an:/home/alex # iwlist scan
> lo Interface doesn’t support scanning.
> eth0 Interface doesn’t support scanning.
> wmaster0 Interface doesn’t support scanning.
> wlan0 Scan completed :
> Cell 01 - Address: 00:14:6C:68:EB:96
> ESSID:“HomeNet”
> Mode:Master
> Channel:11
> Frequency:2.462 GHz (Channel 11)
> Quality=58/100 Signal level:37/65
> Encryption key:on
> IE: WPA Version 1
> Group Cipher : TKIP
> Pairwise Ciphers (1) : TKIP
>
> Authentication Suites (1) : PSK
> Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 22
> Mb/s
> 6 Mb/s; 9 Mb/s; 12 Mb/s; 18 Mb/s; 24
> Mb/s
> 36 Mb/s; 48 Mb/s; 54 Mb/s
> Extra:tsf=0000000294abc564
> Extra: Last beacon: 72ms ago
Good job. You just publicly posted your WPA key. No need to try to break it the
hard way.
This behavior is new to me. What does the output of 'dmesg | egrep “rtl|wlan”
show? Did you force the rate to be 54 Mbs, or was it set that way by the system?
Interesting that this says RTL8187vB and it was RTL8187L according to lsusb.
The 54 Mbs was the default.
BTW - the WPA key has been randomly edited just on the off chance that anyone can work out where my router is and just happens to be close enough to use it.
When you bring it up next time, issue the command ‘sudo /sbin/iwconfig wlan0
rate 24M’ and see if that helps your throughput. I’m guessing that 54 Mb is too
fast and that you are getting many retransmits. If that is the case, I don’t
know why the rate-control mechanism isn’t slowing it down.
Versys wrote:
> I changed the rate to 24 and it made no difference.
>
> linux-68an:~ # dmesg | grep rate
>
> gives
>
> phy0: Selected rate control algorithm ‘pid’
The ‘pid’ algorithm works pretty well. A better one called ‘minstrel’ is in the
pipeline, but ‘pid’ should be OK.
> 14:00:03 linux-68an NetworkManager: <debug> [1230127203.957844]
> periodic_update(): Roamed from BSSID 00:14:6C:68:EB:96 (HomeNet) to
> (none) ((none))
> 14:00:09 linux-68an NetworkManager: <debug> [1230127209.961959]
> periodic_update(): Roamed from BSSID (none) ((none)) to
> 00:14:6C:68:EB:96 (HomeNet)
The roaming from Homenet to none and back is “normal”. At least that happens
here too.
If you run a ping test to your AP, do you see an increase in the times? Use the
command
ping -c 10 -s 1300 <your_AP’s_IP>
Note the statistics, which will look like
— 192.168.1.1 ping statistics —
10 packets transmitted, 10 received, 0% packet loss, time 9013ms
rtt min/avg/max/mdev = 2.740/3.371/4.056/0.411 ms
Then run the command
ping -c 1200 -s 1300 <your_AP’s_IP>
That will be a 20 minute test. What we want to see is if there are a lot of
packets lost, or if the time is a lot longer at the end than we saw at the
beginning.
I plotted the results of the second test on graph and it shows spikes up to 3000ms roughly every 100 pings. Also, there is a general increase in average time after 500 pings and particularly between 600 & 800 and 850 to the end.
Versys wrote:
> Hi Larry,
>
> the results of these tests were:
>
> — 192.168.0.1 ping statistics —
> 10 packets transmitted, 10 received, 0% packet loss, time 9041ms
> rtt min/avg/max/mdev = 6.205/6.686/7.380/0.377 ms
>
> — 192.168.0.1 ping statistics —
> 1200 packets transmitted, 1089 received, 9% packet loss, time
> 1203267ms
> rtt min/avg/max/mdev = 5.700/59.753/3082.309/310.690 ms, pipe 4
>
> I plotted the results of the second test on graph and it shows spikes
> up to 3000ms roughly every 100 pings. Also, there is a general increase
> in average time after 500 pings and particularly between 600 & 800 and
> 850 to the end.
That loss of 9% looks bad. Is your device external? How hot does it get? If
possible, retry the second ping with a fan on the device, or some other means of
cooling.
Versys wrote:
> Hi Larry,
>
> Hope you had a nice Xmas.
>
> In answer to your question, the device in question is an external USB
> dongle,
>
> Some further information:
>
> When I use this on another machine I get the following:
>
> [root@localhost alex]# iwlist rate
> lo no bit-rate information.
>
> wlan0 1 available bit-rates :
> 500 kb/s
> Current Bit Rate=54 Mb/s
That essentially matches what I see.
> When I tried
>
> iwconfig wlan0 rate 24M
Was this done as root?
> per your previous suggesting and then iwconfig, the bitrate still
> showed as 54 Mb/s.
>
> Re the dropped packets, is it possible to change a configuration
> somewhere to reduce/avoid this behaviour?
I think that is due to trying to use 54M on a link that cannot quite support
that rate. I don’t understand why iwconfig doesn’t change the rate. That code
was fixed in mac80211 a long time ago.
yes, I have done all of this as root. The only time I can see the bitrate changing is when I use a machine much further away from the AP - even then it sometimes goes to 54 Mbs, as if it is being changed dynamically according to various factors.
Versys wrote:
> Hi Larry,
>
> yes, I have done all of this as root. The only time I can see the
> bitrate changing is when I use a machine much further away from the AP -
> even then it sometimes goes to 54 Mbs, as if it is being changed
> dynamically according to various factors.
That is normal and it seems that rate adjustment is working; however, I would
expect the rate to be downgraded with a 9% packet loss with ping. That loss is
certainly your problem.
The only other thing to try is to force rates of 11, 5.5, 2, or 1 Mbs. These
rates use a different encoding scheme than the other possible rates. See what
losses you get for the 20 minute ping at each of those rates.
Larry Finger wrote:
>
> To check that, open a terminal window and enter the following command while
> downloading, or even pinging:
>
> while 1 ] ; do iwconfig wlan0 | grep Mb ; sleep 1; done
>
> If your device is not known as wlan0, change that part. This will print the rate
> every second.
>
> I’ll boot the standard kernel and see what happens with my RTL8187B.
I have tried the 11.1 kernel (2.6.27.7-9-default) and found the same results.
When I issue a command
sudo iwconfig wlan0 rate 11M
The interface goes to 11M and stays there just as I expected. The rate-changing
behavior is part of mac80211 and it shouldn’t matter that I’m using an RTL8187B,
not an RTL8187.
Hi I use the same card, and received a tip in another forum to delete networkmanager and install WicD for Wifi. I haven’t tried this yet, but according to other users this works.
bjarte k wrote:
> Hi I use the same card, and received a tip in another forum to delete
> networkmanager and install WicD for Wifi. I haven’t tried this yet, but
> according to other users this works.
Using something other than NetworkManager would make sense if you were having
problems making a connection; however that is not the problem here. The OP has
no problem making the connection, but the rate-control mechanism is setting the
rate too high and he gets an unacceptable retry rate. That is a kernel problem,
not something in userland, like NM.