b43 : under high load, ack are lost

b43 : under high load, ack are lost

[Matthieu CASTET]

Hi,

I use a 4306 (core rev 5) with compat-wireless-2009-05-08 as wireless driver and
4.150.10.5 firmware.
My station is an airo card in wpa-psk mode (802.11b).

After resolving my beacon problem [1], when I download at max speed my station
disconnect from AP because "LostSync-MaxRetry".
After looking in my station statistic it seems the retry (RetryLong) are due to
noack received from the AP.

Who is responsible to generate ack ?
The firmware or the mac80211 stack ?

Any idea to investigate this ?

Thanks

Matthieu 



[1] http://article.gmane.org/gmane.linux.kernel.wireless.general/32845

Re: b43 : under high load, ack are lost

[matthieu castet]

Matthieu CASTET <castet.matthieu@...> writes:

> 
> Hi,
> 
> I use a 4306 (core rev 5) with compat-wireless-2009-05-08 as wireless driver
> and
> 4.150.10.5 firmware.
> My station is an airo card in wpa-psk mode (802.11b).
> 
> After resolving my beacon problem [1], when I download at max speed my 
> station
> disconnect from AP because "LostSync-MaxRetry".
> After looking in my station statistic it seems the retry (RetryLong) are due 
> to
> noack received from the AP.
I take a monitor trace of the trafic and I see weird stuff from the b43 AP, 
there is lot of case of :
- client send data to AP
- AP send data to client
- ack from client
- AP send data to client
- ack from client
- AP send data to client
- ack from client
- ack from AP (for 1 packet)


Sometimes it is :
- client send data to AP
- AP send data to client
- ack from client
- AP send data to client
- ack from client
- AP send data to client
- ack from client
- client resend data to AP
- ack from AP
- client send data to AP
- ack from AP
- ack from AP (for 1 packet)


It seems like ack are queued somewhere with low priority.

Re: b43 : under high load, ack are lost

[matthieu castet]

I see also some period were the AP seem to drop all packet.
I am wondering if it can be due to slow recalibration.
Do you now how much take calibration were mac is down ?

Re: b43 : under high load, ack are lost

[Michael Buesch]

On Wednesday 20 May 2009 23:09:47 matthieu castet wrote:
> I see also some period were the AP seem to drop all packet.
> I am wondering if it can be due to slow recalibration.
> Do you now how much take calibration were mac is down ?

Something like 30/40/50 milliseconds. I don't know. Somewhere in that range.

But I think it doesn't drop packets due to recal. I think it's simply
because the b43 PHY code is completely broken.

-- 
Greetings, Michael.

Re: b43 : under high load, ack are lost

[Michael Buesch]

On Wednesday 20 May 2009 23:34:40 Michael Buesch wrote:
> On Wednesday 20 May 2009 23:09:47 matthieu castet wrote:
> > I see also some period were the AP seem to drop all packet.
> > I am wondering if it can be due to slow recalibration.
> > Do you now how much take calibration were mac is down ?
> 
> Something like 30/40/50 milliseconds. I don't know. Somewhere in that range.
> 
> But I think it doesn't drop packets due to recal. I think it's simply
> because the b43 PHY code is completely broken.
> 

Btw, you can easily test this with 
echo -n 1 > /debug/b43/phy0/debug_pwork_stop
This completely stops periodic recalibration.

-- 
Greetings, Michael.

Re: b43 : under high load, ack are lost

[Michael Buesch]

On Wednesday 20 May 2009 23:09:47 matthieu castet wrote:
> I see also some period were the AP seem to drop all packet.
> I am wondering if it can be due to slow recalibration.
> Do you now how much take calibration were mac is down ?

I think you should try without QoS.
Try specifying the qos=0 module parameter to b43.
If that does not work, additionally apply the following patch.
I think there are some problems with QoS and I think somebody reported some bugs
some time ago. I think they are still not addressed.

If I try with this patch and QoS disabled, the monitor log looks a bit better.
But the connection still doesn't work correctly. However, I only have applied
that patch to the AP. I will also apply it to the station, soon...

In any case, I think this patch is a good thing, as it will completely disable
QoS, if the user requested so.


Index: compat-wireless-2009-05-21/drivers/net/wireless/b43/main.c
===================================================================
--- compat-wireless-2009-05-21.orig/drivers/net/wireless/b43/main.c	2009-05-21 17:16:49.000000000 +0200
+++ compat-wireless-2009-05-21/drivers/net/wireless/b43/main.c	2009-05-21 17:20:48.000000000 +0200
@@ -3064,6 +3064,9 @@
 	int bslots, tmp;
 	unsigned int i;
 
+	if (!b43_modparam_qos)
+		return;
+
 	bslots = b43_read16(dev, B43_MMIO_RNG) & p->cw_min;
 
 	memset(&params, 0, sizeof(params));
@@ -3109,6 +3112,9 @@
 	struct b43_qos_params *params;
 	unsigned int i;
 
+	if (!b43_modparam_qos)
+		return;
+
 	BUILD_BUG_ON(ARRAY_SIZE(b43_qos_shm_offsets) !=
 		     ARRAY_SIZE(wl->qos_params));
 
@@ -3126,6 +3132,9 @@
 	struct b43_qos_params *params;
 	unsigned int i;
 
+	if (!b43_modparam_qos)
+		return;
+
 	/* Initialize QoS parameters to sane defaults. */
 
 	BUILD_BUG_ON(ARRAY_SIZE(b43_qos_shm_offsets) !=
@@ -3168,6 +3177,15 @@
 /* Initialize the core's QOS capabilities */
 static void b43_qos_init(struct b43_wldev *dev)
 {
+	if (!b43_modparam_qos) {
+		/* Disable QOS support. */
+		b43_hf_write(dev, b43_hf_read(dev) & ~B43_HF_EDCF);
+		b43_write16(dev, B43_MMIO_IFSCTL,
+			    b43_read16(dev, B43_MMIO_IFSCTL)
+			    & ~B43_MMIO_IFSCTL_USE_EDCF);
+		return;
+	}
+
 	/* Upload the current QOS parameters. */
 	b43_qos_upload_all(dev);
 


-- 
Greetings, Michael.

Re: b43 : under high load, ack are lost

[matthieu castet]

Michael Buesch wrote:
> On Wednesday 20 May 2009 23:09:47 matthieu castet wrote:
>> I see also some period were the AP seem to drop all packet.
>> I am wondering if it can be due to slow recalibration.
>> Do you now how much take calibration were mac is down ?
> 
> I think you should try without QoS.
> Try specifying the qos=0 module parameter to b43.
> If that does not work, additionally apply the following patch.
> I think there are some problems with QoS and I think somebody reported some bugs
> some time ago. I think they are still not addressed.
Thank you for your help.

First I used a ipw2200 for monitoring traffic, but it seems it doesn't 
not capture all packets. That what explain the strange pattern I saw 
before (missing ack or 2 following ack).

The qos disable doesn't seem to help much. There still some period where 
the AP seem blind.

Disabling pwork doesn't help, but some stuff is still done with 
b43_phy_txpower_check on tx path.


I will try to investigate more. A quick workaround is to increase the 
number of retry on my station.


yes.

Matthieu

Re: b43 : under high load, ack are lost

[Michael Buesch]

On Sunday 24 May 2009 23:42:02 matthieu castet wrote:
> Michael Buesch wrote:
> > On Wednesday 20 May 2009 23:09:47 matthieu castet wrote:
> >> I see also some period were the AP seem to drop all packet.
> >> I am wondering if it can be due to slow recalibration.
> >> Do you now how much take calibration were mac is down ?
> > 
> > I think you should try without QoS.
> > Try specifying the qos=0 module parameter to b43.
> > If that does not work, additionally apply the following patch.
> > I think there are some problems with QoS and I think somebody reported some bugs
> > some time ago. I think they are still not addressed.
> Thank you for your help.
> 
> First I used a ipw2200 for monitoring traffic, but it seems it doesn't 
> not capture all packets. That what explain the strange pattern I saw 
> before (missing ack or 2 following ack).

An ipw2200 is absolutely not usable in monitor mode.
You should dispose of it properly ;)

> Disabling pwork doesn't help, but some stuff is still done with 
> b43_phy_txpower_check on tx path.

Ok, this was just to falsify your "broken by calibration" theory.

-- 
Greetings, Michael.