* [ath9k-devel] Unrealistic RSSI values being reported @ 2011-11-03 19:28 Daniel Smith 2011-11-03 23:10 ` Mohammed Shafi 0 siblings, 1 reply; 16+ messages in thread From: Daniel Smith @ 2011-11-03 19:28 UTC (permalink / raw) To: ath9k-devel I recently upgraded to compat-wireless-3.1-rc8 from compat-wireless-2.6.39-1-sn and have discovered an interesting behavior. When in monitor mode I use the signal strength field reported in radiotap and with 3.1 I am now getting a range of values. The more interesting ones are all the frames reporting a signal of 110+ dBm. To see what is being pulled from the descriptors I dumped rs->rs_rssi to klog when the value was larger than 95. Below is a snippet showing the ranging values, Nov 3 15:00:03 dpsmith-dev-system kernel: [ 5319.907908] [ath9k]: RSSI 107 Nov 3 15:00:03 dpsmith-dev-system kernel: [ 5319.911697] [ath9k]: RSSI -61 Nov 3 15:00:03 dpsmith-dev-system kernel: [ 5319.913553] [ath9k]: RSSI -119 Nov 3 15:00:03 dpsmith-dev-system kernel: [ 5319.913562] [ath9k]: RSSI -59 Nov 3 15:00:03 dpsmith-dev-system kernel: [ 5319.913570] [ath9k]: RSSI -94 Nov 3 15:00:03 dpsmith-dev-system kernel: [ 5319.915880] [ath9k]: RSSI 119 Nov 3 15:00:03 dpsmith-dev-system kernel: [ 5319.915890] [ath9k]: RSSI -109 Nov 3 15:00:03 dpsmith-dev-system kernel: [ 5319.915898] [ath9k]: RSSI 123 Nov 3 15:00:03 dpsmith-dev-system kernel: [ 5319.917743] [ath9k]: RSSI 101 A couple of data points, 1. I have tested two different cards, one having AR9106+AR9160 and one with an AR9382. 2. It appears that it is always the same devices that this occurs for, e.g. pretty confident there are some devices that I collected that I did not see anything out of the 3-10dBm range I know 2.6.39 -> 3.1 is a bit of a jump, but I wanted to push this to the community to see if there are some thoughts or opinions while I dig deeper. My next step is to see if it occurs in 3.0 which should help give me a narrow set of patches to review/bisect to see at what point this was introduced. I would suspect it to be an initval issue, but the two chips I have should have different initval sets. Any thoughts or suggestions would be greatly appreciated. dps ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ath9k-devel] Unrealistic RSSI values being reported 2011-11-03 19:28 [ath9k-devel] Unrealistic RSSI values being reported Daniel Smith @ 2011-11-03 23:10 ` Mohammed Shafi 2011-11-04 11:27 ` Daniel Smith 2011-11-04 17:50 ` Daniel Smith 0 siblings, 2 replies; 16+ messages in thread From: Mohammed Shafi @ 2011-11-03 23:10 UTC (permalink / raw) To: ath9k-devel Hi Daniel, On Fri, Nov 4, 2011 at 12:58 AM, Daniel Smith <viscous.liquid@gmail.com> wrote: > I recently upgraded to compat-wireless-3.1-rc8 from > compat-wireless-2.6.39-1-sn and have discovered an interesting behavior. > When in monitor mode I use the signal strength field reported in > radiotap and with 3.1 I am now getting a range of values. The more > interesting ones are all the frames reporting a signal of 110+ dBm. To > see what is being pulled from the descriptors I dumped rs->rs_rssi to > klog when the value was larger than 95. Below is a snippet showing the > ranging values, i tried with the AR9382 card in 3.1.0-wl with the attached debug patch, can you please give a sample log with the patch applied and putting the interface in monitor mode. did you print/check rs_rssi somewhere else? did you also try with the latest package http://linuxwireless.org/download/compat-wireless-2.6/ > > Nov ?3 15:00:03 dpsmith-dev-system kernel: [ 5319.907908] [ath9k]: RSSI 107 > Nov ?3 15:00:03 dpsmith-dev-system kernel: [ 5319.911697] [ath9k]: RSSI -61 > Nov ?3 15:00:03 dpsmith-dev-system kernel: [ 5319.913553] [ath9k]: RSSI -119 > Nov ?3 15:00:03 dpsmith-dev-system kernel: [ 5319.913562] [ath9k]: RSSI -59 > Nov ?3 15:00:03 dpsmith-dev-system kernel: [ 5319.913570] [ath9k]: RSSI -94 > Nov ?3 15:00:03 dpsmith-dev-system kernel: [ 5319.915880] [ath9k]: RSSI 119 > Nov ?3 15:00:03 dpsmith-dev-system kernel: [ 5319.915890] [ath9k]: RSSI -109 > Nov ?3 15:00:03 dpsmith-dev-system kernel: [ 5319.915898] [ath9k]: RSSI 123 > Nov ?3 15:00:03 dpsmith-dev-system kernel: [ 5319.917743] [ath9k]: RSSI 101 > > A couple of data points, > ?1. I have tested two different cards, one having AR9106+AR9160 and one > with an AR9382. > > ?2. It appears that it is always the same devices that this occurs for, > e.g. pretty confident there are some devices that I collected that I did > not see anything out of the 3-10dBm range > > I know 2.6.39 -> 3.1 is a bit of a jump, but I wanted to push this to > the community to see if there are some thoughts or opinions while I dig > deeper. My next step is to see if it occurs in 3.0 which should help > give me a narrow set of patches to review/bisect to see at what point > this was introduced. I would suspect it to be an initval issue, but the > two chips I have should have different initval sets. Any thoughts or > suggestions would be greatly appreciated. > > dps > > _______________________________________________ > ath9k-devel mailing list > ath9k-devel at lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel > -- shafi -------------- next part -------------- A non-text attachment was scrubbed... Name: print-rssi.patch Type: text/x-diff Size: 631 bytes Desc: not available Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20111104/2a7fa2e3/attachment.patch ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ath9k-devel] Unrealistic RSSI values being reported 2011-11-03 23:10 ` Mohammed Shafi @ 2011-11-04 11:27 ` Daniel Smith 2011-11-04 12:44 ` Mohammed Shafi 2011-11-23 6:06 ` Mohammed Shafi 2011-11-04 17:50 ` Daniel Smith 1 sibling, 2 replies; 16+ messages in thread From: Daniel Smith @ 2011-11-04 11:27 UTC (permalink / raw) To: ath9k-devel On 11/3/2011 7:10 PM, Mohammed Shafi wrote: > Hi Daniel, > > On Fri, Nov 4, 2011 at 12:58 AM, Daniel Smith<viscous.liquid@gmail.com> wrote: >> I recently upgraded to compat-wireless-3.1-rc8 from >> compat-wireless-2.6.39-1-sn and have discovered an interesting behavior. >> When in monitor mode I use the signal strength field reported in >> radiotap and with 3.1 I am now getting a range of values. The more >> interesting ones are all the frames reporting a signal of 110+ dBm. To >> see what is being pulled from the descriptors I dumped rs->rs_rssi to >> klog when the value was larger than 95. Below is a snippet showing the >> ranging values, > i tried with the AR9382 card in 3.1.0-wl with the attached debug > patch, can you please give a sample log with the patch applied and > putting the interface in monitor mode. did you print/check rs_rssi > somewhere else? > did you also try with the latest package > http://linuxwireless.org/download/compat-wireless-2.6/ First I apologize as I forgot to mention I am putting the channel into HT40 mode and the frames coming in are non-HT as that is the stated that the issue was reported to me. I have not ran test yet to see if it occurs with the channel in HT20 and non-ht mode. Also I have one more test to run on compat-wireless-3.0-2 but it looks like I am not seeing any issue with it. For reference here is the patch from my change, very similar to yours except that I didn't dump signal or noise. @@ -1015,6 +1015,8 @@ static int ath9k_rx_skb_preprocess(struct ath_common *common, rx_status->snr = rx_stats->rs_rssi; rx_status->antenna = rx_stats->rs_antenna; rx_status->flag |= RX_FLAG_MACTIME_MPDU; + if (rx_stats->rs_rssi > 95 || rx_stats->rs_rssi < 0) + printk("[ath9k]: RSSI %hhd\n", rx_stats->rs_rssi); return 0; } I will rerun it with your additions so you can see those values as well. Yes I can also test it with a nightly package to see if it has been resolved. Thanks for the Help! dps ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ath9k-devel] Unrealistic RSSI values being reported 2011-11-04 11:27 ` Daniel Smith @ 2011-11-04 12:44 ` Mohammed Shafi 2011-11-23 6:06 ` Mohammed Shafi 1 sibling, 0 replies; 16+ messages in thread From: Mohammed Shafi @ 2011-11-04 12:44 UTC (permalink / raw) To: ath9k-devel On Fri, Nov 4, 2011 at 4:57 PM, Daniel Smith <viscous.liquid@gmail.com> wrote: > On 11/3/2011 7:10 PM, Mohammed Shafi wrote: >> Hi Daniel, >> >> On Fri, Nov 4, 2011 at 12:58 AM, Daniel Smith<viscous.liquid@gmail.com> ?wrote: >>> I recently upgraded to compat-wireless-3.1-rc8 from >>> compat-wireless-2.6.39-1-sn and have discovered an interesting behavior. >>> When in monitor mode I use the signal strength field reported in >>> radiotap and with 3.1 I am now getting a range of values. The more >>> interesting ones are all the frames reporting a signal of 110+ dBm. To >>> see what is being pulled from the descriptors I dumped rs->rs_rssi to >>> klog when the value was larger than 95. Below is a snippet showing the >>> ranging values, >> i tried with the AR9382 card in 3.1.0-wl with the attached debug >> patch, can you please give a sample log with the patch applied and >> putting the interface in monitor mode. did you print/check rs_rssi >> somewhere else? >> did you also try with the latest package >> http://linuxwireless.org/download/compat-wireless-2.6/ > > First I apologize as I forgot to mention I am putting the channel into > HT40 mode and the frames coming in are non-HT as that is the stated that > the issue was reported to me. I have not ran test yet to see if it > occurs with the channel in HT20 and non-ht mode. Also I have one more > test to run on compat-wireless-3.0-2 but it looks like I am not seeing > any issue with it. > > For reference here is the patch from my change, very similar to yours > except that I didn't dump signal or noise. > > @@ -1015,6 +1015,8 @@ static int ath9k_rx_skb_preprocess(struct > ath_common *common, > ? ? ? ? rx_status->snr = rx_stats->rs_rssi; > ? ? ? ? rx_status->antenna = rx_stats->rs_antenna; > ? ? ? ? rx_status->flag |= RX_FLAG_MACTIME_MPDU; > + ? ? ? if (rx_stats->rs_rssi > 95 || rx_stats->rs_rssi < 0) > + ? ? ? ? ? ? ? printk("[ath9k]: RSSI %hhd\n", rx_stats->rs_rssi); hi Daniel, some values i got signal = noise + rs_rssi noise = -95 , rs_rssi = 55, signal = -40 rs_rssi has values like 65, 57, 52, 29, 53, 55, 21 , 35 , 50. sure values > 95 does not seems to occur for me. sure i can try with HT40 mode and put these prints will be out of station for 3 days, will try to debug once , hope some other developers might provide more inputs > > ? ? ? ? return 0; > ?} > > I will rerun it with your additions so you can see those values as well. > Yes I can also test it with a nightly package to see if it has been > resolved. > > Thanks for the Help! > > dps > > _______________________________________________ > ath9k-devel mailing list > ath9k-devel at lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel > -- shafi ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ath9k-devel] Unrealistic RSSI values being reported 2011-11-04 11:27 ` Daniel Smith 2011-11-04 12:44 ` Mohammed Shafi @ 2011-11-23 6:06 ` Mohammed Shafi 2011-11-23 14:08 ` Daniel Smith 1 sibling, 1 reply; 16+ messages in thread From: Mohammed Shafi @ 2011-11-23 6:06 UTC (permalink / raw) To: ath9k-devel On Fri, Nov 4, 2011 at 4:57 PM, Daniel Smith <viscous.liquid@gmail.com> wrote: > On 11/3/2011 7:10 PM, Mohammed Shafi wrote: >> Hi Daniel, >> >> On Fri, Nov 4, 2011 at 12:58 AM, Daniel Smith<viscous.liquid@gmail.com> ?wrote: >>> I recently upgraded to compat-wireless-3.1-rc8 from >>> compat-wireless-2.6.39-1-sn and have discovered an interesting behavior. >>> When in monitor mode I use the signal strength field reported in >>> radiotap and with 3.1 I am now getting a range of values. The more >>> interesting ones are all the frames reporting a signal of 110+ dBm. To >>> see what is being pulled from the descriptors I dumped rs->rs_rssi to >>> klog when the value was larger than 95. Below is a snippet showing the >>> ranging values, >> i tried with the AR9382 card in 3.1.0-wl with the attached debug >> patch, can you please give a sample log with the patch applied and >> putting the interface in monitor mode. did you print/check rs_rssi >> somewhere else? >> did you also try with the latest package >> http://linuxwireless.org/download/compat-wireless-2.6/ > > First I apologize as I forgot to mention I am putting the channel into > HT40 mode and the frames coming in are non-HT as that is the stated that > the issue was reported to me. I have not ran test yet to see if it > occurs with the channel in HT20 and non-ht mode. Also I have one more > test to run on compat-wireless-3.0-2 but it looks like I am not seeing > any issue with it. > > For reference here is the patch from my change, very similar to yours > except that I didn't dump signal or noise. > > @@ -1015,6 +1015,8 @@ static int ath9k_rx_skb_preprocess(struct > ath_common *common, > ? ? ? ? rx_status->snr = rx_stats->rs_rssi; > ? ? ? ? rx_status->antenna = rx_stats->rs_antenna; > ? ? ? ? rx_status->flag |= RX_FLAG_MACTIME_MPDU; > + ? ? ? if (rx_stats->rs_rssi > 95 || rx_stats->rs_rssi < 0) > + ? ? ? ? ? ? ? printk("[ath9k]: RSSI %hhd\n", rx_stats->rs_rssi); > > ? ? ? ? return 0; > ?} > > I will rerun it with your additions so you can see those values as well. > Yes I can also test it with a nightly package to see if it has been > resolved. Hi Daniel, sorry was busy with some other urgent work. a value upto 127 seems to be valid for Atheros chipsets, bad -128 http://en.wikipedia.org/wiki/Received_signal_strength_indication :) further the negative value should be caught by the check in ath9k_process_rssi unless my_beacon is 'false' hope i had not missed something. if (rx_stats->rs_rssi < 0) rx_stats->rs_rssi = 0; i will test this behavior and do further investigation. > > Thanks for the Help! > > dps > > _______________________________________________ > ath9k-devel mailing list > ath9k-devel at lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel > -- shafi ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ath9k-devel] Unrealistic RSSI values being reported 2011-11-23 6:06 ` Mohammed Shafi @ 2011-11-23 14:08 ` Daniel Smith 0 siblings, 0 replies; 16+ messages in thread From: Daniel Smith @ 2011-11-23 14:08 UTC (permalink / raw) To: ath9k-devel On 11/23/2011 1:06 AM, Mohammed Shafi wrote: > > Hi Daniel, > > sorry was busy with some other urgent work. a value upto 127 seems to > be valid for Atheros chipsets, bad -128 > http://en.wikipedia.org/wiki/Received_signal_strength_indication :) > further the negative value should be caught by the check in > ath9k_process_rssi unless my_beacon is 'false' hope i had not missed something. > > if (rx_stats->rs_rssi< 0) > rx_stats->rs_rssi = 0; > > i will test this behavior and do further investigation. > > Hey Shafi, No worries, I completely understand. So while 127 is a valid value for the chip, the reality is that it would not be (legally) possible. if the noise floor is -90dBm and the RSSI was 127 then the signal power at the antenna would have been 37dBm. Even if the TX antenna was right next to the RX antenna that would still be more powerful than what is legally allowed by the FCC. In this case the devices creating the offending traffic are Android smartphones (a HTC and a Motorola; based off of MAC), which typically have a max tx power around 15dBm, which again with a -90dBm noise floor would have a RSSI of 105 in a zero-loss free space. All those numbers are theoretical so for a baseline I set a Nokia N900 right next to the antenna (antenna is ~5' away and has a 6' coax whip) the largest signal strength (rssi + noise) I saw was -29dBm. For testing, take a look at the analysis that Adrian and I have been pursuing. It seems that the invalid RSSI occur for aggregate frames when there are still additional frames left in the aggregate, i.e. rs_isaggr and rs_moreaggr are both set. Thanks for taking some time to help look at this! Daniel ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ath9k-devel] Unrealistic RSSI values being reported 2011-11-03 23:10 ` Mohammed Shafi 2011-11-04 11:27 ` Daniel Smith @ 2011-11-04 17:50 ` Daniel Smith 2011-11-08 15:04 ` Mohammed Shafi 1 sibling, 1 reply; 16+ messages in thread From: Daniel Smith @ 2011-11-04 17:50 UTC (permalink / raw) To: ath9k-devel On 11/3/2011 7:10 PM, Mohammed Shafi wrote: > Hi Daniel, > > i tried with the AR9382 card in 3.1.0-wl with the attached debug > patch, can you please give a sample log with the patch applied and > putting the interface in monitor mode. did you print/check rs_rssi > somewhere else? > did you also try with the latest package > http://linuxwireless.org/download/compat-wireless-2.6/ > Alright, so I built compat-wireless-2011-11-03 (the latest when I looked this morning), although in klog it reported as compat-wireless-2011-10-14. Below are snippets from the logs. Some things I noticed is that for beacons and probes I am get acceptable values, but traffic(data) frames are the ones that have the unrealistic values,. Although if the AR9832 really had a RX sensitivity of -198dB, as it claims on one of the frames, we could set some serious distance records (^_^). Configuration commands, iw wlan9 set type monitor iw wlan9 set channel 4 HT40+ Version info: Nov 4 12:37:23 dpsmith-dev-system kernel: [83160.841129] Compat-wireless backport release: compat-wireless-2011-10-14 Nov 4 12:37:23 dpsmith-dev-system kernel: [83160.841138] Backport based on linux-next.git next-20111025 The AR9382 card: Nov 4 12:37:24 dpsmith-dev-system kernel: [83160.930301] ieee80211 phy0: Atheros AR9300 Rev:3 mem=0xfd7c0000, irq=16 Nov 4 12:37:24 dpsmith-dev-system kernel: [83160.930337] ath9k 0000:0c:08.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 The AR9160 card: Nov 4 12:37:25 dpsmith-dev-system kernel: [83162.531047] ieee80211 phy1: Atheros AR9160 MAC/BB Rev:1 AR5133 RF Rev:b0 mem=0xfd800000, irq=18 Nov 4 12:37:25 dpsmith-dev-system kernel: [83162.531072] ath9k 0000:0c:09.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 AR9160 beacons and probes, Nov 4 12:38:09 dpsmith-dev-system kernel: [83205.921245] noise = -88, rs_rssi = 43, signal =-45 Nov 4 12:38:09 dpsmith-dev-system kernel: [83206.023657] noise = -88, rs_rssi = 40, signal =-48 Nov 4 12:38:09 dpsmith-dev-system kernel: [83206.126067] noise = -88, rs_rssi = 40, signal =-48 Nov 4 12:38:09 dpsmith-dev-system kernel: [83206.161743] noise = -88, rs_rssi = 39, signal =-49 Nov 4 12:38:09 dpsmith-dev-system kernel: [83206.224044] noise = -88, rs_rssi = 41, signal =-47 Nov 4 12:38:09 dpsmith-dev-system kernel: [83206.224052] noise = -88, rs_rssi = 6, signal =-82 Nov 4 12:38:09 dpsmith-dev-system kernel: [83206.228482] noise = -88, rs_rssi = 39, signal =-49 Nov 4 12:38:09 dpsmith-dev-system kernel: [83206.330891] noise = -88, rs_rssi = 41, signal =-47 Nov 4 12:38:09 dpsmith-dev-system kernel: [83206.433304] noise = -88, rs_rssi = 41, signal =-47 Nov 4 12:38:09 dpsmith-dev-system kernel: [83206.535713] noise = -88, rs_rssi = 42, signal =-46 AR9160 large values (obtained with: cat kern.log-wlan9-11-03 |grep 'noise' | grep -v '=-'), Nov 4 12:48:44 dpsmith-dev-system kernel: [83841.704886] noise = -88, rs_rssi = 99, signal =11 Nov 4 12:48:44 dpsmith-dev-system kernel: [83841.707048] noise = -88, rs_rssi = 114, signal =26 Nov 4 12:48:44 dpsmith-dev-system kernel: [83841.707061] noise = -88, rs_rssi = 107, signal =19 Nov 4 12:48:44 dpsmith-dev-system kernel: [83841.713837] noise = -88, rs_rssi = 121, signal =33 Nov 4 12:48:44 dpsmith-dev-system kernel: [83841.800813] noise = -88, rs_rssi = 114, signal =26 Nov 4 12:48:44 dpsmith-dev-system kernel: [83841.800849] noise = -88, rs_rssi = 114, signal =26 Nov 4 12:48:44 dpsmith-dev-system kernel: [83841.803943] noise = -88, rs_rssi = 114, signal =26 Nov 4 12:48:44 dpsmith-dev-system kernel: [83841.812570] noise = -88, rs_rssi = 91, signal =3 Nov 4 12:48:44 dpsmith-dev-system kernel: [83841.833527] noise = -88, rs_rssi = 91, signal =3 Nov 4 12:48:44 dpsmith-dev-system kernel: [83841.852020] noise = -88, rs_rssi = 122, signal =34 Nov 4 12:48:44 dpsmith-dev-system kernel: [83841.867188] noise = -88, rs_rssi = 97, signal =9 Nov 4 12:48:44 dpsmith-dev-system kernel: [83841.883733] noise = -88, rs_rssi = 124, signal =36 Nov 4 12:48:44 dpsmith-dev-system kernel: [83841.887835] noise = -88, rs_rssi = 124, signal =36 Nov 4 12:48:45 dpsmith-dev-system kernel: [83842.222768] noise = -88, rs_rssi = -70, signal =-158 Nov 4 12:48:45 dpsmith-dev-system kernel: [83842.225734] noise = -88, rs_rssi = -57, signal =-145 Nov 4 12:48:45 dpsmith-dev-system kernel: [83842.225744] noise = -88, rs_rssi = -100, signal =-188 Nov 4 12:48:45 dpsmith-dev-system kernel: [83842.228756] noise = -88, rs_rssi = -41, signal =-129 Nov 4 12:48:45 dpsmith-dev-system kernel: [83842.228766] noise = -88, rs_rssi = -50, signal =-138 Nov 4 12:48:45 dpsmith-dev-system kernel: [83842.238307] noise = -88, rs_rssi = -59, signal =-147 Nov 4 12:48:45 dpsmith-dev-system kernel: [83842.238317] noise = -88, rs_rssi = -41, signal =-129 Nov 4 12:48:45 dpsmith-dev-system kernel: [83842.239728] noise = -88, rs_rssi = -80, signal =-168 Nov 4 12:48:45 dpsmith-dev-system kernel: [83842.349986] noise = -88, rs_rssi = -92, signal =-180 Nov 4 12:48:45 dpsmith-dev-system kernel: [83842.349999] noise = -88, rs_rssi = -92, signal =-180 Nov 4 12:48:45 dpsmith-dev-system kernel: [83842.350009] noise = -88, rs_rssi = -18, signal =-106 AR9382 beacons and probes, Nov 4 13:02:48 dpsmith-dev-system kernel: [84685.575367] noise = -95, rs_rssi = 28, signal =-67 Nov 4 13:02:48 dpsmith-dev-system kernel: [84685.577432] noise = -95, rs_rssi = 44, signal =-51 Nov 4 13:02:48 dpsmith-dev-system kernel: [84685.577445] noise = -95, rs_rssi = 48, signal =-47 Nov 4 13:02:48 dpsmith-dev-system kernel: [84685.578581] noise = -95, rs_rssi = 44, signal =-51 Nov 4 13:02:48 dpsmith-dev-system kernel: [84685.580742] noise = -95, rs_rssi = 45, signal =-50 Nov 4 13:02:48 dpsmith-dev-system kernel: [84685.580753] noise = -95, rs_rssi = 45, signal =-50 Nov 4 13:02:48 dpsmith-dev-system kernel: [84685.581369] noise = -95, rs_rssi = 47, signal =-48 Nov 4 13:02:48 dpsmith-dev-system kernel: [84685.582133] noise = -95, rs_rssi = 48, signal =-47 Nov 4 13:02:48 dpsmith-dev-system kernel: [84685.582771] noise = -95, rs_rssi = 48, signal =-47 Nov 4 13:02:48 dpsmith-dev-system kernel: [84685.582780] noise = -95, rs_rssi = 28, signal =-67 Nov 4 13:02:48 dpsmith-dev-system kernel: [84685.582788] noise = -95, rs_rssi = 49, signal =-46 AR9382 large values, Nov 4 13:02:49 dpsmith-dev-system kernel: [84686.866417] noise = -95, rs_rssi = 117, signal =22 Nov 4 13:02:49 dpsmith-dev-system kernel: [84686.867481] noise = -95, rs_rssi = 100, signal =5 Nov 4 13:02:50 dpsmith-dev-system kernel: [84687.056185] noise = -95, rs_rssi = 108, signal =13 Nov 4 13:02:51 dpsmith-dev-system kernel: [84688.101812] noise = -95, rs_rssi = 121, signal =26 Nov 4 13:02:51 dpsmith-dev-system kernel: [84688.184731] noise = -95, rs_rssi = 118, signal =23 Nov 4 13:02:53 dpsmith-dev-system kernel: [84690.676674] noise = -95, rs_rssi = 116, signal =21 Nov 4 13:02:58 dpsmith-dev-system kernel: [84695.616568] noise = -95, rs_rssi = 120, signal =25 Nov 4 13:02:58 dpsmith-dev-system kernel: [84695.616578] noise = -95, rs_rssi = 102, signal =7 Nov 4 13:02:58 dpsmith-dev-system kernel: [84695.737242] noise = -95, rs_rssi = 106, signal =11 Nov 4 13:02:58 dpsmith-dev-system kernel: [84695.741015] noise = -95, rs_rssi = 109, signal =14 Nov 4 13:06:39 dpsmith-dev-system kernel: [84916.016861] noise = -95, rs_rssi = -103, signal =-198 Nov 4 13:06:39 dpsmith-dev-system kernel: [84916.017702] noise = -95, rs_rssi = -6, signal =-101 Nov 4 13:06:39 dpsmith-dev-system kernel: [84916.437538] noise = -95, rs_rssi = -91, signal =-186 Nov 4 13:06:39 dpsmith-dev-system kernel: [84916.443453] noise = -95, rs_rssi = -47, signal =-142 Nov 4 13:06:39 dpsmith-dev-system kernel: [84916.444890] noise = -95, rs_rssi = -59, signal =-154 Nov 4 13:06:39 dpsmith-dev-system kernel: [84916.446049] noise = -95, rs_rssi = -94, signal =-189 Nov 4 13:06:39 dpsmith-dev-system kernel: [84916.447909] noise = -95, rs_rssi = -22, signal =-117 Nov 4 13:06:39 dpsmith-dev-system kernel: [84916.452528] noise = -95, rs_rssi = -55, signal =-150 Nov 4 13:06:39 dpsmith-dev-system kernel: [84916.813274] noise = -95, rs_rssi = -43, signal =-138 v/r, dps ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ath9k-devel] Unrealistic RSSI values being reported 2011-11-04 17:50 ` Daniel Smith @ 2011-11-08 15:04 ` Mohammed Shafi 2011-11-21 17:35 ` Daniel Smith 0 siblings, 1 reply; 16+ messages in thread From: Mohammed Shafi @ 2011-11-08 15:04 UTC (permalink / raw) To: ath9k-devel On Fri, Nov 4, 2011 at 11:20 PM, Daniel Smith <viscous.liquid@gmail.com> wrote: > On 11/3/2011 7:10 PM, Mohammed Shafi wrote: >> Hi Daniel, >> >> i tried with the AR9382 card in 3.1.0-wl with the attached debug >> patch, can you please give a sample log with the patch applied and >> putting the interface in monitor mode. did you print/check rs_rssi >> somewhere else? >> did you also try with the latest package >> http://linuxwireless.org/download/compat-wireless-2.6/ >> > > Alright, so I built compat-wireless-2011-11-03 (the latest when I looked > this morning), although in klog it reported as > compat-wireless-2011-10-14. Below are snippets from the logs. Some > things I noticed is that for beacons and probes I am get acceptable > values, but traffic(data) frames are the ones that have the unrealistic > values,. Although if the AR9832 really had a RX sensitivity of -198dB, > as it claims on one of the frames, we could set some serious distance > records (^_^). > > Configuration commands, > iw wlan9 set type monitor > iw wlan9 set channel 4 HT40+ > > Version info: > Nov ?4 12:37:23 dpsmith-dev-system kernel: [83160.841129] > Compat-wireless backport release: compat-wireless-2011-10-14 > Nov ?4 12:37:23 dpsmith-dev-system kernel: [83160.841138] Backport based > on linux-next.git next-20111025 > > > The AR9382 card: > Nov ?4 12:37:24 dpsmith-dev-system kernel: [83160.930301] ieee80211 > phy0: Atheros AR9300 Rev:3 mem=0xfd7c0000, irq=16 > Nov ?4 12:37:24 dpsmith-dev-system kernel: [83160.930337] ath9k > 0000:0c:08.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 > > > The AR9160 card: > Nov ?4 12:37:25 dpsmith-dev-system kernel: [83162.531047] ieee80211 > phy1: Atheros AR9160 MAC/BB Rev:1 AR5133 RF Rev:b0 mem=0xfd800000, irq=18 > Nov ?4 12:37:25 dpsmith-dev-system kernel: [83162.531072] ath9k > 0000:0c:09.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 > > > AR9160 beacons and probes, > Nov ?4 12:38:09 dpsmith-dev-system kernel: [83205.921245] noise = -88, > rs_rssi = 43, signal =-45 > Nov ?4 12:38:09 dpsmith-dev-system kernel: [83206.023657] noise = -88, > rs_rssi = 40, signal =-48 > Nov ?4 12:38:09 dpsmith-dev-system kernel: [83206.126067] noise = -88, > rs_rssi = 40, signal =-48 > Nov ?4 12:38:09 dpsmith-dev-system kernel: [83206.161743] noise = -88, > rs_rssi = 39, signal =-49 > Nov ?4 12:38:09 dpsmith-dev-system kernel: [83206.224044] noise = -88, > rs_rssi = 41, signal =-47 > Nov ?4 12:38:09 dpsmith-dev-system kernel: [83206.224052] noise = -88, > rs_rssi = 6, signal =-82 > Nov ?4 12:38:09 dpsmith-dev-system kernel: [83206.228482] noise = -88, > rs_rssi = 39, signal =-49 > Nov ?4 12:38:09 dpsmith-dev-system kernel: [83206.330891] noise = -88, > rs_rssi = 41, signal =-47 > Nov ?4 12:38:09 dpsmith-dev-system kernel: [83206.433304] noise = -88, > rs_rssi = 41, signal =-47 > Nov ?4 12:38:09 dpsmith-dev-system kernel: [83206.535713] noise = -88, > rs_rssi = 42, signal =-46 > > > AR9160 large values (obtained with: cat kern.log-wlan9-11-03 |grep > 'noise' | grep -v '=-'), > Nov ?4 12:48:44 dpsmith-dev-system kernel: [83841.704886] noise = -88, > rs_rssi = 99, signal =11 > Nov ?4 12:48:44 dpsmith-dev-system kernel: [83841.707048] noise = -88, > rs_rssi = 114, signal =26 > Nov ?4 12:48:44 dpsmith-dev-system kernel: [83841.707061] noise = -88, > rs_rssi = 107, signal =19 > Nov ?4 12:48:44 dpsmith-dev-system kernel: [83841.713837] noise = -88, > rs_rssi = 121, signal =33 > Nov ?4 12:48:44 dpsmith-dev-system kernel: [83841.800813] noise = -88, > rs_rssi = 114, signal =26 > Nov ?4 12:48:44 dpsmith-dev-system kernel: [83841.800849] noise = -88, > rs_rssi = 114, signal =26 > Nov ?4 12:48:44 dpsmith-dev-system kernel: [83841.803943] noise = -88, > rs_rssi = 114, signal =26 > Nov ?4 12:48:44 dpsmith-dev-system kernel: [83841.812570] noise = -88, > rs_rssi = 91, signal =3 > Nov ?4 12:48:44 dpsmith-dev-system kernel: [83841.833527] noise = -88, > rs_rssi = 91, signal =3 > Nov ?4 12:48:44 dpsmith-dev-system kernel: [83841.852020] noise = -88, > rs_rssi = 122, signal =34 > Nov ?4 12:48:44 dpsmith-dev-system kernel: [83841.867188] noise = -88, > rs_rssi = 97, signal =9 > Nov ?4 12:48:44 dpsmith-dev-system kernel: [83841.883733] noise = -88, > rs_rssi = 124, signal =36 > Nov ?4 12:48:44 dpsmith-dev-system kernel: [83841.887835] noise = -88, > rs_rssi = 124, signal =36 > > Nov ?4 12:48:45 dpsmith-dev-system kernel: [83842.222768] noise = -88, > rs_rssi = -70, signal =-158 > Nov ?4 12:48:45 dpsmith-dev-system kernel: [83842.225734] noise = -88, > rs_rssi = -57, signal =-145 > Nov ?4 12:48:45 dpsmith-dev-system kernel: [83842.225744] noise = -88, > rs_rssi = -100, signal =-188 > Nov ?4 12:48:45 dpsmith-dev-system kernel: [83842.228756] noise = -88, > rs_rssi = -41, signal =-129 > Nov ?4 12:48:45 dpsmith-dev-system kernel: [83842.228766] noise = -88, > rs_rssi = -50, signal =-138 > Nov ?4 12:48:45 dpsmith-dev-system kernel: [83842.238307] noise = -88, > rs_rssi = -59, signal =-147 > Nov ?4 12:48:45 dpsmith-dev-system kernel: [83842.238317] noise = -88, > rs_rssi = -41, signal =-129 > Nov ?4 12:48:45 dpsmith-dev-system kernel: [83842.239728] noise = -88, > rs_rssi = -80, signal =-168 > Nov ?4 12:48:45 dpsmith-dev-system kernel: [83842.349986] noise = -88, > rs_rssi = -92, signal =-180 > Nov ?4 12:48:45 dpsmith-dev-system kernel: [83842.349999] noise = -88, > rs_rssi = -92, signal =-180 > Nov ?4 12:48:45 dpsmith-dev-system kernel: [83842.350009] noise = -88, > rs_rssi = -18, signal =-106 > > > AR9382 beacons and probes, > Nov ?4 13:02:48 dpsmith-dev-system kernel: [84685.575367] noise = -95, > rs_rssi = 28, signal =-67 > Nov ?4 13:02:48 dpsmith-dev-system kernel: [84685.577432] noise = -95, > rs_rssi = 44, signal =-51 > Nov ?4 13:02:48 dpsmith-dev-system kernel: [84685.577445] noise = -95, > rs_rssi = 48, signal =-47 > Nov ?4 13:02:48 dpsmith-dev-system kernel: [84685.578581] noise = -95, > rs_rssi = 44, signal =-51 > Nov ?4 13:02:48 dpsmith-dev-system kernel: [84685.580742] noise = -95, > rs_rssi = 45, signal =-50 > Nov ?4 13:02:48 dpsmith-dev-system kernel: [84685.580753] noise = -95, > rs_rssi = 45, signal =-50 > Nov ?4 13:02:48 dpsmith-dev-system kernel: [84685.581369] noise = -95, > rs_rssi = 47, signal =-48 > Nov ?4 13:02:48 dpsmith-dev-system kernel: [84685.582133] noise = -95, > rs_rssi = 48, signal =-47 > Nov ?4 13:02:48 dpsmith-dev-system kernel: [84685.582771] noise = -95, > rs_rssi = 48, signal =-47 > Nov ?4 13:02:48 dpsmith-dev-system kernel: [84685.582780] noise = -95, > rs_rssi = 28, signal =-67 > Nov ?4 13:02:48 dpsmith-dev-system kernel: [84685.582788] noise = -95, > rs_rssi = 49, signal =-46 > > > AR9382 large values, > Nov ?4 13:02:49 dpsmith-dev-system kernel: [84686.866417] noise = -95, > rs_rssi = 117, signal =22 > Nov ?4 13:02:49 dpsmith-dev-system kernel: [84686.867481] noise = -95, > rs_rssi = 100, signal =5 > Nov ?4 13:02:50 dpsmith-dev-system kernel: [84687.056185] noise = -95, > rs_rssi = 108, signal =13 > Nov ?4 13:02:51 dpsmith-dev-system kernel: [84688.101812] noise = -95, > rs_rssi = 121, signal =26 > Nov ?4 13:02:51 dpsmith-dev-system kernel: [84688.184731] noise = -95, > rs_rssi = 118, signal =23 > Nov ?4 13:02:53 dpsmith-dev-system kernel: [84690.676674] noise = -95, > rs_rssi = 116, signal =21 > Nov ?4 13:02:58 dpsmith-dev-system kernel: [84695.616568] noise = -95, > rs_rssi = 120, signal =25 > Nov ?4 13:02:58 dpsmith-dev-system kernel: [84695.616578] noise = -95, > rs_rssi = 102, signal =7 > Nov ?4 13:02:58 dpsmith-dev-system kernel: [84695.737242] noise = -95, > rs_rssi = 106, signal =11 > Nov ?4 13:02:58 dpsmith-dev-system kernel: [84695.741015] noise = -95, > rs_rssi = 109, signal =14 > > Nov ?4 13:06:39 dpsmith-dev-system kernel: [84916.016861] noise = -95, > rs_rssi = -103, signal =-198 > Nov ?4 13:06:39 dpsmith-dev-system kernel: [84916.017702] noise = -95, > rs_rssi = -6, signal =-101 > Nov ?4 13:06:39 dpsmith-dev-system kernel: [84916.437538] noise = -95, > rs_rssi = -91, signal =-186 > Nov ?4 13:06:39 dpsmith-dev-system kernel: [84916.443453] noise = -95, > rs_rssi = -47, signal =-142 > Nov ?4 13:06:39 dpsmith-dev-system kernel: [84916.444890] noise = -95, > rs_rssi = -59, signal =-154 > Nov ?4 13:06:39 dpsmith-dev-system kernel: [84916.446049] noise = -95, > rs_rssi = -94, signal =-189 > Nov ?4 13:06:39 dpsmith-dev-system kernel: [84916.447909] noise = -95, > rs_rssi = -22, signal =-117 > Nov ?4 13:06:39 dpsmith-dev-system kernel: [84916.452528] noise = -95, > rs_rssi = -55, signal =-150 > Nov ?4 13:06:39 dpsmith-dev-system kernel: [84916.813274] noise = -95, > rs_rssi = -43, signal =-138 > Daniel, thanks for the detail info. i will just do this. run a ping traffic betweem some AP and another card say AR9280 and sniff those data packets in my AR9382 to recreate what you are saying. > v/r, > dps > > _______________________________________________ > ath9k-devel mailing list > ath9k-devel at lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel > -- shafi ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ath9k-devel] Unrealistic RSSI values being reported 2011-11-08 15:04 ` Mohammed Shafi @ 2011-11-21 17:35 ` Daniel Smith 2011-11-21 20:09 ` Adrian Chadd 0 siblings, 1 reply; 16+ messages in thread From: Daniel Smith @ 2011-11-21 17:35 UTC (permalink / raw) To: ath9k-devel Just wanted to follow-up to let everyone know the status and for anyone people that may stumble on this from a search. Also, I have a pcap file from one of the captures done with 2.6.39-1-sn if anyone wants to inspect the frames themselves, just email me directly if would like it. Some observations made in limited testing across various version of compat-wireless. * found that 2.6.39-1-sn exhibited the same behavior * it always seemed that it was HT traffic that this would occur with * tested an 802.11g client right next to the collection antenna, no frames from that client would trigger an invalid value * it was always the same two devices, an HTC phone and a Motorola phone * found that the per chain RSSIs were always valid even when the combined RSSI was not * when the combined RSSI was valid and not equal to the max per chain RSSI, it was typically was 7 dB or less So with 2.6.39 demonstrating the behavior as well I did not want to expend the effort to find a version that this bug did not occur in to do a bisect. To that end I incorporated a fix-up/work-around/hack to attempt to detect when a bad combined RSSI, and if so then substitute in the max per chain RSSI. @@ -566,9 +566,20 @@ EXPORT_SYMBOL(ath9k_hw_resettxqueue); int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc *ds, struct ath_rx_status *rs, u64 tsf) { +/* shamelessly stole from linux.h */ +#define max3(x, y, z) ({ \ + typeof(x) _max1 = (x); \ + typeof(y) _max2 = (y); \ + typeof(z) _max3 = (z); \ + (void) (&_max1 == &_max2); \ + (void) (&_max1 == &_max3); \ + _max1 > _max2 ? (_max1 > _max3 ? _max1 : _max3) : \ + (_max2 > _max3 ? _max2 : _max3); }) + struct ar5416_desc ads; struct ar5416_desc *adsp = AR5416DESC(ds); u32 phyerr; + int8_t max_rssi; if ((adsp->ds_rxstatus8 & AR_RxDone) == 0) return -EINPROGRESS; @@ -604,6 +615,9 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc *ds, rs->rs_rssi_ext2 = MS(ads.ds_rxstatus4, AR_RxRSSIAnt12); } + max_rssi = max3(rs->rs_rssi_ctl0,rs->rs_rssi_ctl1,rs->rs_rssi_ctl2); + if (unlikely( abs(rs->rs_rssi - max_rssi) > 10)) + rs->rs_rssi = max_rssi; if (ads.ds_rxstatus8 & AR_RxKeyIdxValid) rs->rs_keyix = MS(ads.ds_rxstatus8, AR_KeyIdx); else @@ -650,6 +664,7 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc *ds, } return 0; +#undef max3 } EXPORT_SYMBOL(ath9k_hw_rxprocdesc); ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ath9k-devel] Unrealistic RSSI values being reported 2011-11-21 17:35 ` Daniel Smith @ 2011-11-21 20:09 ` Adrian Chadd 2011-11-22 17:42 ` Daniel Smith 0 siblings, 1 reply; 16+ messages in thread From: Adrian Chadd @ 2011-11-21 20:09 UTC (permalink / raw) To: ath9k-devel Hi, See if those valid or invalid RSSI's coincide with aggregate frames. ath9k_process_rssi() has a bit of logic which only considers frames that aren't part of continuing aggregate: if (rx_stats->rs_rssi != ATH9K_RSSI_BAD && !rx_stats->rs_moreaggr) ATH_RSSI_LPF(sc->last_rssi, rx_stats->rs_rssi); .. ie, rs_moreaggr is set if the frame is part of an aggregate, clear if it's not an aggregate or is the last frame in an aggregate. Adrian ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ath9k-devel] Unrealistic RSSI values being reported 2011-11-21 20:09 ` Adrian Chadd @ 2011-11-22 17:42 ` Daniel Smith 2011-11-22 23:05 ` Adrian Chadd 0 siblings, 1 reply; 16+ messages in thread From: Daniel Smith @ 2011-11-22 17:42 UTC (permalink / raw) To: ath9k-devel On 11/21/2011 3:09 PM, Adrian Chadd wrote: > Hi, > > See if those valid or invalid RSSI's coincide with aggregate frames. > > ath9k_process_rssi() has a bit of logic which only considers frames > that aren't part of continuing aggregate: > > if (rx_stats->rs_rssi != ATH9K_RSSI_BAD&& !rx_stats->rs_moreaggr) > ATH_RSSI_LPF(sc->last_rssi, rx_stats->rs_rssi); > > .. ie, rs_moreaggr is set if the frame is part of an aggregate, clear > if it's not an aggregate or is the last frame in an aggregate. > > > Adrian Hey Adrian! Excellent call! So in mac.c:ath9k_hw_rxprocdesc() I put a three printk (in the following order) for when I detect the out-of-bounds rssi, an aggregate, and if there is more to the aggregate. As you can see below when my check is triggered on aggregate frames only. Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.298868] [ath9k] frame is aggr: false Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.300420] [ath9k] overriding RSSI Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.300422] [ath9k] frame is aggr: true Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.300426] [ath9k] frame has more aggr: true Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.300433] [ath9k] overriding RSSI Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.300435] [ath9k] frame is aggr: true Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.300439] [ath9k] frame has more aggr: true Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.300444] [ath9k] overriding RSSI Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.300446] [ath9k] frame is aggr: true Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.300450] [ath9k] frame has more aggr: true Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.300456] [ath9k] frame is aggr: true Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.300460] [ath9k] frame has more aggr: true Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.302637] [ath9k] overriding RSSI Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.302641] [ath9k] frame is aggr: true Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.302645] [ath9k] frame has more aggr: true Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.302654] [ath9k] overriding RSSI Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.302657] [ath9k] frame is aggr: true Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.302662] [ath9k] frame has more aggr: true Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.302670] [ath9k] overriding RSSI Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.302674] [ath9k] frame is aggr: true Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.302679] [ath9k] frame has more aggr: true Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.302687] [ath9k] frame is aggr: true Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.302692] [ath9k] frame has more aggr: true Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.302700] [ath9k] frame is aggr: false Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.302707] [ath9k] frame is aggr: false Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.302714] [ath9k] overriding RSSI Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.302717] [ath9k] frame is aggr: true Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.302722] [ath9k] frame has more aggr: true Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.304683] [ath9k] overriding RSSI Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.304686] [ath9k] frame is aggr: true Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.304689] [ath9k] frame has more aggr: true Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.304696] [ath9k] overriding RSSI Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.304698] [ath9k] frame is aggr: true Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.304701] [ath9k] frame has more aggr: true Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.304707] [ath9k] frame is aggr: true Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.304710] [ath9k] frame has more aggr: true Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.304716] [ath9k] frame is aggr: false To verify that it was only tripped on aggregate frames, $ grep -A 1 overriding /var/log/kern.log|grep -B 1 false Nov 22 08:09:09 dpsmith-dev-system kernel: [342641.360141] [ath9k] overriding RSSI Nov 22 08:09:09 dpsmith-dev-system kernel: [342641.360145] [ath9k] frame is aggr: false -- Nov 22 08:14:53 dpsmith-dev-system kernel: [342985.292829] [ath9k] overriding RSSI Nov 22 08:14:53 dpsmith-dev-system kernel: [342985.292834] [ath9k] frame is aggr: false -- Nov 22 08:21:23 dpsmith-dev-system kernel: [343375.366725] [ath9k] overriding RSSI Nov 22 08:21:23 dpsmith-dev-system kernel: [343375.366729] [ath9k] frame is aggr: false -- Nov 22 12:25:06 dpsmith-dev-system kernel: [357998.381999] [ath9k] overriding RSSI Nov 22 12:25:06 dpsmith-dev-system kernel: [357998.382004] [ath9k] frame is aggr: false I did not print the combined and max RSSI, but I think these four are anomalies where abs(combined - max) was slightly over 10. Which probably was valid as 10 was chosen as a guesstimate more than a scientifically proven value. So the question I have is that, is there a reason not to run ath9k_process_rssi on frames from a monitor interface? From what I read of that function as long as last_rssi != ATH_RSSI_DUMMY_MARKER then rs->rs_rssi will get set to last_rssi, which gets recalculated just before one of these incidents. Thanks for the help! Daniel ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ath9k-devel] Unrealistic RSSI values being reported 2011-11-22 17:42 ` Daniel Smith @ 2011-11-22 23:05 ` Adrian Chadd 2011-11-23 13:44 ` Daniel Smith 0 siblings, 1 reply; 16+ messages in thread From: Adrian Chadd @ 2011-11-22 23:05 UTC (permalink / raw) To: ath9k-devel On 23 November 2011 01:42, Daniel Smith <viscous.liquid@gmail.com> wrote: > Excellent call! So in mac.c:ath9k_hw_rxprocdesc() I put a three printk > (in the following order) for when I detect the out-of-bounds rssi, an > aggregate, and if there is more to the aggregate. As you can see below > when my check is triggered on aggregate frames only. Ok. Does it trigger on aggregation frames w/ more, or not w/ more, or both? adrian ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ath9k-devel] Unrealistic RSSI values being reported 2011-11-22 23:05 ` Adrian Chadd @ 2011-11-23 13:44 ` Daniel Smith 2011-11-23 14:14 ` Adrian Chadd 0 siblings, 1 reply; 16+ messages in thread From: Daniel Smith @ 2011-11-23 13:44 UTC (permalink / raw) To: ath9k-devel On 11/22/2011 6:05 PM, Adrian Chadd wrote: > > Ok. Does it trigger on aggregation frames w/ more, or not w/ more, or both? > > > > adrian So here is the observed patterns, * When the RSSI override is triggered, rs_isaggr and rs_moreaggr is set(true) * When rs_isaggr and rs_moreaggr is set, overwhelmingly of those had the RSSI overridden but there were a few that were not * When rs_isaggr is set and rs_moreaggr is not set, the RSSI was never overridden. Based on this and thinking about how ath9k_process_rssi works I don't see any other way but to leave my fix-up. The alternative would be in user-space I will have to remember that the signal strength for an aggregate series will come from the last frame in the aggregate. Is there another way that I am not thinking of? Daniel ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ath9k-devel] Unrealistic RSSI values being reported 2011-11-23 13:44 ` Daniel Smith @ 2011-11-23 14:14 ` Adrian Chadd 2011-11-23 14:24 ` Felix Fietkau 0 siblings, 1 reply; 16+ messages in thread From: Adrian Chadd @ 2011-11-23 14:14 UTC (permalink / raw) To: ath9k-devel Ok, cool. So I was right. :) Yes, the nice solution would be to expose those aggregate frame boundary delimiters to userland and then only marking those frames with valid RSSI .. well, somehow. The nicer solution would be to buffer those frames in an aggregate and then assign them all a common RSSI. But ew. Adrian ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ath9k-devel] Unrealistic RSSI values being reported 2011-11-23 14:14 ` Adrian Chadd @ 2011-11-23 14:24 ` Felix Fietkau 2011-11-23 15:18 ` Daniel Smith 0 siblings, 1 reply; 16+ messages in thread From: Felix Fietkau @ 2011-11-23 14:24 UTC (permalink / raw) To: ath9k-devel On 2011-11-23 9:14 PM, Adrian Chadd wrote: > Ok, cool. So I was right. :) > > Yes, the nice solution would be to expose those aggregate frame > boundary delimiters to userland and then only marking those frames > with valid RSSI .. well, somehow. > > The nicer solution would be to buffer those frames in an aggregate and > then assign them all a common RSSI. But ew. No need to buffer them in the driver, just do a lookahead on the DMA ring. If necessary, defer processing until the last part of the aggregate has been completed. - Felix ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ath9k-devel] Unrealistic RSSI values being reported 2011-11-23 14:24 ` Felix Fietkau @ 2011-11-23 15:18 ` Daniel Smith 0 siblings, 0 replies; 16+ messages in thread From: Daniel Smith @ 2011-11-23 15:18 UTC (permalink / raw) To: ath9k-devel On Wed, Nov 23, 2011 at 9:24 AM, Felix Fietkau <nbd@openwrt.org> wrote: > On 2011-11-23 9:14 PM, Adrian Chadd wrote: >> Ok, cool. So I was right. :) >> >> Yes, the nice solution would be to expose those aggregate frame >> boundary delimiters to userland and then only marking those frames >> with valid RSSI .. well, somehow. >> >> The nicer solution would be to buffer those frames in an aggregate and >> then assign them all a common RSSI. But ew. > No need to buffer them in the driver, just do a lookahead on the DMA > ring. If necessary, defer processing until the last part of the > aggregate has been completed. > > - Felix Adrian, Yes you were right, excellent call on your part. m(_ _)m Felix, I think the former would be more straight forward. The question I have is what is the cost/benefit of doing either. I think the situation is a rare corner case that only affects the unique solution I support. The main thing for me is that I now know it is just the way the hardware handles aggregates and not something that is caused by the driver. So for me i don't think the benefit of doing a look ahead, ensure AR_RxDone for the frame and then peak at the rssi versus just doing a max3 and a small comparison to get a close approximation is worth the cost of coding and a possible increased delay in processing frames. Perhaps there is a more elegant way for the former, but I am still not certain if the effort to code it is worth the reward of an rssi that may or may not be any more accurate then the max of the individual chains. But hey, I am willing to be convince otherwise. Thanks for all the help, it is much appreciated. Daniel ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2011-11-23 15:18 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-11-03 19:28 [ath9k-devel] Unrealistic RSSI values being reported Daniel Smith 2011-11-03 23:10 ` Mohammed Shafi 2011-11-04 11:27 ` Daniel Smith 2011-11-04 12:44 ` Mohammed Shafi 2011-11-23 6:06 ` Mohammed Shafi 2011-11-23 14:08 ` Daniel Smith 2011-11-04 17:50 ` Daniel Smith 2011-11-08 15:04 ` Mohammed Shafi 2011-11-21 17:35 ` Daniel Smith 2011-11-21 20:09 ` Adrian Chadd 2011-11-22 17:42 ` Daniel Smith 2011-11-22 23:05 ` Adrian Chadd 2011-11-23 13:44 ` Daniel Smith 2011-11-23 14:14 ` Adrian Chadd 2011-11-23 14:24 ` Felix Fietkau 2011-11-23 15:18 ` Daniel Smith
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.