| Message ID | alpine.DEB.2.02.1302160630580.4293@icf.org.ru (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
I think this is correct. adrian On 15 February 2013 18:43, Georgiewskiy Yuriy <bottleman@icf.org.ru> 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: GHhost@icf.org.ru JID: GHhost@icf.org.ru > YG129-RIPE YG129-RIPE -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <bottleman@icf.org.ru> 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: GHhost@icf.org.ru JID: GHhost@icf.org.ru
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: GHhost@icf.org.ru JID: GHhost@icf.org.ru
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: GHhost@icf.org.ru JID: GHhost@icf.org.ru > YG129-RIPE YG129-RIPE
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: GHhost@icf.org.ru JID: GHhost@icf.org.ru
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: GHhost@icf.org.ru JID: GHhost@icf.org.ru
YG129-RIPE YG129-RIPE
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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: GHhost@icf.org.ru JID: GHhost@icf.org.ru 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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: GHhost@icf.org.ru JID: GHhost@icf.org.ru YG129-RIPE YG129-RIPE
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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: GHhost@icf.org.ru JID: GHhost@icf.org.ru YG129-RIPE YG129-RIPE
On 19 February 2013 11:11, Georgiewskiy Yuriy <bottleman@icf.org.ru> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2013-02-19 11:37 -0800, Adrian Chadd wrote Georgiewskiy Yuriy:
AC>On 19 February 2013 11:11, Georgiewskiy Yuriy <bottleman@icf.org.ru> 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: GHhost@icf.org.ru JID: GHhost@icf.org.ru
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 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?
On 2013-02-20 11:30 +0800, Yeoh Chun-Yeow wrote devel@lists.open80211s.org: 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: GHhost@icf.org.ru JID: GHhost@icf.org.ru YG129-RIPE YG129-RIPE
On 2013-02-20 09:24 -0500, Bob Copeland wrote devel@lists.open80211s.org: 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: GHhost@icf.org.ru JID: GHhost@icf.org.ru 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.
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.
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 devel@lists.open80211s.org: 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: GHhost@icf.org.ru JID: GHhost@icf.org.ru 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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: GHhost@icf.org.ru JID: GHhost@icf.org.ru
YG129-RIPE YG129-RIPE
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