Hi,
I recently had to switch my desktop over to use wireless to connect
to my DSL line. Unfortunately it was not a entirely happy experience.
I have the following setup:
- One zd1211rw usb stick taped to a desk.
- A wireless antenna next to it, connected to PCI wireless cards
I'm using the zd1211rw stick, which works (54Mbit/s connection
with no apparent packet loss through two walls from a 16Mbit/s DSL line).
Unfortunately it has horrible queueing behaviour under load: when I have
multiple download streams going the connection gets extremly laggy.
The problem seems to be in the client here, when I do the same from a laptop
with Intel wireless there is no significant lag.
To avoid this problem I was trying to switch over to PCI cards.
I tried two different ones:
05:02.0 Network controller: RaLink RT2561/RT61 802.11g PCI
and
06:02.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8185 IEEE 802.11a/b/g Wireless LAN Controller (rev 20)
in different machines. The reception should be about the same
or better than with the USB stick: they are connected to a real
antenna which is sitting next to the USB stick on a desk.
Unfortunately they both show the same problem. The connection
works, but quickly goes down to 1Mbit/s after setup and is then very slow.
I tried to manually lock it to 54Mbit/s, but then no data
is transferred. When it's set back to auto it quickly goes
down to 1Mbit/s again.
The USB stick happily stays at 54Mbit/s on its own (and works
well except for the lag behaviour). Both to the same AP.
Since I see this with two different chipsets I suppose it's
some general problem in the midlevel layer. There are no special
messages in dmesg. My laptops which have Intel wireless (ipw2200)
don't show this problem. So it must be in some part that
is used by the RTL and RT drivers, but not by Intel or zd1211rw.
Kernels I tried: 2.6.27, 2.6.28, current 2.6.29-git (now with Larry's
patch). All same behaviour.
Any ideas?
-Andi
--
[email protected]
This sounds a bit like what is mentioned in this bug report - (no solution yet,
but the symptom seem similiar).
http://bugzilla.kernel.org/show_bug.cgi?id=12131
On Mon, Jan 5, 2009 at 5:01 PM, Felix Fietkau <[email protected]> wrote:
> Andi Kleen wrote:
>>> According to the rate control's view, only the 1M has a usable
>>> success probability. It's rather insteresting that 11M is the only
>>> other rate that had some successes. With this kind of results, the
>>> only two options that I can think of are either a systematic tx
>>> status reporting error (false negative for the IEEE80211_TX_STAT_ACK
>>> flag), or something PHY related.
>>
>> Ok. Any more data I should provide to help tracking this down?
>> Do you want the same from the RaLink?
> Yes, It'd be interesting to see if the table looks similar or if
> more rates work.
>
> - Felix
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On Sun, Jan 04, 2009 at 10:59:18PM -0600, Larry Finger wrote:
> Andi Kleen wrote:
> > On Sun, Jan 04, 2009 at 09:55:03PM -0600, Larry Finger wrote:
> >
> > Minstrel stays constantly at 1 Mbit/s
>
> Do you have mac80211 debugging turned on? If so, then do a
>
> sudo cat /sys/kernel/debug/ieee80211/phyXX/stations/<MAC ADDR>/rc_stats
>
> and post them.
Lots of zeroes.
-Andi
rate throughput ewma prob this prob this succ/attempt success attempts
TtP 1 0.0 0.0 0.0 1( 0) 0 0
2 0.0 0.0 0.0 0( 0) 0 0
5.5 0.0 0.0 0.0 0( 0) 0 0
11 0.0 0.0 0.0 0( 0) 0 0
6 0.0 0.0 0.0 0( 0) 0 0
9 0.0 0.0 0.0 0( 0) 0 0
12 0.0 0.0 0.0 0( 0) 0 0
18 0.0 0.0 0.0 0( 0) 0 0
24 0.0 0.0 0.0 0( 0) 0 0
36 0.0 0.0 0.0 0( 0) 0 0
48 0.0 0.0 0.0 0( 0) 0 0
54 0.0 0.0 0.0 0( 0) 0 2
Total packet count:: ideal 46 lookaround 2
--
[email protected]
Andi,
Andi Kleen wrote:
>
> Anyways with PID i get between 1Mbit/s and 5.5Mbit/s, most of the
> time 1Mbit/s. So it's not really much better.
Does this patch help? Recently mac80211 changed from expecting tries
to retries, and I don't think rtl8180 got changed.
Larry
===============
Index: wireless-testing/drivers/net/wireless/rtl818x/rtl8180_dev.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/rtl818x/rtl8180_dev.c
+++ wireless-testing/drivers/net/wireless/rtl818x/rtl8180_dev.c
@@ -188,7 +188,7 @@ static void rtl8180_handle_tx(struct iee
(flags & RTL818X_TX_DESC_FLAG_TX_OK))
info->flags |= IEEE80211_TX_STAT_ACK;
- info->status.rates[0].count = (flags & 0xFF) + 1;
+ info->status.rates[0].count = (flags & 0xFF);
ieee80211_tx_status_irqsafe(dev, skb);
if (ring->entries - skb_queue_len(&ring->queue) == 2)
-------
On Sunday 04 January 2009 17:46:49 Andi Kleen wrote:
[snip]
I guess you're using the minstrel rate control.
Can you switch to PID rate control and retry.
Note that intel uses its own rate control algorithm. so I guess that's
where it breaks.
--
Greetings, Michael.
Hin-Tak Leung wrote:
> This sounds a bit like what is mentioned in this bug report - (no solution yet,
> but the symptom seem similiar).
> http://bugzilla.kernel.org/show_bug.cgi?id=12131
>
I think that one is different. If I read the bug report correctly, that one
cannot even keep a full rate of 1 Mb/s.
Larry
On Sun, Jan 04, 2009 at 05:36:47PM +0100, Michael Buesch wrote:
> On Sunday 04 January 2009 17:46:49 Andi Kleen wrote:
> [snip]
>
> I guess you're using the minstrel rate control.
> Can you switch to PID rate control and retry.
I thought i had tried both, but on rechecking it looks like
Kconfig makes it actively hard to do that (grumbl) and probably minstrel
was on all the time.
Anyways with PID i get between 1Mbit/s and 5.5Mbit/s, most of the
time 1Mbit/s. So it's not really much better.
-Andi
--
[email protected]
Andi Kleen wrote:
>
> Same issue with this patch. It fluctuates some time between 11Mbit/s
> and 48Mbit/s, but then eventually settles on 1Mbit/s again. That's with PID
> now, not Mistrel. I think it takes longer with this patch than
> before, but not much.
>
> BTW I see the problem with RT2561 too.
Can you retry with mistrel? In my experience, it converges to a lower rate than
does pid, but it doesn't fluctuate as much.
I'll look into RT2561.
What I generally do is start a ping in one window and enter the following line
in another:
while [ 1 ] ; do iwconfig wlan0 | grep Mb ; sleep 1 ; done
and watch the rate.
Larry
Andi Kleen wrote:
>
> BTW I see the problem with RT2561 too.
>
This one should fix all of the rt2x00 drivers.
Larry
Index: wireless-testing/drivers/net/wireless/rt2x00/rt2x00dev.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/rt2x00/rt2x00dev.c
+++ wireless-testing/drivers/net/wireless/rt2x00/rt2x00dev.c
@@ -266,7 +266,7 @@ void rt2x00lib_txdone(struct queue_entry
tx_info->status.ack_signal = 0;
tx_info->status.rates[0].idx = rate_idx;
tx_info->status.rates[0].flags = rate_flags;
- tx_info->status.rates[0].count = txdesc->retry + 1;
+ tx_info->status.rates[0].count = txdesc->retry;
tx_info->status.rates[1].idx = -1; /* terminate */
if (!(tx_info->flags & IEEE80211_TX_CTL_NO_ACK)) {
---
On Mon, Jan 05, 2009 at 04:25:58PM +0100, Felix Fietkau wrote:
> > Forcing the rates works somewhat, but the link quality is very poor
> > (10-15/100) and fluctuates.
> Another possibility is that the tx power is fine, but the
> sensitivity of the card is crap, so the packets actually make it,
Ok, but I see the same thing with two different cards, with different
chipsets (RaLink and RealTek). You think they both have that problem?
> Even if both cards work fine on Windows, I wouldn't assume that this
> is an issue with mac80211. The information that was used to write
> these two drivers was derived from very poor vendor codebases and
> limited information in datasheets, so it's much more likely that
> simply the Baseband/RF tuning is far from optimal on both cards.
Ok I won't try then. Setting up Windows would be quite a lot of
effort and I would prefer to avoid it.
> Maybe we can see more if you provide some minstrel stats after
> you've pushed more traffic through the link - 25-50 packets is not
> nearly enough for getting an accurate view of how good the link is.
> Try to push through a few megabytes of data...
Here are the statistics after a few MB.
rate throughput ewma prob this prob this succ/attempt success attempts
TtP 1 0.9 97.9 100.0 1( 1) 19284 21249
2 0.0 0.0 0.0 0( 0) 0 101
5.5 0.0 0.0 0.0 0( 0) 0 104
11 0.0 0.0 0.0 0( 0) 253 397
6 0.0 0.0 0.0 0( 0) 0 103
9 0.0 0.0 0.0 0( 0) 0 106
12 0.0 0.0 0.0 0( 0) 0 107
18 0.0 0.0 0.0 0( 0) 0 104
24 0.0 0.0 0.0 0( 0) 0 111
36 0.0 0.0 0.0 0( 0) 0 120
48 0.0 0.0 0.0 0( 0) 0 179
54 0.0 0.0 0.0 0( 0) 0 253
Total packet count:: ideal 9023 lookaround 474
-Andi
--
[email protected]
Andi Kleen wrote:
> On Sun, Jan 04, 2009 at 09:55:03PM -0600, Larry Finger wrote:
>
> Minstrel stays constantly at 1 Mbit/s
Do you have mac80211 debugging turned on? If so, then do a
sudo cat /sys/kernel/debug/ieee80211/phyXX/stations/<MAC ADDR>/rc_stats
and post them.
Thanks,
Larry
On Sun, Jan 04, 2009 at 09:55:03PM -0600, Larry Finger wrote:
> Andi Kleen wrote:
> >
> > Same issue with this patch. It fluctuates some time between 11Mbit/s
> > and 48Mbit/s, but then eventually settles on 1Mbit/s again. That's with PID
> > now, not Mistrel. I think it takes longer with this patch than
> > before, but not much.
> >
> > BTW I see the problem with RT2561 too.
>
> Can you retry with mistrel? In my experience, it converges to a lower rate than
> does pid, but it doesn't fluctuate as much.
Minstrel stays constantly at 1 Mbit/s
-Andi
--
[email protected]
Andi Kleen wrote:
> With Larry's patch reverted. Rate is still at 1Mbit/s of course.
> This is all only with rtl8180, I didn't try everything on the realtek
> card too.
>
> -Andi
>
> rate throughput ewma prob this prob this succ/attempt success attempts
> TtP 1 0.9 99.2 100.0 1( 1) 23 32
> 2 0.0 0.0 0.0 0( 0) 0 0
> 5.5 0.0 0.0 0.0 0( 0) 0 1
> 11 0.0 0.0 0.0 0( 0) 0 0
> 6 0.0 0.0 0.0 0( 0) 0 0
> 9 0.0 0.0 0.0 0( 0) 0 0
> 12 0.0 0.0 0.0 0( 0) 0 0
> 18 0.0 0.0 0.0 0( 0) 0 0
> 24 0.0 0.0 0.0 0( 0) 0 0
> 36 0.0 0.0 0.0 0( 0) 0 0
> 48 0.0 0.0 0.0 0( 0) 0 0
> 54 0.0 0.0 0.0 0( 0) 0 0
>
> Total packet count:: ideal 25 lookaround 1
OK, that confirms that Larry's patch was wrong - at least the dump
looks consistent now.
Probably the RT2561 and the RTL8180 simply have a lower Tx power and
thus can't get the signal through the walls as easily as the zd1211rw.
If you still think that it's a rate control problem, please try all
the rates individually and see if one of them works better.
- Felix
On Mon, Jan 05, 2009 at 02:32:21PM +0100, Felix Fietkau wrote:
> It looks like mac80211 is not getting proper feedback from the tx
> status of the device. Is this with the patch that Larry suggested?
> If so, please revert that patch and post an updated version of the
> same stats.
With Larry's patch reverted. Rate is still at 1Mbit/s of course.
This is all only with rtl8180, I didn't try everything on the realtek
card too.
-Andi
rate throughput ewma prob this prob this succ/attempt success attempts
TtP 1 0.9 99.2 100.0 1( 1) 23 32
2 0.0 0.0 0.0 0( 0) 0 0
5.5 0.0 0.0 0.0 0( 0) 0 1
11 0.0 0.0 0.0 0( 0) 0 0
6 0.0 0.0 0.0 0( 0) 0 0
9 0.0 0.0 0.0 0( 0) 0 0
12 0.0 0.0 0.0 0( 0) 0 0
18 0.0 0.0 0.0 0( 0) 0 0
24 0.0 0.0 0.0 0( 0) 0 0
36 0.0 0.0 0.0 0( 0) 0 0
48 0.0 0.0 0.0 0( 0) 0 0
54 0.0 0.0 0.0 0( 0) 0 0
Total packet count:: ideal 25 lookaround 1
--
[email protected]
On Sun, Jan 04, 2009 at 06:29:25PM -0600, Larry Finger wrote:
> Andi,
>
> Andi Kleen wrote:
> >
> > Anyways with PID i get between 1Mbit/s and 5.5Mbit/s, most of the
> > time 1Mbit/s. So it's not really much better.
>
>
> Does this patch help? Recently mac80211 changed from expecting tries
> to retries, and I don't think rtl8180 got changed.
Same issue with this patch. It fluctuates some time between 11Mbit/s
and 48Mbit/s, but then eventually settles on 1Mbit/s again. That's with PID
now, not Mistrel. I think it takes longer with this patch than
before, but not much.
BTW I see the problem with RT2561 too.
-Andi
Andi Kleen wrote:
>> According to the rate control's view, only the 1M has a usable
>> success probability. It's rather insteresting that 11M is the only
>> other rate that had some successes. With this kind of results, the
>> only two options that I can think of are either a systematic tx
>> status reporting error (false negative for the IEEE80211_TX_STAT_ACK
>> flag), or something PHY related.
>
> Ok. Any more data I should provide to help tracking this down?
> Do you want the same from the RaLink?
Yes, It'd be interesting to see if the table looks similar or if
more rates work.
- Felix
> According to the rate control's view, only the 1M has a usable
> success probability. It's rather insteresting that 11M is the only
> other rate that had some successes. With this kind of results, the
> only two options that I can think of are either a systematic tx
> status reporting error (false negative for the IEEE80211_TX_STAT_ACK
> flag), or something PHY related.
Ok. Any more data I should provide to help tracking this down?
Do you want the same from the RaLink?
-Andi
--
[email protected]
Andi Kleen wrote:
> On Sun, Jan 04, 2009 at 10:59:18PM -0600, Larry Finger wrote:
>> Andi Kleen wrote:
>>> On Sun, Jan 04, 2009 at 09:55:03PM -0600, Larry Finger wrote:
>>>
>>> Minstrel stays constantly at 1 Mbit/s
>> Do you have mac80211 debugging turned on? If so, then do a
>>
>> sudo cat /sys/kernel/debug/ieee80211/phyXX/stations/<MAC ADDR>/rc_stats
>>
>> and post them.
>
> Lots of zeroes.
Strange. Mine looks like this.
rate throughput ewma prob this prob this succ/attempt success attempts
1 0.9 97.7 100.0 1( 1) 2086 2206
2 0.1 7.0 0.0 0( 0) 1 5
5.5 0.0 0.0 0.0 0( 0) 0 1
11 0.0 0.0 0.0 0( 0) 0 4
6 1.4 25.0 100.0 0( 0) 1 2
9 0.0 0.0 0.0 0( 0) 0 6
12 7.6 68.8 0.0 0( 0) 187 192
18 7.0 43.3 0.0 0( 0) 3 5
24 10.6 49.8 100.0 0( 0) 20 40
36 8.5 28.0 50.0 0( 0) 1389 1520
T P 48 15.7 99.9 100.0 1( 1) 3277 3525
t 54 21.7 50.1 0.0 0( 0) 19282 20028
Total packet count:: ideal 3800 lookaround 422
Johannes,
Any explanation as to why there are no attempts?
Larry
On Sun, 2009-01-04 at 23:51 -0600, Larry Finger wrote:
> rate throughput ewma prob this prob this succ/attempt success attempts
> 1 0.9 97.7 100.0 1( 1) 2086 2206
> 2 0.1 7.0 0.0 0( 0) 1 5
> 5.5 0.0 0.0 0.0 0( 0) 0 1
> 11 0.0 0.0 0.0 0( 0) 0 4
> 6 1.4 25.0 100.0 0( 0) 1 2
> 9 0.0 0.0 0.0 0( 0) 0 6
> 12 7.6 68.8 0.0 0( 0) 187 192
> 18 7.0 43.3 0.0 0( 0) 3 5
> 24 10.6 49.8 100.0 0( 0) 20 40
> 36 8.5 28.0 50.0 0( 0) 1389 1520
> T P 48 15.7 99.9 100.0 1( 1) 3277 3525
> t 54 21.7 50.1 0.0 0( 0) 19282 20028
>
> Total packet count:: ideal 3800 lookaround 422
>
> Johannes,
>
> Any explanation as to why there are no attempts?
It only sent two probe packets? Remember that zd1211 is rather rate
control challenged. I don't know. nbd might be able to tell you more.
johannes
Andi Kleen wrote:
> Ok, but I see the same thing with two different cards, with different
> chipsets (RaLink and RealTek). You think they both have that problem?
Yes, I think that's not unlikely.
>> Maybe we can see more if you provide some minstrel stats after
>> you've pushed more traffic through the link - 25-50 packets is not
>> nearly enough for getting an accurate view of how good the link is.
>> Try to push through a few megabytes of data...
>
> Here are the statistics after a few MB.
>
> rate throughput ewma prob this prob this succ/attempt success attempts
> TtP 1 0.9 97.9 100.0 1( 1) 19284 21249
> 2 0.0 0.0 0.0 0( 0) 0 101
> 5.5 0.0 0.0 0.0 0( 0) 0 104
> 11 0.0 0.0 0.0 0( 0) 253 397
> 6 0.0 0.0 0.0 0( 0) 0 103
> 9 0.0 0.0 0.0 0( 0) 0 106
> 12 0.0 0.0 0.0 0( 0) 0 107
> 18 0.0 0.0 0.0 0( 0) 0 104
> 24 0.0 0.0 0.0 0( 0) 0 111
> 36 0.0 0.0 0.0 0( 0) 0 120
> 48 0.0 0.0 0.0 0( 0) 0 179
> 54 0.0 0.0 0.0 0( 0) 0 253
>
> Total packet count:: ideal 9023 lookaround 474
According to the rate control's view, only the 1M has a usable
success probability. It's rather insteresting that 11M is the only
other rate that had some successes. With this kind of results, the
only two options that I can think of are either a systematic tx
status reporting error (false negative for the IEEE80211_TX_STAT_ACK
flag), or something PHY related.
I think the latter is more likely.
- Felix
On Mon, Jan 05, 2009 at 03:41:58PM +0100, Felix Fietkau wrote:
> Andi Kleen wrote:
> > With Larry's patch reverted. Rate is still at 1Mbit/s of course.
> > This is all only with rtl8180, I didn't try everything on the realtek
> > card too.
> >
> > -Andi
> >
> > rate throughput ewma prob this prob this succ/attempt success attempts
> > TtP 1 0.9 99.2 100.0 1( 1) 23 32
> > 2 0.0 0.0 0.0 0( 0) 0 0
> > 5.5 0.0 0.0 0.0 0( 0) 0 1
> > 11 0.0 0.0 0.0 0( 0) 0 0
> > 6 0.0 0.0 0.0 0( 0) 0 0
> > 9 0.0 0.0 0.0 0( 0) 0 0
> > 12 0.0 0.0 0.0 0( 0) 0 0
> > 18 0.0 0.0 0.0 0( 0) 0 0
> > 24 0.0 0.0 0.0 0( 0) 0 0
> > 36 0.0 0.0 0.0 0( 0) 0 0
> > 48 0.0 0.0 0.0 0( 0) 0 0
> > 54 0.0 0.0 0.0 0( 0) 0 0
> >
> > Total packet count:: ideal 25 lookaround 1
> OK, that confirms that Larry's patch was wrong - at least the dump
> looks consistent now.
> Probably the RT2561 and the RTL8180 simply have a lower Tx power and
> thus can't get the signal through the walls as easily as the zd1211rw.
That surprises me because I use a real antenna on them which the zd1211rw
is just itself. Also some laptops with Intel wireless have no trouble
talking through the walls at full rate when I put them on the same position.
Hmm perhaps I should try to find a Windows box and see if it works
there. That would rule out hardware issues.
> If you still think that it's a rate control problem, please try all
I don't know what it is, i just know that it doesn't work and
from the evidence I gathered so far it looks like a Linux software
problem.
> the rates individually and see if one of them works better.
Forcing the rates works somewhat, but the link quality is very poor
(10-15/100) and fluctuates.
-Andi
--
[email protected]
Andi Kleen wrote:
> Lots of zeroes.
>
> -Andi
>
> rate throughput ewma prob this prob this succ/attempt success attempts
> TtP 1 0.0 0.0 0.0 1( 0) 0 0
> 2 0.0 0.0 0.0 0( 0) 0 0
> 5.5 0.0 0.0 0.0 0( 0) 0 0
> 11 0.0 0.0 0.0 0( 0) 0 0
> 6 0.0 0.0 0.0 0( 0) 0 0
> 9 0.0 0.0 0.0 0( 0) 0 0
> 12 0.0 0.0 0.0 0( 0) 0 0
> 18 0.0 0.0 0.0 0( 0) 0 0
> 24 0.0 0.0 0.0 0( 0) 0 0
> 36 0.0 0.0 0.0 0( 0) 0 0
> 48 0.0 0.0 0.0 0( 0) 0 0
> 54 0.0 0.0 0.0 0( 0) 0 2
>
> Total packet count:: ideal 46 lookaround 2
It looks like mac80211 is not getting proper feedback from the tx
status of the device. Is this with the patch that Larry suggested?
If so, please revert that patch and post an updated version of the
same stats.
The info->status.rates[0].count is supposed to contain the number of
tx attempts, not the number of retransmissions (at least that's what
minstrel expects).
- Felix
> > Any explanation as to why there are no attempts?
>
> It only sent two probe packets? Remember that zd1211 is rather rate
This was with rtl8180, not zd1211.
> control challenged. I don't know. nbd might be able to tell you more.
What is nbd?
Anyways I can add printks and try to figure out more.
-Andi
--
[email protected]
Andi Kleen wrote:
>> Probably the RT2561 and the RTL8180 simply have a lower Tx power and
>> thus can't get the signal through the walls as easily as the zd1211rw.
>
> That surprises me because I use a real antenna on them which the zd1211rw
> is just itself. Also some laptops with Intel wireless have no trouble
> talking through the walls at full rate when I put them on the same position.
>
> Hmm perhaps I should try to find a Windows box and see if it works
> there. That would rule out hardware issues.
>
>> If you still think that it's a rate control problem, please try all
>
> I don't know what it is, i just know that it doesn't work and
> from the evidence I gathered so far it looks like a Linux software
> problem.
>
>> the rates individually and see if one of them works better.
>
> Forcing the rates works somewhat, but the link quality is very poor
> (10-15/100) and fluctuates.
Another possibility is that the tx power is fine, but the
sensitivity of the card is crap, so the packets actually make it,
but the ACKs don't. This is something that's quite hard to detect in
a rate control module that relies on ACKs as the only available
source of feedback (not that using RSSI for that would be any
better, but still).
Even if both cards work fine on Windows, I wouldn't assume that this
is an issue with mac80211. The information that was used to write
these two drivers was derived from very poor vendor codebases and
limited information in datasheets, so it's much more likely that
simply the Baseband/RF tuning is far from optimal on both cards.
Maybe we can see more if you provide some minstrel stats after
you've pushed more traffic through the link - 25-50 packets is not
nearly enough for getting an accurate view of how good the link is.
Try to push through a few megabytes of data...
- Felix