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 ?
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
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.
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(¶ms, 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.
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.
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.