ath9k-devel.lists.ath9k.org archive mirror
 help / color / mirror / Atom feed
From: sandeep suresh <sandeep.suresh@yahoo.co.in>
To: ath9k-devel@lists.ath9k.org
Subject: [ath9k-devel] Bonjour mDNS broacast can be lost during BT-WLAN coexistence schemes?
Date: Wed, 30 Mar 2016 01:40:43 +0000 (UTC)	[thread overview]
Message-ID: <1186227012.1763514.1459302043299.JavaMail.yahoo@mail.yahoo.com> (raw)
In-Reply-To: <CAJ-VmomakNNn2oUQ+HfPrA=d5QXkAfnLixOBF5twX9yL3bRetA@mail.gmail.com>

Hello Adrian,Thanks for your quick response. Specifically 3 follow-up queries:a. Based on your comment, "I thought bt_tx_rx is "bt is active", not "bt is tx'ing." I'd have tocheck the PHY docs.". Can you please check this and confirm/let me know? Based on your comment, bt_tx_rx = 1 when BT_ACTIVE = 1 and 0 otherwise.b. Regarding the comment on BT indicating that it is only in receive mode. As we understand there are multicast/ broadcast packets sent from WiFi AP to WiFi STA (my WiFi device). There are cameras which does udp streaming. So, if BT can inform WLAN that it is only in receive mode, then WLAN can also receive the multicast/ broadcast packets and hence the throughput of WLAN will increase. ?What is your opinion?c. Next, in a 2-wire coexistence scheme, if BT_ACTIVE can we inform WLAN to enter into power save mode? As I understand with this, the WiFi AP will buffer all multicast/broadcast packets. When BT_ACTIVE is de-asserted, then WLAN can exit power save mode and get the buffered packets. Is this realistic? And if Yes, how can this be achieved?
Thanks & regardsSandeep 

    On Wednesday, 30 March 2016 1:59 AM, Adrian Chadd <adrian@freebsd.org> wrote:
 

 On 28 March 2016 at 21:22, sandeep suresh <sandeep.suresh@yahoo.co.in> wrote:
> Hello Adrian,
>? ? ? Thanks for your response. Currently with 2-wire coexistence, BT has
> higher priority when compared to WiFi. You had shared the following
> different bitfields that can be configured with different weights:
>
> WLAN:-
> wait_beacon | qcu_priority | rx_clear | wlan level
>
> BT:-
> bt_priority | bt freq | bt_tx_rx | bt_level
>
> I have the following queries, please help:
> 1.? wait_beacon:- WLAN client is waiting for a beacon from AP, this bit will
> be set. If the weights during this state is kept the highest, then even if
> BT wants to use the medium (BT_ACTIVE = 1), WLAN will always attempt to
> catch the beacon. Am I correct in my understanding?

Right. The idea is that the STA wants to hear a beacon, so if it's
important to do this ,you want to have WLAN stomp BT.

> 2. What happens if BT wants to transmit during this time when wait_beacon =
> TRUE; will the BT transmission be suppressed?

If you set the weight appropriately then yeah, WLAN stomps BT.

> 3. Regarding "bt_tx_rx". As I understand, bt_tx_rx = 1 when BT is
> transmitting and bt_tx_rx = 0 when BT is receiving; am I correct? How can BT
> module communicate if it will be transmitting or receiving to WLAN module?
> Because BT_PRIORITY will only indicate High or Low priority.

I thought bt_tx_rx is "bt is active", not "bt is tx'ing." I'd have to
check the PHY docs.

> 4. Currently the WLAN_ACTIVE line indicates only Tx activity from WLAN. Is
> there any way to indicate only Rx activities (E.g. Beacon reception etc) ?

On two/three-wire coex, no, I don't think so. The whole point is that
you just need to know "is the BT wanting to do stuff", "is the wlan
wanting to do stuff" and "who wins".
The wlan chip is the arbiter of who wins, it has the weights
programmed in to figure out what to do when.

> 5.? Regarding your comment on dynamically changing weights. AR9287 and the
> BT chipsets are separate and connected to a Host controller running linux.

> As for different states of BT, if there is a need for different weights, I
> do not think at runtime the weights can be changed (by sending a command
> from BT to Host and then weight change from Host to WLAN)as we might not be
> able to meet the short timings. WHat is your opinion on this?

No, the BT doesn't get to send the host commands like that. The driver
layer (ath9k) could be extended to include smarts about traffic
patterns and which BT profiles are active, so you can tune the weights
based on it.

The ath9k driver can also do things to "tune" how much of the channel
it uses - eg, by using the quiet time timers to control TX duty cycle
so BT has more of a chance to work.

The later chips (MCI?) implement a control protocol between the wlan
side and the bt side. I haven't yet ported that functionality to
freebsd so I don't have any operational experience with that!


-adrian


  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20160330/305106e9/attachment.htm 

  reply	other threads:[~2016-03-30  1:40 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1860079637.618245.1459097009016.JavaMail.yahoo.ref@mail.yahoo.com>
2016-03-27 16:43 ` [ath9k-devel] Bonjour mDNS broacast can be lost during BT-WLAN coexistence schemes? sandeep suresh
2016-03-27 22:43   ` Adrian Chadd
2016-03-27 23:27     ` Dave Taht
2016-03-29  4:22     ` sandeep suresh
2016-03-29  8:24       ` [ath9k-devel] Fw: " sandeep suresh
2016-03-29 20:29       ` [ath9k-devel] " Adrian Chadd
2016-03-30  1:40         ` sandeep suresh [this message]
2016-03-30 20:02           ` Adrian Chadd
2016-03-31  1:33             ` sandeep suresh
2016-03-31 22:04               ` Adrian Chadd
2016-04-01  1:32                 ` sandeep suresh
2016-04-01 20:28                   ` Adrian Chadd
2016-04-02  2:52                     ` sandeep suresh
2016-04-05  4:33                       ` sandeep

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1186227012.1763514.1459302043299.JavaMail.yahoo@mail.yahoo.com \
    --to=sandeep.suresh@yahoo.co.in \
    --cc=ath9k-devel@lists.ath9k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).