Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior
Hello Mr.Adrian, Thanks for your response. I understand the following: Please correct if I am wrong. 1. With WLAN_ACTIVE and BT_ACTIVE, the wireless medium is managed between BT and WLAN without stomping the traffic. 2. With WLAN_ACTIVE, BT_ACTIVE and BT_PRIORITY, WiFI traffic stomping is possible. Regards Sandeep. From: Adrian Chadd adr...@freebsd.org To: sandeep suresh sandeep.sur...@yahoo.co.in Cc: Sujith Manoharan suj...@msujith.org; ath9k-devel ath9k-devel@lists.ath9k.org; linux-wirel...@vger.kernel.org linux-wirel...@vger.kernel.org Sent: Wednesday, 10 April 2013 11:07 AM Subject: Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior Right, but same deal - if it asserts the line, it should stomp wifi transmission in your particular scheme. adrian On 9 April 2013 19:37, sandeep suresh sandeep.sur...@yahoo.co.in wrote: Hello Mr.Adrian, Thanks for your response. During googling, I had come across the following 2-wire coexistence solution from owl modules. http://support.connectblue.com/display/PRODWLAN/cB-OWL22x+Bluetooth+co-existence+application+note According to this application note, for 2-wire coexistence, WLAN_ACTIVE and BT_PRIORITY signals are used rather than WLAN_ACTIVE and BT_ACTIVE. What is your opinion on this? And as I understand owl modules are based on Atheros chipsets. Regards Sandeep. From: Adrian Chadd adr...@freebsd.org To: sandeep suresh sandeep.sur...@yahoo.co.in Cc: Sujith Manoharan suj...@msujith.org; ath9k-devel ath9k-devel@lists.ath9k.org; linux-wirel...@vger.kernel.org linux-wirel...@vger.kernel.org Sent: Wednesday, 10 April 2013 4:30 AM Subject: Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior Hi, Yes, WLAN_ACTIVE here is just both TX and RX activity. So if it were working, that would stay low. adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior
No, wifi stomping occurs with both 2-wire and 3-wire. BT_PRIORITY just gives the MAC the ability to tell the difference between high priority TX and any bt activity requiring the air, so the MAC can then choose a weight based on differnet kinds of BT inputs. If all you have is two wire, then you don't get separate weight table entries for different kinds of BT transmissions. adrian On 9 April 2013 23:13, sandeep suresh sandeep.sur...@yahoo.co.in wrote: Hello Mr.Adrian, Thanks for your response. I understand the following: Please correct if I am wrong. 1. With WLAN_ACTIVE and BT_ACTIVE, the wireless medium is managed between BT and WLAN without stomping the traffic. 2. With WLAN_ACTIVE, BT_ACTIVE and BT_PRIORITY, WiFI traffic stomping is possible. Regards Sandeep. From: Adrian Chadd adr...@freebsd.org To: sandeep suresh sandeep.sur...@yahoo.co.in Cc: Sujith Manoharan suj...@msujith.org; ath9k-devel ath9k-devel@lists.ath9k.org; linux-wirel...@vger.kernel.org linux-wirel...@vger.kernel.org Sent: Wednesday, 10 April 2013 11:07 AM Subject: Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior Right, but same deal - if it asserts the line, it should stomp wifi transmission in your particular scheme. adrian On 9 April 2013 19:37, sandeep suresh sandeep.sur...@yahoo.co.in wrote: Hello Mr.Adrian, Thanks for your response. During googling, I had come across the following 2-wire coexistence solution from owl modules. http://support.connectblue.com/display/PRODWLAN/cB-OWL22x+Bluetooth+co-existence+application+note According to this application note, for 2-wire coexistence, WLAN_ACTIVE and BT_PRIORITY signals are used rather than WLAN_ACTIVE and BT_ACTIVE. What is your opinion on this? And as I understand owl modules are based on Atheros chipsets. Regards Sandeep. From: Adrian Chadd adr...@freebsd.org To: sandeep suresh sandeep.sur...@yahoo.co.in Cc: Sujith Manoharan suj...@msujith.org; ath9k-devel ath9k-devel@lists.ath9k.org; linux-wirel...@vger.kernel.org linux-wirel...@vger.kernel.org Sent: Wednesday, 10 April 2013 4:30 AM Subject: Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior Hi, Yes, WLAN_ACTIVE here is just both TX and RX activity. So if it were working, that would stay low. adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] Adjust data rate of beacon frame but TSF goes wrong
Hi everyone,
We are using ath9k for our research project. The wlan interface that we
have is AR9285. Basically we want to adjust the data rate of beacon frame
to higher rate, i.e. from 1Mbps to 54Mbps, so that the beacon frame will
use less channel time.
I tried to achieve that by simply change the argument of ath_beacon_setup()
--- a/drivers/net/wireless/ath/ath9k/beacon.c
+++ b/drivers/net/wireless/ath/ath9k/beacon.c
@@ -209,7 +209,9 @@ static struct ath_buf *ath_beacon_generate(struct
ieee80211_hw *hw,
}
}
- ath_beacon_setup(sc, vif, bf, info-control.rates[0].idx);
+ // ath_beacon_setup(sc, vif, bf, info-control.rates[0].idx);
+ // chagne data rate
+ ath_beacon_setup(sc, vif, bf, 11);
while (skb) {
ath_tx_cabq(hw, skb);
By using the other wifi station in monitor mode, I can see that the data
rate is changed from 1Mpbs to 54Mbps. However, the TSF value does not looks
right. That is we observed the TSF in the stations run few hundreds
micro-sec earlier than the AP.
We suspect that is because when AP timestamped the TSF in beacon, it
actually estimated the transmission time of the beacon frame under 1Mbps.
However, in our case, the data rate is 54Mbps, so that the transmission
time is shorter which makes the TSF of station nodes run earlier. Am I
right? Is it possible to change the data rate of beacon, and maintain the
sync of TSF as well?
Thanks and best regards,
-Yi-Hung
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [RFC] ath9k: Respect current txpower setting
In routine ath_tx_fill_desc(), the txpower is only set to MAX_RATE_POWER. Now it respects the txpower from bss_conf and set it if it is (txpower * 2) MAX_RATE_POWER else set to MAX_RATE_POWER. Signed-off-by: Tobias Steinicke tsteini...@net.t-labs.tu-berlin.de --- drivers/net/wireless/ath/ath9k/xmit.c |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c index 5bc5802..90701e4 100644 --- a/drivers/net/wireless/ath/ath9k/xmit.c +++ b/drivers/net/wireless/ath/ath9k/xmit.c @@ -1110,13 +1110,18 @@ static void ath_tx_fill_desc(struct ath_softc *sc, struct ath_buf *bf, struct ath_buf *bf_first = bf; struct ath_tx_info info; bool aggr = !!(bf-bf_state.bf_type BUF_AGGR); + u8 txpower = tx_info-control.vif-bss_conf.txpower * 2; memset(info, 0, sizeof(info)); info.is_first = true; info.is_last = true; - info.txpower = MAX_RATE_POWER; info.qcu = txq-axq_qnum; + if (txpower MAX_RATE_POWER) + info.txpower = MAX_RATE_POWER; + else + info.txpower = txpower; + info.flags = ATH9K_TXDESC_INTREQ; if (tx_info-flags IEEE80211_TX_CTL_NO_ACK) info.flags |= ATH9K_TXDESC_NOACK; -- 1.7.9.5 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [RFC] ath9k: Respect current txpower setting
On 10 April 2013 15:03, Tobias Steinicke tobias.steini...@net.t-labs.tu-berlin.de wrote: In routine ath_tx_fill_desc(), the txpower is only set to MAX_RATE_POWER. Now it respects the txpower from bss_conf and set it if it is (txpower * 2) MAX_RATE_POWER else set to MAX_RATE_POWER. This doesn't do anything unless TPC is enabled. And if TPC is enabled, you have to jump through hoops to set the correct target TX power, as it's not always 1:1 between dBm value programmed in and dBm value transmitted. Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [RFC] ath9k: Respect current txpower setting
I fucked the format. Sorry for that. I will resend it. Tobias Steinicke Am 11.04.2013 00:03, schrieb Tobias Steinicke: In routine ath_tx_fill_desc(), the txpower is only set to MAX_RATE_POWER. Now it respects the txpower from bss_conf and set it if it is (txpower * 2) MAX_RATE_POWER else set to MAX_RATE_POWER. Signed-off-by: Tobias Steinicke tsteini...@net.t-labs.tu-berlin.de --- drivers/net/wireless/ath/ath9k/xmit.c |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c index 5bc5802..90701e4 100644 --- a/drivers/net/wireless/ath/ath9k/xmit.c +++ b/drivers/net/wireless/ath/ath9k/xmit.c @@ -1110,13 +1110,18 @@ static void ath_tx_fill_desc(struct ath_softc *sc, struct ath_buf *bf, struct ath_buf *bf_first = bf; struct ath_tx_info info; bool aggr = !!(bf-bf_state.bf_type BUF_AGGR); + u8 txpower = tx_info-control.vif-bss_conf.txpower * 2; memset(info, 0, sizeof(info)); info.is_first = true; info.is_last = true; - info.txpower = MAX_RATE_POWER; info.qcu = txq-axq_qnum; + if (txpower MAX_RATE_POWER) + info.txpower = MAX_RATE_POWER; + else + info.txpower = txpower; + info.flags = ATH9K_TXDESC_INTREQ; if (tx_info-flags IEEE80211_TX_CTL_NO_ACK) info.flags |= ATH9K_TXDESC_NOACK; ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [RFC] ath9k: Respect current txpower setting
On 2013-04-11 1:20 AM, Adrian Chadd wrote: On 10 April 2013 15:03, Tobias Steinicke tobias.steini...@net.t-labs.tu-berlin.de wrote: In routine ath_tx_fill_desc(), the txpower is only set to MAX_RATE_POWER. Now it respects the txpower from bss_conf and set it if it is (txpower * 2) MAX_RATE_POWER else set to MAX_RATE_POWER. This doesn't do anything unless TPC is enabled. And if TPC is enabled, you have to jump through hoops to set the correct target TX power, as it's not always 1:1 between dBm value programmed in and dBm value transmitted. I think TPC power value mappings were only problematic in pre-802.11n chipsets, all chipsets supported by ath9k should be fine. There may be some minor changes missing to enable it on some older chipsets, but other than that it should be functional. - Felix ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [RFCv2] ath9k: Respect current txpower setting
In routine ath_tx_fill_desc(), the txpower is only set to MAX_RATE_POWER. Now it respects the txpower from bss_conf and set it if it is (txpower * 2) MAX_RATE_POWER else set to MAX_RATE_POWER. Signed-off-by: Tobias Steinicke tsteini...@net.t-labs.tu-berlin.de --- drivers/net/wireless/ath/ath9k/xmit.c |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c index 5bc5802..90701e4 100644 --- a/drivers/net/wireless/ath/ath9k/xmit.c +++ b/drivers/net/wireless/ath/ath9k/xmit.c @@ -1110,13 +1110,18 @@ static void ath_tx_fill_desc(struct ath_softc *sc, struct ath_buf *bf, struct ath_buf *bf_first = bf; struct ath_tx_info info; bool aggr = !!(bf-bf_state.bf_type BUF_AGGR); + u8 txpower = tx_info-control.vif-bss_conf.txpower * 2; memset(info, 0, sizeof(info)); info.is_first = true; info.is_last = true; - info.txpower = MAX_RATE_POWER; info.qcu = txq-axq_qnum; + if (txpower MAX_RATE_POWER) + info.txpower = MAX_RATE_POWER; + else + info.txpower = txpower; + info.flags = ATH9K_TXDESC_INTREQ; if (tx_info-flags IEEE80211_TX_CTL_NO_ACK) info.flags |= ATH9K_TXDESC_NOACK; -- 1.7.9.5 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [RFC] ath9k: Respect current txpower setting
On 10 April 2013 16:24, Felix Fietkau n...@openwrt.org wrote: I think TPC power value mappings were only problematic in pre-802.11n chipsets, all chipsets supported by ath9k should be fine. There may be some minor changes missing to enable it on some older chipsets, but other than that it should be functional. .. except AR9285. .. and I think maybe AR9485, and some of the Osprey era NICs that have different CCK target power offset values. :-) It's worth reviewing. I had to do this to get TPC working on AR9285, and I haven't yet pushed it into FreeBSD (because at the time I didn't have a spectrum analyser. Now, however, I do..) Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [RFC] ath9k: Respect current txpower setting
Am 11.04.2013 01:20, schrieb Adrian Chadd: On 10 April 2013 15:03, Tobias Steinicke tobias.steini...@net.t-labs.tu-berlin.de wrote: In routine ath_tx_fill_desc(), the txpower is only set to MAX_RATE_POWER. Now it respects the txpower from bss_conf and set it if it is (txpower * 2) MAX_RATE_POWER else set to MAX_RATE_POWER. This doesn't do anything unless TPC is enabled. If I'm understanding this right, if TPC is disable the cards sending always with the max. power (I guess from the current regdomain)? Tobias ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [RFC] ath9k: Respect current txpower setting
If TPC isn't enabled, the cards transmit at the power configured in the AR_PHY_TX_POWER_* registers. Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [RFC] ath9k: Respect current txpower setting
Am 11.04.2013 01:38, schrieb Adrian Chadd: If TPC isn't enabled, the cards transmit at the power configured in the AR_PHY_TX_POWER_* registers. I understand. Thanks for the clarification. But since TPC is enabled, we have to set info.txpower to the right value. Also ar900[23]_set_txdesc() have to change to apply info.txpower to all try series. Tobias ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] Problem in calculation of the Queuing+channel access delay (being smaller than airtime)
hi, I am trying to measure the time when the frame is inserted into queue (ath_tx_process_buffer, ath_drain_txq_list[not req actually]) and when one receives ACK from hardware in ath_tx_process_buffer() in the descriptor, ath_tx_status and eventually the timestamp is calculated in ath_tx_complete_buf() by me. But when I compute the airtime of the frame by using frame-size/bitrate,I get the airtime greater than the difference in the tsf values. My traces have this situation about 22% by volume count. For example, for a frame of size 1542 transmitted at 18Mbps, the airtime calculated is 685 [1542/18.0], while the ACK_time- enqueue_time ==318 ! Both the values are in microseconds. Is there a factor between the clock time and the airtime I calculate ? I am unable to understand why ? https://github.com/abnarain/mac80211-ath9k/blob/master/drivers/net/wireless/ath/ath9k/xmit.c#L2075 I have neat documented code above, which does the following : get the hw tsf in ath_tx_process_buffer() [also in ath_drain_txq_list(), which is hardly called], this is stored in bf-timestamp_temp. This is then used to combine the ath_tx_status-ts_tstamp 32 bit field to get the final tsf value, using the way tsf is calculated in the receive path (ath9k/recv.c) Will be great if someone can help - Abhinav ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
