Hi, in our setups we experience pure ANI operational in mesh mode
VS AP mode, after debuffing and digging in ANI code i find what ANI
in AP mode work in limited mode, i try this mode with mesh and seems
getting same good operation as in AP mode, i am not familiar with ANI
may be there is another better way to fix this issue?
changes what i made:
diff -ruN compat-drivers-3.7.6-1/drivers/net/wireless/ath/ath9k/ani.c compat-drivers-3.7.6-1-new/drivers/net/wireless/ath/ath9k/ani.c
--- compat-drivers-3.7.6-1/drivers/net/wireless/ath/ath9k/ani.c 2013-02-11 04:23:53.000000000 +0400
+++ compat-drivers-3.7.6-1-new/drivers/net/wireless/ath/ath9k/ani.c 2013-02-16 05:03:46.640746411 +0400
@@ -303,7 +303,8 @@
ah->stats.ast_ani_reset++;
/* only allow a subset of functions in AP mode */
- if (ah->opmode == NL80211_IFTYPE_AP) {
+ if (ah->opmode == NL80211_IFTYPE_AP || ah->opmode == NL80211_IFTYPE_MESH_POINT) {
+ ath_dbg(common, ANI, "only allow a subset of functions in AP or MESH mode");
if (IS_CHAN_2GHZ(chan)) {
ah->ani_function = (ATH9K_ANI_SPUR_IMMUNITY_LEVEL |
ATH9K_ANI_FIRSTEP_LEVEL);
@@ -323,7 +324,8 @@
if (is_scanning ||
(ah->opmode != NL80211_IFTYPE_STATION &&
- ah->opmode != NL80211_IFTYPE_ADHOC)) {
+ ah->opmode != NL80211_IFTYPE_ADHOC &&
+ ah->opmode != NL80211_IFTYPE_MESH_POINT)) {
/*
* If we're scanning or in AP mode, the defaults (ini)
* should be in place. For an AP we assume the historical
C ????????? With Best Regards
???????????? ????. Georgiewskiy Yuriy
+7 4872 711666 +7 4872 711666
???? +7 4872 711143 fax +7 4872 711143
???????? ??? "?? ?? ??????" IT Service Ltd
http://nkoort.ru http://nkoort.ru
JID: [email protected] JID: [email protected]
YG129-RIPE YG129-RIPE
What's _supposed_ to happen on channel change is this:
* There's supposed to be an initial set of calibrations done, including NF;
* the time-adjusted noise floor history for that channel is written out;
* The last set ANI parameters for that channel are written out.
The theory being that the NF and ANI results for a channel are channel
specific and not global.
_However_ this may or may not be correct or working correctly. ANI
doesn't run for long enough during a channel scan to properly figure
out channel conditions. But on a very noisy channel, you may need some
specifically detuned parameters in order to receive successfully.
This is why I was kinda hoping someone would step up and write some
PHY visualisation tools. :-) There's plenty of counters from the
Atheros MAC and PHY hardware; they just need to be logged and graphed!
adrian
Adrian Chadd wrote:
> It's easy enough to diagnose - just enable NF cal logging. Look at
> what's being read back from the initial NF cal and what's being
> written into the time-series average.
I discussed this with Felix a while ago, a small log is here:
http://pastebin.ca/2312828 (Note the jump in signal level).
> It may be that something dumb is happening, like there's no
> per-channel history, or the history from the wrong channel is being
> used on a new channel.
I am not sure about the dumb part, but ath9k doesn't have per-channel
history or calibration data. :)
Sujith
On 2013-02-20 09:24 -0500, Bob Copeland wrote [email protected]:
BC>On Wed, Feb 20, 2013 at 12:31:13AM +0400, Georgiewskiy Yuriy wrote:
BC>> common.h
BC>> #define ATH_EP_RND(x, mul) \
BC>> ((((x)%(mul)) >= ((mul)/2)) ? ((x) + ((mul) - 1)) / (mul) : (x)/(mul))
BC>
BC>Hmm, is that the same as:
BC>
BC> (x + mul/2) / mul?
i think yes, but i dont understand what exactly do this signal processing and why it needed,
i find the source of this changes - http://www.spinics.net/lists/linux-wireless/msg35905.html,
but there is no explain too.
C ????????? With Best Regards
???????????? ????. Georgiewskiy Yuriy
+7 4872 711666 +7 4872 711666
???? +7 4872 711143 fax +7 4872 711143
???????? ??? "?? ?? ??????" IT Service Ltd
http://nkoort.ru http://nkoort.ru
JID: [email protected] JID: [email protected]
YG129-RIPE YG129-RIPE
On Wed, Feb 20, 2013 at 03:25:24PM -0500, Bob Copeland wrote:
> That takes the value read from the card, and multiplies it by
> ATH_RSSI_EP_MULTIPLIER, which is 1<<7. So now it's in fixed-point
> with a 6-bit fractional part.
Sorry, off-by-one: 7-bit fractional part.
--
Bob Copeland %% http://www.bobcopeland.com
Well, ANI does adjust some of its parameters based on the beacon
signal level. It uses that as an estimate for how "strong" the signal
is likely to be and tunes the baseband to either be highly sensitive
or slightly on the deafer side.
If you have many sources of beacons (read: ibss, mesh, TDMA in my
case) then that particular feature of ANI can't be used and it should
be disabled. The code should be special casing it.
I suggest someone writes a bunch of test functions:
* whether we see no beacons (ie, AP mode)
* whether we see one set of beacons (ie, STA mode)
* whether we see multiple sets of beacons (ie ,everything else)
.. and then modify the ANI code to work with the above.
adrian
On Wed, Feb 20, 2013 at 12:31:13AM +0400, Georgiewskiy Yuriy wrote:
> common.h
> #define ATH_EP_RND(x, mul) \
> ((((x)%(mul)) >= ((mul)/2)) ? ((x) + ((mul) - 1)) / (mul) : (x)/(mul))
Hmm, is that the same as:
(x + mul/2) / mul?
--
Bob Copeland %% http://www.bobcopeland.com
I think this is correct.
adrian
On 15 February 2013 18:43, Georgiewskiy Yuriy <[email protected]> wrote:
>
> Hi, in our setups we experience pure ANI operational in mesh mode
> VS AP mode, after debuffing and digging in ANI code i find what ANI
> in AP mode work in limited mode, i try this mode with mesh and seems
> getting same good operation as in AP mode, i am not familiar with ANI
> may be there is another better way to fix this issue?
>
> changes what i made:
>
> diff -ruN compat-drivers-3.7.6-1/drivers/net/wireless/ath/ath9k/ani.c
> compat-drivers-3.7.6-1-new/drivers/net/wireless/ath/ath9k/ani.c
> --- compat-drivers-3.7.6-1/drivers/net/wireless/ath/ath9k/ani.c 2013-02-11
> 04:23:53.000000000 +0400
> +++ compat-drivers-3.7.6-1-new/drivers/net/wireless/ath/ath9k/ani.c
> 2013-02-16 05:03:46.640746411 +0400
> @@ -303,7 +303,8 @@
> ah->stats.ast_ani_reset++;
>
> /* only allow a subset of functions in AP mode */
> - if (ah->opmode == NL80211_IFTYPE_AP) {
> + if (ah->opmode == NL80211_IFTYPE_AP || ah->opmode ==
> NL80211_IFTYPE_MESH_POINT) {
> + ath_dbg(common, ANI, "only allow a subset of functions in AP
> or MESH mode");
> if (IS_CHAN_2GHZ(chan)) {
> ah->ani_function = (ATH9K_ANI_SPUR_IMMUNITY_LEVEL |
> ATH9K_ANI_FIRSTEP_LEVEL);
> @@ -323,7 +324,8 @@
>
> if (is_scanning ||
> (ah->opmode != NL80211_IFTYPE_STATION &&
> - ah->opmode != NL80211_IFTYPE_ADHOC)) {
> + ah->opmode != NL80211_IFTYPE_ADHOC && + ah->opmode !=
> NL80211_IFTYPE_MESH_POINT)) {
> /*
> * If we're scanning or in AP mode, the defaults (ini)
> * should be in place. For an AP we assume the historical
>
>
>
> C ????????? With Best Regards
> ???????????? ????. Georgiewskiy Yuriy
> +7 4872 711666 +7 4872 711666
> ???? +7 4872 711143 fax +7 4872 711143
> ???????? ??? "?? ?? ??????" IT Service Ltd
> http://nkoort.ru http://nkoort.ru
> JID: [email protected] JID: [email protected]
> YG129-RIPE YG129-RIPE
Hello Georgiewskiy,
On Sat, Feb 16, 2013 at 06:43:16AM +0400, Georgiewskiy Yuriy wrote:
>
> Hi, in our setups we experience pure ANI operational in mesh mode
> VS AP mode, after debuffing and digging in ANI code i find what ANI
> in AP mode work in limited mode, i try this mode with mesh and seems
> getting same good operation as in AP mode, i am not familiar with ANI
> may be there is another better way to fix this issue?
We sometimes see some problems too where we suspect ANI, but we are not
and it's hard to reproduce. Our mesh networks are IBSS mode based, not
802.11s mesh, so I wonder if we can apply your findings to IBSS mode too.
Can you describe how your setup looks like, and what difference your patches
make? Did you experience some problem which was easily reproducable?
Also, do you plan to send a proper patch?
Thanks,
Simon
>
> changes what i made:
>
> diff -ruN compat-drivers-3.7.6-1/drivers/net/wireless/ath/ath9k/ani.c compat-drivers-3.7.6-1-new/drivers/net/wireless/ath/ath9k/ani.c
> --- compat-drivers-3.7.6-1/drivers/net/wireless/ath/ath9k/ani.c 2013-02-11 04:23:53.000000000 +0400
> +++ compat-drivers-3.7.6-1-new/drivers/net/wireless/ath/ath9k/ani.c 2013-02-16 05:03:46.640746411 +0400
> @@ -303,7 +303,8 @@
> ah->stats.ast_ani_reset++;
>
> /* only allow a subset of functions in AP mode */
> - if (ah->opmode == NL80211_IFTYPE_AP) {
> + if (ah->opmode == NL80211_IFTYPE_AP || ah->opmode == NL80211_IFTYPE_MESH_POINT) {
> + ath_dbg(common, ANI, "only allow a subset of functions in AP or MESH mode");
> if (IS_CHAN_2GHZ(chan)) {
> ah->ani_function = (ATH9K_ANI_SPUR_IMMUNITY_LEVEL |
> ATH9K_ANI_FIRSTEP_LEVEL);
> @@ -323,7 +324,8 @@
>
> if (is_scanning ||
> (ah->opmode != NL80211_IFTYPE_STATION &&
> - ah->opmode != NL80211_IFTYPE_ADHOC)) {
> + ah->opmode != NL80211_IFTYPE_ADHOC && + ah->opmode !=
> NL80211_IFTYPE_MESH_POINT)) {
> /*
> * If we're scanning or in AP mode, the defaults (ini)
> * should be in place. For an AP we assume the historical
>
>
>
> C уважением With Best Regards
> Георгиевский Юрий. Georgiewskiy Yuriy
> +7 4872 711666 +7 4872 711666
> факс +7 4872 711143 fax +7 4872 711143
> Компания ООО "Ай Ти Сервис" IT Service Ltd
> http://nkoort.ru http://nkoort.ru
> JID: [email protected] JID: [email protected]
> YG129-RIPE YG129-RIPE
>
> hm, but ibss not hit this path too because is_mybeacon is 0 in this mode,
> seems this works only for station mode.
All the mesh nodes will generate its own beacon same as IBSS. Adrian
has mentioned that mode that supports multiple sources of beacons
should be disabled the ANI. Perhaps, someone can comment on this why.
---
Chun-Yeow
Adrian Chadd wrote:
> What's _supposed_ to happen on channel change is this:
>
> * There's supposed to be an initial set of calibrations done, including NF;
> * the time-adjusted noise floor history for that channel is written out;
> * The last set ANI parameters for that channel are written out.
>
> The theory being that the NF and ANI results for a channel are channel
> specific and not global.
>
> _However_ this may or may not be correct or working correctly. ANI
> doesn't run for long enough during a channel scan to properly figure
> out channel conditions. But on a very noisy channel, you may need some
> specifically detuned parameters in order to receive successfully.
I think there are bugs in the NF calibration code in ath9k. I see
wild fluctuations in the signal level before and after nfcal happens, and
this happens in all the chips I tested - AR9285, AR9485, AR9565. Since
nfcal is triggered as part of the ANI calibration routine, this would cause
issues.
Sujith
> but, there is some funny rssi processing sometimes:
>
>
> /* Update Beacon RSSI, this is used by ANI. */
> ah->stats.avgbrssi = rssi;
>
> may be i don't understand something, but looks strange.
If I am not mistaken, mesh node (802.11s) does not process beacon RSSI in ath9k,
---
Chun-Yeow
On 2013-02-15 20:08 -0800, Adrian Chadd wrote Georgiewskiy Yuriy:
it seems there is another one place related to this:
drivers/net/wireless/ath/ath9k/link.c in
void ath_ani_calibrate(unsigned long data)
short_cal_interval = (ah->opmode == NL80211_IFTYPE_AP) ?
should be
short_cal_interval = (ah->opmode == NL80211_IFTYPE_AP || ah->opmode == NL80211_IFTYPE_MESH_POINT) ?
AC>I think this is correct.
AC>
AC>
AC>
AC>adrian
AC>
AC>
AC>On 15 February 2013 18:43, Georgiewskiy Yuriy <[email protected]> wrote:
AC>>
AC>> Hi, in our setups we experience pure ANI operational in mesh mode
AC>> VS AP mode, after debuffing and digging in ANI code i find what ANI
AC>> in AP mode work in limited mode, i try this mode with mesh and seems
AC>> getting same good operation as in AP mode, i am not familiar with ANI
AC>> may be there is another better way to fix this issue?
AC>>
AC>> changes what i made:
AC>>
AC>> diff -ruN compat-drivers-3.7.6-1/drivers/net/wireless/ath/ath9k/ani.c
AC>> compat-drivers-3.7.6-1-new/drivers/net/wireless/ath/ath9k/ani.c
AC>> --- compat-drivers-3.7.6-1/drivers/net/wireless/ath/ath9k/ani.c 2013-02-11
AC>> 04:23:53.000000000 +0400
AC>> +++ compat-drivers-3.7.6-1-new/drivers/net/wireless/ath/ath9k/ani.c
AC>> 2013-02-16 05:03:46.640746411 +0400
AC>> @@ -303,7 +303,8 @@
AC>> ah->stats.ast_ani_reset++;
AC>>
AC>> /* only allow a subset of functions in AP mode */
AC>> - if (ah->opmode == NL80211_IFTYPE_AP) {
AC>> + if (ah->opmode == NL80211_IFTYPE_AP || ah->opmode ==
AC>> NL80211_IFTYPE_MESH_POINT) {
AC>> + ath_dbg(common, ANI, "only allow a subset of functions in AP
AC>> or MESH mode");
AC>> if (IS_CHAN_2GHZ(chan)) {
AC>> ah->ani_function = (ATH9K_ANI_SPUR_IMMUNITY_LEVEL |
AC>> ATH9K_ANI_FIRSTEP_LEVEL);
AC>> @@ -323,7 +324,8 @@
AC>>
AC>> if (is_scanning ||
AC>> (ah->opmode != NL80211_IFTYPE_STATION &&
AC>> - ah->opmode != NL80211_IFTYPE_ADHOC)) {
AC>> + ah->opmode != NL80211_IFTYPE_ADHOC && + ah->opmode !=
AC>> NL80211_IFTYPE_MESH_POINT)) {
AC>> /*
AC>> * If we're scanning or in AP mode, the defaults (ini)
AC>> * should be in place. For an AP we assume the historical
AC>>
AC>>
AC>>
AC>> C ????????? With Best Regards
AC>> ???????????? ????. Georgiewskiy Yuriy
AC>> +7 4872 711666 +7 4872 711666
AC>> ???? +7 4872 711143 fax +7 4872 711143
AC>> ???????? ??? "?? ?? ??????" IT Service Ltd
AC>> http://nkoort.ru http://nkoort.ru
AC>> JID: [email protected] JID: [email protected]
AC>> YG129-RIPE YG129-RIPE
AC>
C ????????? With Best Regards
???????????? ????. Georgiewskiy Yuriy
+7 4872 711666 +7 4872 711666
???? +7 4872 711143 fax +7 4872 711143
???????? ??? "?? ?? ??????" IT Service Ltd
http://nkoort.ru http://nkoort.ru
JID: [email protected] JID: [email protected]
YG129-RIPE YG129-RIPE
Adrian Chadd wrote:
> Yes. I've seen cards that do this. It's almost always due to badly
> placed components/tracks causing spurs / resonance to show up in the
> 2GHz bands.
> It makes the NIC unusable in those modes.
This issue happens on a variety of cards (with ath9k). I think this
might be just a driver bug.
Sujith
Hey Adrian,
On Tue, Feb 19, 2013 at 08:31:25AM -0800, Adrian Chadd wrote:
> Well, ANI does adjust some of its parameters based on the beacon
> signal level. It uses that as an estimate for how "strong" the signal
> is likely to be and tunes the baseband to either be highly sensitive
> or slightly on the deafer side.
>
> If you have many sources of beacons (read: ibss, mesh, TDMA in my
> case) then that particular feature of ANI can't be used and it should
> be disabled. The code should be special casing it.
>
> I suggest someone writes a bunch of test functions:
>
> * whether we see no beacons (ie, AP mode)
> * whether we see one set of beacons (ie, STA mode)
> * whether we see multiple sets of beacons (ie ,everything else)
this sounds useful - and easier to maintain than checking each
IFTYPE seperately (we add iftypes after all ...).
Maybe Felix knows more about this? He has ported ANI as far as I know. :)
Cheers,
Simon
On 2013-02-20 23:31 +0400, Georgiewskiy Yuriy wrote Yeoh Chun-Yeow:
GY>On 2013-02-20 11:30 +0800, Yeoh Chun-Yeow wrote [email protected]:
GY>
GY>YC>> but, there is some funny rssi processing sometimes:
GY>YC>>
GY>YC>>
GY>YC>> /* Update Beacon RSSI, this is used by ANI. */
GY>YC>> ah->stats.avgbrssi = rssi;
GY>YC>>
GY>YC>> may be i don't understand something, but looks strange.
GY>YC>
GY>YC>If I am not mistaken, mesh node (802.11s) does not process beacon RSSI in ath9k,
GY>
GY>Yes, you are right, 802.11s not hit this code path, but there is people who use ibss
GY>and seems have problems with ani too.
hm, but ibss not hit this path too because is_mybeacon is 0 in this mode,
seems this works only for station mode.
C ????????? With Best Regards
???????????? ????. Georgiewskiy Yuriy
+7 4872 711666 +7 4872 711666
???? +7 4872 711143 fax +7 4872 711143
???????? ??? "?? ?? ??????" IT Service Ltd
http://nkoort.ru http://nkoort.ru
JID: [email protected] JID: [email protected]
YG129-RIPE YG129-RIPE
On 2013-02-20 11:30 +0800, Yeoh Chun-Yeow wrote [email protected]:
YC>> but, there is some funny rssi processing sometimes:
YC>>
YC>>
YC>> /* Update Beacon RSSI, this is used by ANI. */
YC>> ah->stats.avgbrssi = rssi;
YC>>
YC>> may be i don't understand something, but looks strange.
YC>
YC>If I am not mistaken, mesh node (802.11s) does not process beacon RSSI in ath9k,
Yes, you are right, 802.11s not hit this code path, but there is people who use ibss
and seems have problems with ani too.
C ????????? With Best Regards
???????????? ????. Georgiewskiy Yuriy
+7 4872 711666 +7 4872 711666
???? +7 4872 711143 fax +7 4872 711143
???????? ??? "?? ?? ??????" IT Service Ltd
http://nkoort.ru http://nkoort.ru
JID: [email protected] JID: [email protected]
YG129-RIPE YG129-RIPE
On 2013-02-21 09:08 +0800, Yeoh Chun-Yeow wrote Georgiewskiy Yuriy:
YC>All the mesh nodes will generate its own beacon same as IBSS. Adrian
YC>has mentioned that mode that supports multiple sources of beacons
YC>should be disabled the ANI. Perhaps, someone can comment on this why.
yes, but according to this there seems unnided check in ath9k_process_rssi for
modes:
if (!rx_stats->is_mybeacon ||
((ah->opmode != NL80211_IFTYPE_STATION) &&
(ah->opmode != NL80211_IFTYPE_ADHOC)))
return;
currently is_mybeacon true only in station mode, it set by this code:
if (ieee80211_is_beacon(hdr->frame_control)) {
RX_STAT_INC(rx_beacons);
if (!is_zero_ether_addr(common->curbssid) &&
ether_addr_equal(hdr->addr3, common->curbssid))
rs.is_mybeacon = true;
else
rs.is_mybeacon = false;
}
else
rs.is_mybeacon = false;
as i understand correctly common->curbssid exists only in client mode.
C ????????? With Best Regards
???????????? ????. Georgiewskiy Yuriy
+7 4872 711666 +7 4872 711666
???? +7 4872 711143 fax +7 4872 711143
???????? ??? "?? ?? ??????" IT Service Ltd
http://nkoort.ru http://nkoort.ru
JID: [email protected] JID: [email protected]
YG129-RIPE YG129-RIPE
On 2013-02-19 08:31 -0800, Adrian Chadd wrote Georgiewskiy Yuriy:
AC>Well, ANI does adjust some of its parameters based on the beacon
AC>signal level. It uses that as an estimate for how "strong" the signal
AC>is likely to be and tunes the baseband to either be highly sensitive
AC>or slightly on the deafer side.
AC>
AC>If you have many sources of beacons (read: ibss, mesh, TDMA in my
AC>case) then that particular feature of ANI can't be used and it should
AC>be disabled. The code should be special casing it.
AC>
AC>I suggest someone writes a bunch of test functions:
AC>
AC>* whether we see no beacons (ie, AP mode)
AC>* whether we see one set of beacons (ie, STA mode)
AC>* whether we see multiple sets of beacons (ie ,everything else)
AC>
AC>.. and then modify the ANI code to work with the above.
I think you are right, but there i think a number of another bugs outside
of ani code - scan somehow triggers ani which adjust levels randomly,
it's triggers it even if ani disabled completely, question - why? random
levels after inserting module and bring up interface, its very annoing on
real network, reboot node - and a number of client will unreacheble, reboot
again - reachble, or part of him, scan on node - same result, this is why
i first disable ani at all, but this no much help me, then start digging
what is wrong. and after this changes i se no difference between AP and
802.11 modes, i think bugs with scan and initialisation steel present,
but ani will work and nivelate this bugs, don't known about other modes,
i just compare with ap.
C ????????? With Best Regards
???????????? ????. Georgiewskiy Yuriy
+7 4872 711666 +7 4872 711666
???? +7 4872 711143 fax +7 4872 711143
???????? ??? "?? ?? ??????" IT Service Ltd
http://nkoort.ru http://nkoort.ru
JID: [email protected] JID: [email protected]
YG129-RIPE YG129-RIPE
On 2013-02-19 11:37 -0800, Adrian Chadd wrote Georgiewskiy Yuriy:
AC>On 19 February 2013 11:11, Georgiewskiy Yuriy <[email protected]> wrote:
AC>
AC>>
AC>> hm, i have signal jumps too on some cards, but it's may be a hardware problem,
AC>> in one of my case this confirmed by manufacturer, then hi block 2.4 bands on it
AC>> where problem occurses, and continue sell it as 5Ggz only card. and i have NF
AC>> calibration jumps on this card too, it easy to se just enable calibration debug
AC>> (echo 0x00000008 > /sys/kernel/debug/ieee80211/phy0/ath9k/debug) and watch on
AC>> log with tail -f, you sould se something like this, may be periodicaly:
AC>>
AC>> 6.505180] ath: phy0: NF calibrated [ctl] [chain 0] is -68
AC>> 6.505185] ath: phy0: NF[0] (-68) > MAX (-97), correcting to MAX
AC>> 6.505188] ath: phy0: NF calibrated [ctl] [chain 1] is -80
AC>> 6.505191] ath: phy0: NF[1] (-80) > MAX (-97), correcting to MAX
AC>> 6.505194] ath: phy0: NF calibrated [ext] [chain 0] is -70
AC>> 6.505197] ath: phy0: NF[3] (-70) > MAX (-97), correcting to MAX
AC>> 6.505200] ath: phy0: NF calibrated [ext] [chain 1] is -80
AC>> 6.505204] ath: phy0: NF[4] (-80) > MAX (-97), correcting to MAX
AC>
AC>Yes. I've seen cards that do this. It's almost always due to badly
AC>placed components/tracks causing spurs / resonance to show up in the
AC>2GHz bands.
AC>It makes the NIC unusable in those modes.
but, there is some funny rssi processing sometimes:
common.h
#define ATH_EP_RND(x, mul) \
((((x)%(mul)) >= ((mul)/2)) ? ((x) + ((mul) - 1)) / (mul) : (x)/(mul))
recv.c
last_rssi = sc->last_rssi;
if (likely(last_rssi != ATH_RSSI_DUMMY_MARKER))
rssi = ATH_EP_RND(last_rssi, ATH_RSSI_EP_MULTIPLIER);
if (rssi < 0)
rssi = 0;
/* Update Beacon RSSI, this is used by ANI. */
ah->stats.avgbrssi = rssi;
may be i don't understand something, but looks strange.
C ????????? With Best Regards
???????????? ????. Georgiewskiy Yuriy
+7 4872 711666 +7 4872 711666
???? +7 4872 711143 fax +7 4872 711143
???????? ??? "?? ?? ??????" IT Service Ltd
http://nkoort.ru http://nkoort.ru
JID: [email protected] JID: [email protected]
YG129-RIPE YG129-RIPE
It's easy enough to diagnose - just enable NF cal logging. Look at
what's being read back from the initial NF cal and what's being
written into the time-series average.
It may be that something dumb is happening, like there's no
per-channel history, or the history from the wrong channel is being
used on a new channel.
I know the reference driver has a couple of options (per-channel NF
history or shared NF history with a "scan" not using the history
buffer..)
adrian
On 2013-02-19 14:40 +0100, Simon Wunderlich wrote Georgiewskiy Yuriy:
Hi, i don't know mutch about ibss mode, but in 802.11s we expirience massive
packetloss sometime, also according to signal levels ani seems not work at all,
it adjust some level while interface startup, then it stay forether, levels
varies about from -10 to -60db dBm, for example - rmmod then insmod, bring interface
up - see one level, rmmod then insmod, bring interface up - another level,
and so on, also seems issuing scan make some level ajust, in random side too.
but as i say before - i dont familiar with ani, i just make it work in 802.11s
mode as in AP mode and this helps. you can try of cose my patch, just change
NL80211_IFTYPE_MESH_POINT to NL80211_IFTYPE_ADHOC, but i don't known make it
sence or not.
SW>Hello Georgiewskiy,
SW>
SW>On Sat, Feb 16, 2013 at 06:43:16AM +0400, Georgiewskiy Yuriy wrote:
SW>>
SW>> Hi, in our setups we experience pure ANI operational in mesh mode
SW>> VS AP mode, after debuffing and digging in ANI code i find what ANI
SW>> in AP mode work in limited mode, i try this mode with mesh and seems
SW>> getting same good operation as in AP mode, i am not familiar with ANI
SW>> may be there is another better way to fix this issue?
SW>
SW>We sometimes see some problems too where we suspect ANI, but we are not
SW>and it's hard to reproduce. Our mesh networks are IBSS mode based, not
SW>802.11s mesh, so I wonder if we can apply your findings to IBSS mode too.
SW>
SW>Can you describe how your setup looks like, and what difference your patches
SW>make? Did you experience some problem which was easily reproducable?
SW>Also, do you plan to send a proper patch?
SW>
SW>Thanks,
SW> Simon
SW>
SW>>
SW>> changes what i made:
SW>>
SW>> diff -ruN compat-drivers-3.7.6-1/drivers/net/wireless/ath/ath9k/ani.c compat-drivers-3.7.6-1-new/drivers/net/wireless/ath/ath9k/ani.c
SW>> --- compat-drivers-3.7.6-1/drivers/net/wireless/ath/ath9k/ani.c 2013-02-11 04:23:53.000000000 +0400
SW>> +++ compat-drivers-3.7.6-1-new/drivers/net/wireless/ath/ath9k/ani.c 2013-02-16 05:03:46.640746411 +0400
SW>> @@ -303,7 +303,8 @@
SW>> ah->stats.ast_ani_reset++;
SW>>
SW>> /* only allow a subset of functions in AP mode */
SW>> - if (ah->opmode == NL80211_IFTYPE_AP) {
SW>> + if (ah->opmode == NL80211_IFTYPE_AP || ah->opmode == NL80211_IFTYPE_MESH_POINT) {
SW>> + ath_dbg(common, ANI, "only allow a subset of functions in AP or MESH mode");
SW>> if (IS_CHAN_2GHZ(chan)) {
SW>> ah->ani_function = (ATH9K_ANI_SPUR_IMMUNITY_LEVEL |
SW>> ATH9K_ANI_FIRSTEP_LEVEL);
SW>> @@ -323,7 +324,8 @@
SW>>
SW>> if (is_scanning ||
SW>> (ah->opmode != NL80211_IFTYPE_STATION &&
SW>> - ah->opmode != NL80211_IFTYPE_ADHOC)) {
SW>> + ah->opmode != NL80211_IFTYPE_ADHOC && + ah->opmode !=
SW>> NL80211_IFTYPE_MESH_POINT)) {
SW>> /*
SW>> * If we're scanning or in AP mode, the defaults (ini)
SW>> * should be in place. For an AP we assume the historical
SW>>
SW>>
SW>>
SW>> C уважением With Best Regards
SW>> Георгиевский Юрий. Georgiewskiy Yuriy
SW>> +7 4872 711666 +7 4872 711666
SW>> факс +7 4872 711143 fax +7 4872 711143
SW>> Компания ООО "Ай Ти Сервис" IT Service Ltd
SW>> http://nkoort.ru http://nkoort.ru
SW>> JID: [email protected] JID: [email protected]
SW>> YG129-RIPE YG129-RIPE
SW>
SW>
C уважением With Best Regards
Георгиевский Юрий. Georgiewskiy Yuriy
+7 4872 711666 +7 4872 711666
факс +7 4872 711143 fax +7 4872 711143
Компания ООО "Ай Ти Сервис" IT Service Ltd
http://nkoort.ru http://nkoort.ru
JID: [email protected] JID: [email protected]
YG129-RIPE YG129-RIPE
On Wed, Feb 20, 2013 at 11:55:14PM +0400, Georgiewskiy Yuriy wrote:
> i think yes, but i dont understand what exactly do this signal processing and why it needed,
> i find the source of this changes - http://www.spinics.net/lists/linux-wireless/msg35905.html,
> but there is no explain too.
Yeah, me neither, but just going on the macros:
> +#define ATH_RSSI_IN(x) (ATH_EP_MUL((x),
> ATH_RSSI_EP_MULTIPLIER))
That takes the value read from the card, and multiplies it by
ATH_RSSI_EP_MULTIPLIER, which is 1<<7. So now it's in fixed-point
with a 6-bit fractional part.
> +#define ATH_LPF_RSSI(x, y, len) \
> + ((x != ATH_RSSI_DUMMY_MARKER) ? (((x) * ((len) - 1) + (y)) / (len))
> : (y))
Low pass filter, aka moving average. So rssi values are first moved into
fixed point range, some averaging is done on the samples, presumably to
reduce the variance, then the result is rounded back into non-fractional
units.
((x + m/2)/m is the fixed point version of int(x + 0.5) if 'm' is the
representation of 1.0 in fixed point.
--
Bob Copeland %% http://www.bobcopeland.com
On 19 February 2013 11:11, Georgiewskiy Yuriy <[email protected]> wrote:
>
> hm, i have signal jumps too on some cards, but it's may be a hardware problem,
> in one of my case this confirmed by manufacturer, then hi block 2.4 bands on it
> where problem occurses, and continue sell it as 5Ggz only card. and i have NF
> calibration jumps on this card too, it easy to se just enable calibration debug
> (echo 0x00000008 > /sys/kernel/debug/ieee80211/phy0/ath9k/debug) and watch on
> log with tail -f, you sould se something like this, may be periodicaly:
>
> 6.505180] ath: phy0: NF calibrated [ctl] [chain 0] is -68
> 6.505185] ath: phy0: NF[0] (-68) > MAX (-97), correcting to MAX
> 6.505188] ath: phy0: NF calibrated [ctl] [chain 1] is -80
> 6.505191] ath: phy0: NF[1] (-80) > MAX (-97), correcting to MAX
> 6.505194] ath: phy0: NF calibrated [ext] [chain 0] is -70
> 6.505197] ath: phy0: NF[3] (-70) > MAX (-97), correcting to MAX
> 6.505200] ath: phy0: NF calibrated [ext] [chain 1] is -80
> 6.505204] ath: phy0: NF[4] (-80) > MAX (-97), correcting to MAX
Yes. I've seen cards that do this. It's almost always due to badly
placed components/tracks causing spurs / resonance to show up in the
2GHz bands.
It makes the NIC unusable in those modes.
Adrian
On 2013-02-20 00:14 +0530, Sujith Manoharan wrote Adrian Chadd:
SM>Adrian Chadd wrote:
SM>> It's easy enough to diagnose - just enable NF cal logging. Look at
SM>> what's being read back from the initial NF cal and what's being
SM>> written into the time-series average.
SM>
SM>I discussed this with Felix a while ago, a small log is here:
SM>http://pastebin.ca/2312828 (Note the jump in signal level).
SM>
SM>> It may be that something dumb is happening, like there's no
SM>> per-channel history, or the history from the wrong channel is being
SM>> used on a new channel.
SM>
SM>I am not sure about the dumb part, but ath9k doesn't have per-channel
SM>history or calibration data. :)
hm, i have signal jumps too on some cards, but it's may be a hardware problem,
in one of my case this confirmed by manufacturer, then hi block 2.4 bands on it
where problem occurses, and continue sell it as 5Ggz only card. and i have NF
calibration jumps on this card too, it easy to se just enable calibration debug
(echo 0x00000008 > /sys/kernel/debug/ieee80211/phy0/ath9k/debug) and watch on
log with tail -f, you sould se something like this, may be periodicaly:
6.505180] ath: phy0: NF calibrated [ctl] [chain 0] is -68
6.505185] ath: phy0: NF[0] (-68) > MAX (-97), correcting to MAX
6.505188] ath: phy0: NF calibrated [ctl] [chain 1] is -80
6.505191] ath: phy0: NF[1] (-80) > MAX (-97), correcting to MAX
6.505194] ath: phy0: NF calibrated [ext] [chain 0] is -70
6.505197] ath: phy0: NF[3] (-70) > MAX (-97), correcting to MAX
6.505200] ath: phy0: NF calibrated [ext] [chain 1] is -80
6.505204] ath: phy0: NF[4] (-80) > MAX (-97), correcting to MAX
and for example log from normal card:
[61255.118534] ath: phy0: NF calibrated [ctl] [chain 1] is -110
[61255.118544] ath: phy0: NF calibrated [ext] [chain 0] is -108
[61255.118553] ath: phy0: NF calibrated [ext] [chain 1] is -110
[61285.187275] ath: phy0: NF calibrated [ctl] [chain 0] is -109
[61285.187288] ath: phy0: NF calibrated [ctl] [chain 1] is -110
[61285.187297] ath: phy0: NF calibrated [ext] [chain 0] is -108
C ????????? With Best Regards
???????????? ????. Georgiewskiy Yuriy
+7 4872 711666 +7 4872 711666
???? +7 4872 711143 fax +7 4872 711143
???????? ??? "?? ?? ??????" IT Service Ltd
http://nkoort.ru http://nkoort.ru
JID: [email protected] JID: [email protected]
YG129-RIPE YG129-RIPE
On 2013-02-19 10:33 -0800, Adrian Chadd wrote Sujith Manoharan:
AC>It's easy enough to diagnose - just enable NF cal logging. Look at
AC>what's being read back from the initial NF cal and what's being
AC>written into the time-series average.
AC>
AC>It may be that something dumb is happening, like there's no
AC>per-channel history, or the history from the wrong channel is being
AC>used on a new channel.
AC>
AC>I know the reference driver has a couple of options (per-channel NF
AC>history or shared NF history with a "scan" not using the history
AC>buffer..)
i do this already, in my case i dont see anything strange on NF claibration.
C ????????? With Best Regards
???????????? ????. Georgiewskiy Yuriy
+7 4872 711666 +7 4872 711666
???? +7 4872 711143 fax +7 4872 711143
???????? ??? "?? ?? ??????" IT Service Ltd
http://nkoort.ru http://nkoort.ru
JID: [email protected] JID: [email protected]
YG129-RIPE YG129-RIPE