Atheros Sensitivity

Is this specific to the HAL revision (have you tried prior HALS)?

There has been a discussion in the user and devel mailing lists on this, in case you'd not seen it- "Big Problem...", about 1-3 months back.

There are reported sensitivity problems, and I'll try to discuss this with Atheros. However, our contact currently is burried with LOTS of work and it will take some time until this talks can take place.

Please have a look at the discussion p0g0 mentions. It shouldn't be too hard to locate it in the mailing list archives. Please add missing facts as comments to this ticket. Thanks.

I've also noticed sensitivity problems with the latest drivers using A mode (OFDM modulation scheme). With commercial drivers (for example the mikrotik OS drivers) the sensitivity is around -94 dBm, while with MadWifi the sensitivity is only around -84 dBm. A loss of 10 dBm. I can't find anything about in the HAL documentation nor in the source code of MadWifi, so I also suspect this is an issue in the HAL itself.

What is the status of this ticket? Has it been discussed with Atheros?

Does this help to explain the -84? http ://madwifi.org/wiki/UserDocs/RSSI

Besides using the RSSI we also did measurements with external hardware tools for examining this issue, which are based on dBm. We used an attenuator connected with wires between the external antenna connectors of two atheros cards to be able to accurately lower the signal strength of the transmitter. The transmitter was set on transmitting at 0 dbm (lowest power setting). When the receiver is using a commercial driver we could set the attenuator at 94 dBm and packets were still correctly received. When the receiver is using MadWifi the packets were not received anymore with the attenuator set on 85 dBm or higher.

on which HAL version ya have done that nice real world testing ? Have ya tried various HAL versions, or only one ?

I've used HAL 0.9.18.0 and 0.9.17.2 for testing.

Would you mind to try newer HALs too, if this issue is still there ?

Just a quick point.

dBM is a decibel measurment system, with a reference level of 1mW (One milliwatt). decibel is a logarithmic scale. An change of 3dB corresponds to a multiplier of 2 on the original value.

Thus, -95dBm is smaller than 0dBm is smaller than 10dBm.

OK, so the most we seem to be able to do is ask the HAL about the RF gain, and it will tell us if we need to recalibrate; if we do, then we reset the chip. There doesn't seem to be any way we can influence the gain setting on the PHY chip.

However, OpenHAL seems to have the registers for the gain on the PHY chip, and has a gain adjustment routine, so it might be worth looking at that...

Replying to tjalling.hattink@ti-wmc.nl:

Has it been discussed with Atheros?

Nope, as I have been wrong in that point: HAL issues of course need to be discussed with the entity that delivers the HAL, which is Sam and not Atheros at this time. And to be honest, this has not yet been fired at Sam yet.

However, there is a list of open questions for Sam, and this one will be added there.

I checked the new 0.9.30.13 HAL and the sensitivity didn't improve either in my setup.

Maybe another interesting fact I noticed is that the lowest reported RSSI value is around 12, which roughly matched the sensitivity difference between madwifi and the routeros driver. You would expect that RSSI value becoming low as 0 or 1 when packets are received at lowest snr.

it has been still connected when you set attenuator at 84dbm or higher? Hasn't, when RSSI decreased under 12dbm or something, one or both sides of connection started to scan for better AP or simply disconnect? Maybe this "bad sensitivity" problem is in fact problem of rssi11a treshold , which could be changed with iwpriv command? But i doubt it,treshold is above 20 if i properly remember.

Both the transmitter and receiver are working in ad-hoc mode. So there is no roaming or association going on. I measure the strength of received beacons, which are transmitted at lowest rate.

Alright, here are some new findings from my latest experiments. I tried the latest dadwifi-openhal branch r2536 and its sensitivity was good (packets with RSSI value of 2 were still received). So my first impression was that the openhal didn't have these OFDM sensitivity problems.

Then I took the dadwifi branch (with atheros HAL 0.9.18.0) r2535 and expected it to have sensitivity problems because of the HAL. But this wasn't the case! With dadwifi I could also receive OFDM packets with RSSI values around 2). This was unexpected. It means that the HAL is not the cause of the sensitivity problems and the issue is probably in the open source part of MadWifi.

The next thing we should do is comparing MadWifi with DadWifi and see what they are doing differently with the HAL. Maybe DadWifi uses different OFDM settings, or (lack of) setting sensitivity options of the HAL?

Comparing MadWifi and DadWifi code, the former used its own 80211 stack while the latter used the linux 80211 stack. The comparison is not that straightforward. To further complicate things, I cannot try Dadwifi on our platform because it can only be compiled for Linux 2.6.18 and higher because mac80211 is not supported for lower versions(correct me if I'm wrong). Our current firmware is using 2.6.12.

Any ideas on how to resolve the problem? or any suggestions on how to proceed the investigation?

I've noticed that if you turn protmode off ("iwpriv ath0 protmode 0" on your AP if it's an Atheros AP, and possibly also on the client card as well), you can achieve much better RX sensitivity. Can anyone else verify that performance is increased with this?

I saw that the AP was blasting the channel with CTS packets once my client hit a certain RSSI, and once I set protmode off, the CTS packets were not sent, and I could be much further from my AP.

I have also noticed that in the very latest subversion build, sometimes turning protmode off doesn't help at all. It seems like it helped more in 0.9.2.x.

After more endless testing with DadWifi-openhal, DadWifi and MadWifi I finally figured out what is actually causing the sensitivity issues. First, my findings in my previous post on 07/23/7 are not correct. The reason why DadWifi worked in my case and MadWifi didn't was caused by the fact that I tested DadWifi under station mode and MadWifi under adhoc mode. So the mode setting has influence on the sensitivity and not the driver version.

Secondly, the HAL does cause the sensitivity issues. After testing all possible modes under MadWifi I figured out that the sensitivity problem always occur except when using station (client) mode. When checking the HAL function calls made from MadWifi I found out that the ath_hal_reset function passes the current mode setting to the HAL and influences the sensitivity. When I override the mode argument with station mode (HAL_M_STA) in the function calls to ath_hal_reset even when MadWifi runs in another mode (e.g. adhoc) the sensitivity problems are gone! So the HAL is causing these issues.

After discussing these findings with Sam Leffler I received a few hints on the usage of ANI (ambient noise immunity) in the HAL. This algorithm can be influenced or even turned off by using capability calls. After some experimenting I figured out that turning off ANI after a reset in non-station mode the sensitivity issues do not occur. So the ANI algorithm doesn't seem to function properly in non-station modes.

I'll attach a patch that turns off ANI after each reset so please test if it helps in your situation when having sensitivity issues. This only works in access point/adhoc/monitor modes! If you use MadWifi as client only this patch won't fix your sensitivity problems! ANI should work properly in that case and any sensititivy issues are probably caused by other (unknown) factors.

Now the bad news about this patch. First, it is a hack. The correct fix should be applied in the HAL itself. ANI should be used on all modes, not only in station mode to account for ambient noise and temperature changes. This fix can only be performed by the HAL maintainer Sam Leffler. He knows about it and was going to look at it someday but I have no idea when he's going to look into it and when an updated version of the HAL becomes available. Until that time this patch can be a replacement fix.

Secondly, this patch only works on older HALs. The last working HAL version is 0.9.18.0, used in MadWifi 0.9.3.3. The newer HAL 0.9.30.13 used in the trunk and MadWifi-dfs branch does NOT react on this patch and ANI stays on and causes sensitivity problems. This is really a pity because I would rather use the new HAL with better DFS support and lots of other fixes. As long as Sam doesn't release an update of 0.9.30.13 you can expect sensitivity issues in trunk or MadWifi-dfs.

ANI sensitivity patch.

Ofcourse the patch needs to be signed off.

Signed-off-by: Tjalling Hattink <tjalling.hattink@ti-wmc.nl> Twente Institute of Wireless and Mobile Communications

Thanks!

r2843

Usefull you just patched code without any result...

The ticket states the fix only works on older hals. So the patch should be applied to 0.9.3.x versions since these still run with HAL 0.9.18

This fix doesn't help on a 0.9.30.x based HAL and thus there is no need to apply the fix in trunk.. It would be better to put effort in fixing the real cause of the problem.

Replying to anonymous:

The ticket states the fix only works on older hals. So the patch should be applied to 0.9.3.x versions since these still run with HAL 0.9.18

True. mentor, please also merge r2843 to madwifi/releases/0.9.3, so that it is included in the next 0.9.3.x release.

It would be better to put effort in fixing the real cause of the problem.

As stated above the only person who can fix "the real cause of the problem" is Sam. He seems to be aware of the issue and hopefully will fix it. There's virtually nothing we can do about it (despite bugging him, which most probably will have no positive but surely some negative effect, so we should stay away from that option).

here's another idea on how to forcibly disable ani operation: use ah_updateMibCounters to clear the mib event instead of ah_procMibEvent

Could you please explain more. I've been googling for this function but it doesn't give me any hints.

All I see are 3 variables which could be filed with average RSSI values which could be updated and given to the HAL. Problem is what does this values mean for a card in AP or Adhoc mode?

There is only 1 set of variables for all received traffic?!?!? So what should go in these varables.

Does this mean that ANI is working in station mode due to the fact that there are average RSSI values filed for received beacons?

This patch works for me !!

Many thanks !

Hi,

By rolling back to 0.9.3 and turning off ANI, links that were previously unusable are now running at 10Mbit/s.

Thanks for the patch!

Although the patch works for getting the receive sensitivity. I want to warn it can introduce the infamous stuck beacon problem again.

At one of our outdoor test locations the noisefloor is around -81dBm (which is pretty high) by disabling Ambient Noise Immunity we proved this mechanism does work in these conditions.

When we disable ANI in this location no beacons are sent anymore! When we enable ANI beacons are send without issues...

So when you hit this old beacon stuck issue again, revert the attached patch...

Replying to scottr:

By rolling back to 0.9.3

I think it's just a typo, but anyway (and to be on the safe side):

You should not use v0.9.3 in production environments, as it has various security issues that have been fixed already. Use 0.9.3.3 instead, which (HAL-wise) similar to 0.9.3.

Replying to mrenzmann:

You should not use v0.9.3 in production environments, as it has various security issues that have been fixed already. Use 0.9.3.3 instead, which (HAL-wise) similar to 0.9.3.

Well, yes, I meant the 0.9.3 branch, to indicate that I was using the older HAL.

Cheers,

madwifi release 0.9.4 adds a sysctl "intmit" to turn ANI on and off. ANI is enabled by default and can be disabled in cases where this yields better performance.

example: sysctl -w dev.wifi0.intmit=0

Some useful information for anyone looking to get a fix for this problem:

The fix above is in the 0.9.4 release. This is the changeset : 3120

However there are also similar fixes in the madwifi-dfs branch and the trunk now. madwifi-dfs : 3375 trunk: 3505

We have investigated the ANI problem described in this ticket more thoroughly. The test where executed under release-0.9.4, which uses hal version 0.9.18.0.

As previously mentioned in on the mailinglist (1), turning ANI off gives at least performance issues in urban environments.

We saw that the ANI algorithm consist of different steps, setting different registers to adapt noise immunity. Among them are (2):

• OFDM weak signal detection
• Noise immunity level
• Spur immunity level
• CCK weak signal detection
• Fir step level

These can also be found in the hal extensions (r3495), added by mtaylor and the changeset r3505 which disables ANI in the current trunk (HAL version 0.9.30.13).

Our conclusion after extensive testing and experimenting is that the ANI algorithm in the HAL (0.9.18.0) is actually working, except that the OFDM weak signal detection parameter is not initialised properly after a radio reset. A patch for the sources is made with a fix that forces the hopefully correct OFDM weak signal setting into the HAL after each reset. The sensitivity is initial high, but will be adapted according to the environment. This is different compared to the previous fix where ANI was disabled totally.

A new patch is added to this ticket for madwifi release-0.9.4 (ani_sensitivity_fix_v2.diff). We hope this patch will be tested in different environments, and hope to receive feedback on the results.

References:

• (1) Ani thread madwifi: gmane.linux.drivers.madwifi.devel/5557
• (2) Ani thread ath5k: gmane.linux.drivers.ath5k.devel/340

Signed-off-by: Michel Lammertink <mlammertink@ti-wmc.nl> Twente Institute of Wireless and Mobile Communications

ANI sensitivity patch version 2

Replying to mlammertink@ti-wmc.nl:

A new patch is added to this ticket for madwifi release-0.9.4 (ani_sensitivity_fix_v2.diff). We hope this patch will be tested in different environments, and hope to receive feedback on the results. References: * (1) Ani thread madwifi: gmane.linux.drivers.madwifi.devel/5557 * (2) Ani thread ath5k: gmane.linux.drivers.ath5k.devel/340 Signed-off-by: Michel Lammertink <mlammertink@ti-wmc.nl> Twente Institute of Wireless and Mobile Communications

It really looks like this has finally solved the sensitivity issue. I had tried the first patch before 0.9.4 which disabled totally the ANI and it caused big problems in the environment I'm operating in. I have over 30 users connected 24x7 in a rural area, coverage from the access point is approx max radius of 1Km. When I turned off ANI totally my connections began dropping in and out like fireflys as the noise floor changed and the signal quality varied. With this new fix I am seeing much improved performance. I maintain 11Mb/s to stations with S/N @ -81dBm where previously these stations would be connected at 1Mb/s. Great work, a real tangible and practical improvement. Thank you.

Replying to mlammertink@ti-wmc.nl:

We have investigated the ANI problem described in this ticket more thoroughly. The test where executed under release-0.9.4, which uses hal version 0.9.18.0.

Hi, thanks for the patch. Just to clarify (so I can test properly), this patch should be applied to a clean 0.9.4 branch? None of the various ANI bits and pieces in trunk need to be present?

Cheers,

Previous message was from me.

Replying to anonymous:

Hi, thanks for the patch. Just to clarify (so I can test properly), this patch should be applied to a clean 0.9.4 branch? None of the various ANI bits and pieces in trunk need to be present? Cheers,

Apply it to the clean 0.9.4 release (root/madwifi/tags/release-0.9.4). Do not know if it also works for the 0.9.4 branche because I do not know the differences at the moment. The ANI changes in trunk are not needed.

The ANI changes in trunk are not needed.

This means that trunk (currently r3680) is already patched/fixed against the sensitivity issue? Thanks

The ANI changes in trunk are not needed.

This means that trunk (currently r3680) is already patched/fixed against the sensitivity issue?

Sorry, what I meant to say was: The ANI changes in trunk are not needed for my patch. The patch was made for release-0.9.4.

AFAIK it is possible to turn ANI on or off in trunk and release-0.9.4. This on/off option was added because ANI reduced the sensitivity of the receiver. When ANI was disabled the sensitivity was normal again, but people experienced problems in urban environments. (see article.gmane.org/gmane.linux.drivers.madwifi.devel/5668).

My patch fixes an initialization issue for OFDM weak signal detection, but does not turn off ANI! This will hopefully fix the sensitivity problems of ANI, without disabling it completely.

Regarding the v2 patch: what is "3" and what is "1"? Where does it come from? What is the value before "1"? Is it random? What does HAL do? Do we see other (e.g. Windows) drivers do it? We can find out with mmiotrace, which is in Linux 2.6.27-rc1 already.

Also, why do we need to set it in 3 places? Can we group similar initializations into one function?

Replying to proski:

Regarding the v2 patch: what is "3" and what is "1"?

"3" is the OFDM weak signal detection ANI parameter identifier, which can be set to on ("1") or off ("0").

Where does it come from?

Sam.

What is the value before "1"?

This is the strange part. From what I remember, reading it gives 1, but it seems that the return value is inverted. Thats why I forced "1" again to enable OFDM weak signal detection.

Is it random?

No

What does HAL do?

The HAL only initializes this value. I never noticed a change in OFDM weak signal detection while the algorithm was running.

Do we see other (e.g. Windows) drivers do it?

According to the patent and Windows implementation the OFDM weak signal detection should be turned on.

Also, why do we need to set it in 3 places? Can we group similar initializations into one function?

It seems reasonable to set it in the init method. I also set it in the reset function because the Interference Mitigation is also enabled/disabled there. The documentation of the ath_chan_set function mentions a reset of the chip, thats why I set it there also. It can probably be combined with the interference mitigation setting but currently I'm not sure about that.

Question from my side: Has anyone besides awalton tested the patch? Please report your results when you have? Thanks.

Michel.

Replying to mlammertink@ti-wmc.nl:

Question from my side: Has anyone besides awalton tested the patch? Please report your results when you have? Thanks.

I'm a wifi internals neophyte, so please be gentle. I'm not sure if this is relevant or just coincidental...

I have tried the v2 patch in an attempt to get stable rates (that don't plummet to 1Mbps under moderate load) between an AP and two clients (all Dlink DWL G520). All are running a patched 0.9.4, in G-only mode, channel 1 (no neighbours), antenna diversity off, and WPA-PSK with CCMP. The only change I noticed is a dramatic increase in the incidence of the infamous stuck beacon problem at the AP, which had previously been quite rare.

If there's a specific test or output you'd like then I'm more than willing to spend some time but I'll need specific set-up details.

Regards,
Chris Williams

I am having sensitivity problems running the kernel 2.6.27 on ThinkPad? T60p (AR5212 802.11abg NIC (rev 01)). Among other things, I tried building the latest SVN version of the driver, and applying the patch from this ticket. It did not help (still low signal reported, practically unusable connection), but I'd report because the patch v2 does not apply to the SVN source. At revision 3901, this got rejected:

--- 1035,1041 ----
        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)
+ #define ath_hal_setintmitofdmweaksignaldetection(_ah, _v) \
+       ath_hal_setcapability(ah, HAL_CAP_INTMIT, 3, _v, NULL)

  #endif /* _DEV_ATH_ATHVAR_H */

and I replaced it with this:

--- ath/if_ath_hal_wrappers.h   (revision 3901)
+++ ath/if_ath_hal_wrappers.h   (working copy)
@@ -286,6 +286,12 @@
        return (ath_hal_setcapability(ah, HAL_CAP_INTMIT, 1, v, NULL));
 }

+static inline HAL_BOOL ath_hal_setintmitofdmweaksignaldetection
+                                       (struct ath_hal *ah, u_int32_t v)
+{
+       return (ath_hal_setcapability(ah, HAL_CAP_INTMIT, 3, v, NULL));
+}
+
 /* misc */

 static inline HAL_BOOL ath_hal_getcountrycode(struct ath_hal *ah, u_int32_t *destination)

I have no idea if the patch is needed for this version whatsoever, just FYI.

Eugene