hello all!
we did some tests with 0.9.4 (it is the same as 0.9.3.3 for this matter) with
and without the ANI patch in an urban environment, on a not too busy street
in japan, but with cars and pedestrians passing by. this is our usual
real-life testbed and we have distance marks every 10 or 20m (from 20-240m)
where we made a stop and performed 6 iperf TCP tests as well as 6 rssi and
rate measurements. we started at 20m and moved to a distance of 240m and then
came back again. the average of those measurements is shown in the graph at:
http://br1.einfach.org/ath/madwifi-ani.png
* the green color is 0.9.4 as it is in the svn today, i.e. with ANI turned
off (the patch applied).
* the red color is 0.9.4 but with ANI left ON, i.e. without the patch
* the blue color is trunk, also with ANI ON because there is no way to
turn it off (right now).
i think it basically confirms the results aidan and derek reported. with the
patch (= without ANI) the thruput got worse! an interresting fact may be that
it seems the rate control module can't work so well with ANI disabled (it
stayed at 54 most of the time). in some cases the thruput without ANI was
better but in average it was worse, and it seems a bit "rough", going up and
down unnecessarily.
also in an indoor multihop test, disabling ANI resulted in worse performance:
thruput (Mbps)
hops trunk 0.9.4 0.9.4-ani
--------------------------------------
1 12.3 6.82 12.95
2 6.53 3.57 8.11
3 3.24 2.45 5.03
4 3.36 1.82 3.85
so it seems that in some situations, like high-gain point-to-point links or
lab tests where 2 nodes sit very close to each other, turning ANI off can
result in a better thruput, but in most real-life cases it should stay on.
this makes some sense, since on p2p links or very good links there will not
be so much interference, so no need to adapt to it.
therefore i suggest to keep ANI ON (i.e patch "disabled" by default) in 0.9.4,
but add a iwpriv command to explicitly turn it off, for cases like scotts
where it is not needed. i will send a patch for this shortly.
bruno
On Thursday 20 December 2007 10:17:20 Aidan Walton wrote:
> Hi again,
>
> Ok jitters over for the night. I'm afraid its bad news for the patch!
>
> I loaded 0.9.3.3 without the ANI patch and so far (its only been 20mins)
> all clients are back up and running and no churn. It looks solid. I'll
> leave it on there now and see how we get on.
>
> Hmmm, I think some progress on a real fix to the HAL is needed. That's a
> real shame. Sam??
>
> Maybe after Christmas I'll get a chance to try the patch again and this
> time take a closer look at what might be going on.
>
> All the best
> Aidan
>
> On Wed, 2007-12-19 at 12:55 +1300, Derek Smithies wrote:
> > Hi,
> > Including this patch in the build reduces the cards ability to cope with
> > the presence of noise. Consequently, link performance will vary much
> > more, as a function of time.
> > It is reasonable to expect that some links will go down (briefly).
> > Aidan's report alludes to being in Access Point mode. When the link goes
> > down, the card has to reassociatate and reauthenticate. This burst of
> > traffic between the access point and station may interfere with other
> > links, taking them out, which accounts for the firefly like experience of
> >
> > > > 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,
> >
> > Scott- you won't see this on your psuedo IBSS links - as there is no
> > traffic to reassociate etc.
> >
> > Derek.
> >
> > On Wed, 19 Dec 2007, Scott Raynel wrote:
> > > Hi there,
> > >
> > > Thanks for the interesting read. I'd like to know what caused the
> > > stations to disassociate. Try applying the patch to 0.9.2. If you see
> > > better sensitivity and stable associations then there's obviously a
> > > regression in 0.9.3.3 which needs to be addressed. Alternatively, try
> > > running plain 0.9.3.3 without the patch to see what happens.
> > >
> > > Cheers,
> > >
> > > On 19/12/2007, at 7:12 AM, Aidan Walton wrote:
> > > > 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
> > > >> Madwifi-devel@...
> > > >> https://lists.sourceforge.net/lists/listinfo/madwifi-devel
> > >
> > > --
> > > 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://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/market
> > >place _______________________________________________
> > > Madwifi-devel mailing list
> > > Madwifi-devel@...
> > > https://lists.sourceforge.net/lists/listinfo/madwifi-devel
>
> -------------------------------------------------------------------------
> 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://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplac
>e _______________________________________________
> Madwifi-devel mailing list
> Madwifi-devel@...
> https://lists.sourceforge.net/lists/listinfo/madwifi-devel
|