[ath9k-devel] unknown phase offset added to CSI measurement at 2.4 GHz?
It is not directly related with ath9k, but with Intel 5300 NIC. In https://github.com/dhalperi/linux-80211n-csitool-supplementary/issues/6, dhalperi says: > On 2.4 GHz bands, it appears that each antenna experiences an unknown phase shift by a multiple of π/2 (or 90 degrees). This is probably what you're seeing? > If I recall correctly, this effect does not show up at 5 GHz(*). So if you do your experiments in that band, you may not have this problem. > (*) Manikanta Kotaru from Stanford pointed out that this effect disappears on 5 GHz, and pointed at Section 3 in Jon Gjengset, Graeme McPhillips, and Kyle Jamieson's ArrayPhaser (@jonhoo's) paper as evidence. I wonder whether it applies to all 2.4 GHz devices, which means it is not a manufacturer-specific problem. Or, is it a manufacturer(Intel)-specific problem, so thus ath9k does not suffer such problem? Or even worse, will ath9k suffer such problem at both 2.4 GHz and 5 GHz? Regards, Jeon. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] linearity of ath9k CSI phase
Dear Joe Ayers Thanks for your response again. I started studying and investigating on antennas theories. Regards, Jeon. 2016-06-14 14:19 GMT+09:00 Joe Ayers : > This increased spacing looks to impact the detection angle before aliasing > occurs with grating lobes. Google around, but looks like 1/2 wave length > spacing gives full +/-90 deg. Going up to 1 wave length spacing reduces > the detection angle to +/-30 deg before aliasing. > > > > On Mon, Jun 13, 2016 at 8:39 PM, Jeon wrote: > >> Dear Joe Ayers, >> Thank you for response. >> >> I don't have a sort of RF anechoic chamber. So, I've captured CSI in a >> quite realistic and practical environemnt with possible interference and >> multipath components. There are other WLAN APs, Bluetooth devices. Also, >> there exist desks, chairs and walls as reflectors. >> >> Yet, I don't think it does matter to capture CSI and estimate true phase. >> My attempts are based on a couple of papers which have done estimating true >> phase and AoA of a signal with uniform linear antenna array (ULA) in a >> realistic and practical living environment [1, 2, 3]. Which means, those >> papers claim that they can identify directpath component and multipath >> components with MUSIC algorithm [4]. >> >> One suspicious thing is, I think distance between antennas of ULA is >> misconfigured. I placed them 6.5 cm apart from each other. With >> calculation, a half of wavelength at 2.4 GHz band is less than 6.25 cm. >> Does it matter a lot? >> >> Regards, >> Jeon. >> >> [1]: K. Qian, C. Wu, Z. Yang, Y. Liu, and Z. Zhou, “PADS: Passive >> detection of moving targets with dynamic speed using PHY layer >> information,” in 2014 20th IEEE International Conference on Parallel and >> Distributed Systems (ICPADS), 2014, pp. 1–8. >> [2]: J. Xiong and K. Jamieson, “ArrayTrack: A Fine-Grained Indoor >> Location System,” in Presented as part of the 10th USENIX Symposium on >> Networked Systems Design and Implementation (NSDI 13), Lombard, IL, 2013, >> pp. 71–84. >> [3]: M. Kotaru, K. Joshi, D. Bharadia, and S. Katti, “SpotFi: Decimeter >> Level Localization Using WiFi,” SIGCOMM Comput. Commun. Rev., vol. 45, no. >> 4, pp. 269–282, Aug. 2015. >> [4]: R. Schmidt, “Multiple emitter location and signal parameter >> estimation,” IEEE Transactions on Antennas and Propagation, vol. 34, no. 3, >> pp. 276–280, Mar. 1986. >> >> 2016-06-14 3:28 GMT+09:00 Joe Ayers : >> >>> Jeon, >>> >>> "only constant offset across subcarrier seems to be effective".Could >>> this be because there's not just one signal being received anymore, rather >>> with microwaves, particularly with lots of nearby reflection surfaces, >>> there's now ~10 signals bouncing in to the receive antenna at 10 >>> AoA's--some with 2x the distance-delay traveled--and resonance/nulls >>> occurring? How perfect is your test environment? >>> >>> Joe AE6XE >>> >>> On Mon, Jun 13, 2016 at 10:00 AM, Jeon wrote: >>> Dear ath9k developers, I am currently working with Atheros CSI Extraction Tool [1] to get a true phase of each subcarrier. - Background [2], [3] and many other papers claim that phase information from extracted CSI contains two components: true phase and unwanted phase offset due to subcarrier and time delay. i.e., measured_phase = true_phase + time_delay * subcarrier_index + phase_offset_due_to_txrx_mismatch This equation can be visualized as below: http://i.imgur.com/rk9Hh1M.png (Please note that this figure is based on CSI tool for Intel 5300 NIC.) It contains unwanted linear phase offset and constant phase offset. Since the true phase is relatively small, it seems that phase is monotonically increasing or decreasing in macro view due to the unwanted phase offsets. We cannot see a tiny true phase currently. To remove phase offset due to subcarrier, the mentioned papers are attempting to remove it with linear fitting ax + b, where a = slope of the figure, b = average of measured phase, and x = subcarrier index. After removing unwanted phase offset components, the true phase is estimated. This estimated true phase seems steady and consistent across a time duration shorter than < 100 - 1000 ms: http://i.imgur.com/AO89vYV.png Note that Y-axis scale is reduece from [-50, 10] to [5, -3] - My question I want to extract and manipulate CSI phase WITH ATH9K NIC. After extracting CSI from my ath9k NIC (AR9580 @ 2.4 GHz) with Atheros CSI extraction tool, I've tried various fitting methods to eliminate unwanted components and stacked results from nearly 100 packets: http://i.imgur.com/5r9eYwO.png From the result, in short, removing only constant offset across subcarrier seems to be effective. But I'm not sure. And sometimes, some phase measurement show large dispalcement along y-ax
[ath9k-devel] [PATCH] ath9k: Fix programming of minCCA power threshold
The function ar9003_hw_apply_minccapwr_thresh takes as second parameter not
a pointer to the channel but a boolean value describing whether the channel
is 2.4GHz or not. This broke (according to the origin commit) the ETSI
regulatory compliance on 5GHz channels.
Fixes: 3533bf6b15a0 ("ath9k: Fix regulatory compliance")
Signed-off-by: Sven Eckelmann
Cc: Simon Wunderlich
Cc: Sujith Manoharan
---
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
index dec1a31..e2083f4 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
@@ -4176,7 +4176,7 @@ static void ath9k_hw_ar9300_set_board_values(struct
ath_hw *ah,
if (!AR_SREV_9330(ah) && !AR_SREV_9340(ah) && !AR_SREV_9531(ah))
ar9003_hw_internal_regulator_apply(ah);
ar9003_hw_apply_tuning_caps(ah);
- ar9003_hw_apply_minccapwr_thresh(ah, chan);
+ ar9003_hw_apply_minccapwr_thresh(ah, is2ghz);
ar9003_hw_txend_to_xpa_off_apply(ah, is2ghz);
ar9003_hw_thermometer_apply(ah);
ar9003_hw_thermo_cal_apply(ah);
--
2.8.1
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 1/2] ath9k: use mac80211 intermediate software queues
On 2016-06-17 11:09, Toke Høiland-Jørgensen wrote:
> This patch leaves the code for ath9k's internal per-node per-tid
> queues in place and just modifies the driver to also pull from
> the new mac80211 intermediate software queues, and implements
> the .wake_tx_queue method, which will cause mac80211 to deliver
> packets to be sent via the new intermediate queue.
>
> Signed-off-by: Tim Shepard
>
> Reworked to not require the global variable renaming in ath9k.
>
> Signed-off-by: Toke Høiland-Jørgensen
> ---
> drivers/net/wireless/ath/ath9k/ath9k.h | 16 +++-
> drivers/net/wireless/ath/ath9k/debug_sta.c | 7 +-
> drivers/net/wireless/ath/ath9k/init.c | 1 +
> drivers/net/wireless/ath/ath9k/main.c | 1 +
> drivers/net/wireless/ath/ath9k/xmit.c | 119
> +
> 5 files changed, 125 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h
> b/drivers/net/wireless/ath/ath9k/ath9k.h
> index 93b3793..caeae10 100644
> --- a/drivers/net/wireless/ath/ath9k/ath9k.h
> +++ b/drivers/net/wireless/ath/ath9k/ath9k.h
> @@ -145,8 +145,6 @@ int ath_descdma_setup(struct ath_softc *sc, struct
> ath_descdma *dd,
> #define BAW_WITHIN(_start, _bawsz, _seqno) \
> _seqno) - (_start)) & 4095) < (_bawsz))
>
> -#define ATH_AN_2_TID(_an, _tidno) (&(_an)->tid[(_tidno)])
> -
> #define IS_HT_RATE(rate) (rate & 0x80)
> #define IS_CCK_RATE(rate) ((rate >= 0x18) && (rate <= 0x1e))
> #define IS_OFDM_RATE(rate) ((rate >= 0x8) && (rate <= 0xf))
> @@ -232,8 +230,10 @@ struct ath_buf {
>
> struct ath_atx_tid {
> struct list_head list;
> + struct sk_buff_head i_q;
Do we really need a third queue here? Instead of adding yet another
layer of queueing here, I think we should even get rid of buf_q.
Channel context based queue handling can be dealt with by
stopping/starting relevant queues on channel context changes.
buf_q becomes unnecessary when you remove all code in the drv_tx
codepath that moves frames to the intermediate queue.
Any frame that was pulled from the intermediate queue and prepared for
tx, but which can't be sent right now can simply be queued to retry_q.
This will also help with getting the diffstat insertion/deletion ratio
under control ;)
> struct sk_buff_head buf_q;
> struct sk_buff_head retry_q;
> + struct ieee80211_txq *swq;
No need for this pointer, you can use container_of.
- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 1/2] ath9k: use mac80211 intermediate software queues
On 2016-06-17 15:43, Toke Høiland-Jørgensen wrote:
> Felix Fietkau writes:
>
>> On 2016-06-17 11:09, Toke Høiland-Jørgensen wrote:
>>> This patch leaves the code for ath9k's internal per-node per-tid
>>> queues in place and just modifies the driver to also pull from
>>> the new mac80211 intermediate software queues, and implements
>>> the .wake_tx_queue method, which will cause mac80211 to deliver
>>> packets to be sent via the new intermediate queue.
>>>
>>> Signed-off-by: Tim Shepard
>>>
>>> Reworked to not require the global variable renaming in ath9k.
>>>
>>> Signed-off-by: Toke Høiland-Jørgensen
>>> ---
>>> drivers/net/wireless/ath/ath9k/ath9k.h | 16 +++-
>>> drivers/net/wireless/ath/ath9k/debug_sta.c | 7 +-
>>> drivers/net/wireless/ath/ath9k/init.c | 1 +
>>> drivers/net/wireless/ath/ath9k/main.c | 1 +
>>> drivers/net/wireless/ath/ath9k/xmit.c | 119
>>> +
>>> 5 files changed, 125 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h
>>> b/drivers/net/wireless/ath/ath9k/ath9k.h
>>> index 93b3793..caeae10 100644
>>> --- a/drivers/net/wireless/ath/ath9k/ath9k.h
>>> +++ b/drivers/net/wireless/ath/ath9k/ath9k.h
>>> @@ -145,8 +145,6 @@ int ath_descdma_setup(struct ath_softc *sc, struct
>>> ath_descdma *dd,
>>> #define BAW_WITHIN(_start, _bawsz, _seqno) \
>>> _seqno) - (_start)) & 4095) < (_bawsz))
>>>
>>> -#define ATH_AN_2_TID(_an, _tidno) (&(_an)->tid[(_tidno)])
>>> -
>>> #define IS_HT_RATE(rate) (rate & 0x80)
>>> #define IS_CCK_RATE(rate) ((rate >= 0x18) && (rate <= 0x1e))
>>> #define IS_OFDM_RATE(rate) ((rate >= 0x8) && (rate <= 0xf))
>>> @@ -232,8 +230,10 @@ struct ath_buf {
>>>
>>> struct ath_atx_tid {
>>> struct list_head list;
>>> + struct sk_buff_head i_q;
>> Do we really need a third queue here? Instead of adding yet another
>> layer of queueing here, I think we should even get rid of buf_q.
>
> This is definitely something that needs to be improved. One other
> sticking point related to this: in the current version of this patch
> ath_tid_has_buffered() gains a side effect of pulling from the mac80211
> txq, which is obviously not so nice.
>
> The obvious way to get rid of this is to export a txq_has_buffered()
> function at the mac80211 layer. But avoiding that may be possible; the
> sticking point is what to do with the code paths that do not dequeue
> packets, but check ath_tid_has_buffered() to decide whether to schedule
> the queue and/or to tell ieee80211_sta_set_buffered() about it (these
> are for instance ath_tx_aggr_sleep/wakeup(). Can those just be removed
> (i.e. don't call into ieee80211, and always schedule the txq on wakeup?
> I'm not familiar enough with the intermediate queues to make that
> call...
For tx scheduling, we can use swq_nonempty and deal with false positives.
For power save we should only use ieee80211_sta_set_buffered if the
driver itself has buffered some frames. Indication of packets in the
mac80211 intermediate queue is already taken care of inside mac80211.
- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 1/2] ath9k: use mac80211 intermediate software queues
>> struct ath_atx_tid {
>> struct list_head list;
>> + struct sk_buff_head i_q;
> Do we really need a third queue here? Instead of adding yet another
> layer of queueing here, I think we should even get rid of buf_q.
Less queues, more filling!
>
> Channel context based queue handling can be dealt with by
> stopping/starting relevant queues on channel context changes.
what can be done to reduce the impact of channel scans?
http://blog.cerowrt.org/post/disabling_channel_scans/
> buf_q becomes unnecessary when you remove all code in the drv_tx
> codepath that moves frames to the intermediate queue.
>
> Any frame that was pulled from the intermediate queue and prepared for
> tx, but which can't be sent right now can simply be queued to retry_q.
>
> This will also help with getting the diffstat insertion/deletion ratio
> under control ;)
The ideas here can apply elsewhere, also. Are you still actively
working with the mt76?
Anything else "out there" besides that and the ath5k worth looking at?
Am I seeing patches and firmware changes for better statistic keeping
on the ath10k that look promising for airtime fairness... or am I
delusional?
> elsewhere powersave was mentioned
How big can a powersave queue get?
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 1/2] ath9k: use mac80211 intermediate software queues
On 2016-06-17 15:41, Tim Shepard wrote:
>> > diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h
>> > b/drivers/net/wireless/ath/ath9k/ath9k.h
>> > index 93b3793..caeae10 100644
>> > --- a/drivers/net/wireless/ath/ath9k/ath9k.h
>> > +++ b/drivers/net/wireless/ath/ath9k/ath9k.h
>> > @@ -145,8 +145,6 @@ int ath_descdma_setup(struct ath_softc *sc, struct
>> > ath_descdma *dd,
>> > #define BAW_WITHIN(_start, _bawsz, _seqno) \
>> >_seqno) - (_start)) & 4095) < (_bawsz))
>> >
>> > -#define ATH_AN_2_TID(_an, _tidno) (&(_an)->tid[(_tidno)])
>> > -
>> > #define IS_HT_RATE(rate) (rate & 0x80)
>> > #define IS_CCK_RATE(rate) ((rate >= 0x18) && (rate <= 0x1e))
>> > #define IS_OFDM_RATE(rate) ((rate >= 0x8) && (rate <= 0xf))
>> > @@ -232,8 +230,10 @@ struct ath_buf {
>> >
>> > struct ath_atx_tid {
>> >struct list_head list;
>> > + struct sk_buff_head i_q;
>> Do we really need a third queue here? Instead of adding yet another
>> layer of queueing here, I think we should even get rid of buf_q.
>>
>> Channel context based queue handling can be dealt with by
>> stopping/starting relevant queues on channel context changes.
>>
>> buf_q becomes unnecessary when you remove all code in the drv_tx
>> codepath that moves frames to the intermediate queue.
>>
>> Any frame that was pulled from the intermediate queue and prepared for
>> tx, but which can't be sent right now can simply be queued to retry_q.
>>
>> This will also help with getting the diffstat insertion/deletion ratio
>> under control ;)
>>
>> >struct sk_buff_head buf_q;
>> >struct sk_buff_head retry_q;
>> > + struct ieee80211_txq *swq;
>> No need for this pointer, you can use container_of.
>
>
> Felix, great to hear from you and thanks for your feedback. I will
> try to work on this.
>
> I was struggling to understand the channel context stuff, and I have
> no idea how to test it. (Is there anyone else listening who might be
> able to help with testing the channel context stuff as we improve this
> patch and simplify the ath9k driver's use of the new mac80211
> intermediate queues?)
>
>
> Felix, do you have any thoughts on the renaming of txq to hwx that I
> had done in my original version of this patch? I had a good e-mail
> discussion with Toke a week or two ago (cc these same various lists)
> and I believe he came to understand that perhaps the renaming I had
> done in the original version of this patch was worth doing.
>
> Now in Toke's version of my patch he calls the ieee80211 txq a "swq"
> and the ath9k hardware queue is called a "txq". (I had called the
> ieee80211 txq a "txq" and I renamed the ath9k hardware queue "hwq"
> throught all the ath9k driver code.This also made ath9k's names of
> things more similar to mt76 which I was looking at as an example of a
> driver that uses your new ieee80211 txq mechanism.
>
> I think the renaming is worth doing, but I also understand the
> renaming can be disruptive to others actively working on ath9k.
> It would be nice to have another opinion on this.
I think we should finish intermediate queues support first and then look
into the rename later.
- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 1/2] ath9k: use mac80211 intermediate software queues
On 2016-06-17 15:48, Felix Fietkau wrote:
> On 2016-06-17 15:43, Toke Høiland-Jørgensen wrote:
>> Felix Fietkau writes:
>>
>>> On 2016-06-17 11:09, Toke Høiland-Jørgensen wrote:
This patch leaves the code for ath9k's internal per-node per-tid
queues in place and just modifies the driver to also pull from
the new mac80211 intermediate software queues, and implements
the .wake_tx_queue method, which will cause mac80211 to deliver
packets to be sent via the new intermediate queue.
Signed-off-by: Tim Shepard
Reworked to not require the global variable renaming in ath9k.
Signed-off-by: Toke Høiland-Jørgensen
---
drivers/net/wireless/ath/ath9k/ath9k.h | 16 +++-
drivers/net/wireless/ath/ath9k/debug_sta.c | 7 +-
drivers/net/wireless/ath/ath9k/init.c | 1 +
drivers/net/wireless/ath/ath9k/main.c | 1 +
drivers/net/wireless/ath/ath9k/xmit.c | 119
+
5 files changed, 125 insertions(+), 19 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h
b/drivers/net/wireless/ath/ath9k/ath9k.h
index 93b3793..caeae10 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -145,8 +145,6 @@ int ath_descdma_setup(struct ath_softc *sc, struct
ath_descdma *dd,
#define BAW_WITHIN(_start, _bawsz, _seqno) \
_seqno) - (_start)) & 4095) < (_bawsz))
-#define ATH_AN_2_TID(_an, _tidno) (&(_an)->tid[(_tidno)])
-
#define IS_HT_RATE(rate) (rate & 0x80)
#define IS_CCK_RATE(rate) ((rate >= 0x18) && (rate <= 0x1e))
#define IS_OFDM_RATE(rate) ((rate >= 0x8) && (rate <= 0xf))
@@ -232,8 +230,10 @@ struct ath_buf {
struct ath_atx_tid {
struct list_head list;
+ struct sk_buff_head i_q;
>>> Do we really need a third queue here? Instead of adding yet another
>>> layer of queueing here, I think we should even get rid of buf_q.
>>
>> This is definitely something that needs to be improved. One other
>> sticking point related to this: in the current version of this patch
>> ath_tid_has_buffered() gains a side effect of pulling from the mac80211
>> txq, which is obviously not so nice.
>>
>> The obvious way to get rid of this is to export a txq_has_buffered()
>> function at the mac80211 layer. But avoiding that may be possible; the
>> sticking point is what to do with the code paths that do not dequeue
>> packets, but check ath_tid_has_buffered() to decide whether to schedule
>> the queue and/or to tell ieee80211_sta_set_buffered() about it (these
>> are for instance ath_tx_aggr_sleep/wakeup(). Can those just be removed
>> (i.e. don't call into ieee80211, and always schedule the txq on wakeup?
>> I'm not familiar enough with the intermediate queues to make that
>> call...
> For tx scheduling, we can use swq_nonempty and deal with false positives.
> For power save we should only use ieee80211_sta_set_buffered if the
> driver itself has buffered some frames. Indication of packets in the
> mac80211 intermediate queue is already taken care of inside mac80211.
One more thing that I forgot in my previous reply: on PS wakeup, the
driver does not need to schedule the intermediate queues itself -
mac80211 will call drv_wake_tx_queue if frames are pending.
- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
