Re: [Madwifi-devel] [RFC PATCH 0.9.3] Improve OFDM sensitivity in non-STA operating modes.
Status: Beta
Brought to you by:
otaku
From: Aidan W. <aw...@wi...> - 2007-12-18 18:12:32
|
Hi All, I would like to give you a little feedback on both the patch described below and maybe the 0.9.3.3 release. I'm not sure which is to blame and I'm also afraid this is a little anecdotal as time was of the essence when I saw these results. I operate a small WISP in the UK. I have been happily using Linux 2.6.18-3 combined with the 0.9.2.1 madwifi driver. I did however notice the apparent deafness of the system, but did not ascribe this to madwifi. I assumed it was just coax loss and other factors such as background noise. However in the rural areas I serve this should not be a problem. (Typically -95dBm noise floor) You can imagine my excitement when I read and tested the ANI-patch for the 0.9.3.3 release. On my test hardware which mirrors that in the field (BTW this is 'fields' in the literal sense of the word, 10m up on telegraph poles) the code seemed good. I did get just one occurrence of the stuck beacon message but I ended up putting this down to changes I was making to the configuration. Needless to say I was eager to try this in the real network. So this morning at 2am I compiled the patched 0.9.3.3 code base against my running kernel and rebooted! Woops! not good. the router began connecting the 30 or so clients that are supported and then after about 25 connections became associated, all hell broke loose. The clients began to associate and disassociate at random, 7 or 8 at a time, sometimes nearly all 30 clients would be associated but then just a few seconds later 5 or 6 would drop off, only to re-associate a few seconds later. Unfortunately I did not have debugging enabled for the madwifi driver. The only evidence I see is hostapd's association and dis-associations. This is a live network and unfortunately I was forced to revert back to the 0.9.2.1 code. As soon as this was back on the router everything is stable again and still is. Now I would very much like to take advantage of this patch and the extra sensitivity that I can very clearly see is achieved, how might I help you to diagnose this problem. I can schedule down-time and try this again another day, but this must take place in the early hours of the morning. However I think my network is a good testbed for the code. It has 30+ clients all running pppoe sessions into a router with 4 madwifi devices. The clients are spread over distances from 30m to 1Km and even with the deaf AP most maintain connection speeds above 6Mb/s. This is a dual 5.8GHz and 2.4GHz deployment and the improvements in sensitivity that I see on the 5.8GHz band are profound. In the past signal levels below -75dBm began to be worryingly low. In fact the throughput would 'drop off a cliff' and disconnect within a 3-4dB window below this level. With the patched code I see connectivity maintained down to less than -90dBm...just as Atheros say it should. However deaf or not this network must be stable and I'm not too keen on running 10m up a ladder at 3am with -2deg in order to put things right, (as last night). Does anyone have any suggestions as to the likely culprit? Is it the 0.9.3.3 code itself, or is it the patch? what can I do to help? All the best, and thanks for all your efforts with madwifi, its a stunning success most of the time ;) Aidan On Tue, 2007-12-11 at 12:42 +1300, Scott Raynel wrote: > Improve OFDM sensitivity in non-STA operating modes. > > This patch turns off Interference Mitigation (also known as Ambient > Noise > Immunity) in non-STA modes in order to work around a known bug in the > HAL which > causes poor OFDM sensitivity. > > Reference ticket: > * http://madwifi.org/ticket/705 > > Reference changeset: > * http://madwifi.org/changeset/2843 > > Index: ath/if_athvar.h > =================================================================== > --- ath/if_athvar.h (revision 3013) > +++ ath/if_athvar.h (working copy) > @@ -571,7 +571,8 @@ > sc_rtasksched:1, /* radar task is scheduled */ > sc_dfswait:1, /* waiting on channel for radar detect */ > sc_dfstest:1, /* Test timer in progress */ > - sc_ackrate:1; /* send acks at high bitrate */ > + sc_ackrate:1, /* send acks at high bitrate */ > + sc_hasintmit:1; /* Has interference mitigation */ > /* rate tables */ > const HAL_RATE_TABLE *sc_rates[IEEE80211_MODE_MAX]; > const HAL_RATE_TABLE *sc_currates; /* current rate table */ > @@ -1023,5 +1024,11 @@ > ((*(_ah)->ah_radarWait)((_ah), (_chan))) > #define ath_hal_get_channel_noise(_ah, _chan) \ > ((*(_ah)->ah_getChanNoise)((_ah), (_chan))) > +#define ath_hal_hasintmit(_ah) \ > + (ath_hal_getcapability(_ah, HAL_CAP_INTMIT, 0, NULL) == HAL_OK) > +#define ath_hal_getintmit(_ah, _dst) \ > + ath_hal_getcapability(_ah, HAL_CAP_INTMIT, 1, _dst) > +#define ath_hal_setintmit(_ah, _v) \ > + ath_hal_setcapability(ah, HAL_CAP_INTMIT, 1, _v, NULL) > > #endif /* _DEV_ATH_ATHVAR_H */ > Index: ath/if_ath.c > =================================================================== > --- ath/if_ath.c (revision 3013) > +++ ath/if_ath.c (working copy) > @@ -829,6 +829,12 @@ > */ > sc->sc_hasveol = ath_hal_hasveol(ah); > > + /* Interference Mitigation causes problems with recevive sensitivity > + * for OFDM rates when we are in non-STA modes. We will turn this > + * capability off in non-STA VAPs > + */ > + sc->sc_hasintmit = ath_hal_hasintmit(ah); > + > /* get mac address from hardware */ > ath_hal_getmac(ah, ic->ic_myaddr); > if (sc->sc_hasbmask) { > @@ -1905,6 +1911,11 @@ > > if (sc->sc_softled) > ath_hal_gpioCfgOutput(ah, sc->sc_ledpin); > + > + /* Turn off Interference Mitigation in non-STA modes */ > + if ((sc->sc_opmode != HAL_M_STA) && sc->sc_hasintmit) > + ath_hal_setintmit(ah, 0); > + > /* > * This is needed only to setup initial state > * but it's best done after a reset. > @@ -2155,6 +2166,10 @@ > if (!ath_hal_reset(ah, sc->sc_opmode, &sc->sc_curchan, AH_TRUE, > &status)) > printk("%s: %s: unable to reset hardware: '%s' (HAL status %u)\n", > dev->name, __func__, ath_get_hal_status_desc(status), status); > + > + if ((sc->sc_opmode != HAL_M_STA) && sc->sc_hasintmit) > + ath_hal_setintmit(ah, 0); > + > ath_update_txpow(sc); /* update tx power state */ > if (ath_startrecv(sc) != 0) /* restart recv */ > printk("%s: %s: unable to start recv logic\n", > @@ -7792,6 +7807,9 @@ > if (sc->sc_softled) > ath_hal_gpioCfgOutput(ah, sc->sc_ledpin); > > + if (sc->sc_opmode != HAL_M_STA && sc->sc_hasintmit) > + ath_hal_setintmit(ah, 0); > + > sc->sc_curchan = hchan; > ath_update_txpow(sc); /* update tx power state */ > > > -- > Scott Raynel > WAND Network Research Group > Department of Computer Science > University of Waikato > New Zealand > > > > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Madwifi-devel mailing list > Mad...@li... > https://lists.sourceforge.net/lists/listinfo/madwifi-devel |