From mboxrd@z Thu Jan 1 00:00:00 1970 From: Date: Sun, 15 Sep 2013 09:49:13 -0000 Subject: No subject Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org generated acks. Enabling hw acks results in duplicate, identical acks being sent by the access point on successful frame receipt. The difference is just in timings: while hw acks is usually received in less then 10 or 20 microseconds from a successful frame receipt, sw generated acks arrive in 2-300 microseconds. We suppose the problem is in Clear Channel Assessment: the hardware waits the right (CSMA compliant) time to send the frame while we would like it to send the ack frame ASAP (i.e. wait SIFS instead of AIFS). Tried a few flags with no success (tested with or without such flags and no apparent change happened). Flags are: AR_DIAG_FORCE_RX_CLEAR AR_DIAG_FORCE_CH_IDLE_HIGH AR_DIAG_IGNORE_VIRT_CS AR_D_GBL_IFS_MISC_IGNORE_BACKOFF Possible "next steps": - choose the correct hw queue (now using queue skb->queue_mapping=3 and skb->priority=7) - find out the correct register values for disabling the virtual and physical carrier sense (AR_DIAG_SW) for ath9k. - find out if such values are "honored" in our card or if should be better to simply change the atheros chipset family or card manufacturer - disabling back-off setting the cwmin and cwmax to zero on the choosen queue And also setting AIFS=1 (or zero?) - disabling any debug code possibly inserted during coding phase (according to http://adrianchadd.blogspot.it/2012/11/be-careful-of-adding-debugging-as.html ) Any suggestion? Is anyone interested in collaborating in softMAC development? Right now we are thinking about standard ack mechanism (i.e. a/g) but it could be extended to blockAck (802.11e or "n" versions of a/g)? Any feedback welcome... Thnkz in advance!!! Alex --047d7b15ad979ce54c04edbbc6dc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello everybody!
I's my first time writing to the l= ist, while I'm following it with interest for some time.

We'= re developing some MAC functions in software for testing purposes.

The most challenging part seems to be generating Acks in software.

T= hree main tasks:
1. Disabling Link Layer Acks in hardware
2. Generati= ng Acks as "low" as possible in driver stack
3. sending such a= cks as quickly as possible

Now, task 1 and 2 are done in ath9k: task 1 setting the appropriate fla= g in the register and task 2 coding link layer ack generation in ath9k_rx t= asklet.

We have a problem in task 3.
It seems that the ack frame = is sent like regular frames, respecting CCA, while we would need the ack fr= ames to be sent immediately, as soon as they've been put in the tx queu= e.

Test environment
Access Point
Hardware: Alix 2d2 board, Compex W= LM200NX MiniPCI network adapter (should be Chipset AR9220 according to vend= or datasheet - kernel Dmesg says "ieee80211 phy0: Atheros AR9280 Rev:2= mem=3D0xd0ca0000, irq=3D9")
Software: OpenWRT REVISION r37112

Client
any WiFi compliant clien= t such as smartphones and laptop

Sniffer
wireshark on a laptop wi= th a mon interface


Results
From a sniffer perspective you can= not distinguish between hw and sw generated acks.
Enabling hw acks results in duplicate, identical acks being sent by the acc= ess point on successful frame receipt.
The difference is just in timings= : while hw acks is usually received in less then 10 or 20 microseconds from= a successful frame receipt, sw generated acks arrive in 2-300 microseconds= .

We suppose the problem is in Clear Channel Assessment: the hardware wai= ts the right (CSMA compliant) time to send the frame while we would like it= to send the ack frame ASAP (i.e. wait SIFS instead of AIFS).

Tried = a few flags with no success (tested with or without such flags and no appar= ent change happened).
Flags are:

AR_DIAG_FORCE_RX_CLEAR
AR_DIAG_FORCE_CH_IDLE_HIGH
A= R_DIAG_IGNORE_VIRT_CS
AR_D_GBL_IFS_MISC_IGNORE_BACKOFF


Possib= le "next steps":

- choose the correct hw queue =A0(now usi= ng queue skb->queue_mapping=3D3 and skb->priority=3D7)
- find out the correct register values for disabling the virtual and physic= al carrier sense (AR_DIAG_SW) for ath9k.
- find out if such values are &= quot;honored" in our card or if should be better to simply change the = atheros chipset family or card manufacturer
- disabling back-off setting the cwmin and cwmax to zero on the choosen que= ue And also setting AIFS=3D1 (or zero?)
- disabling any debug code possi= bly inserted during coding phase (according to http://adrian= chadd.blogspot.it/2012/11/be-careful-of-adding-debugging-as.html)


Any suggestion?
Is anyone interested in collaborating in softMAC= development? Right now we are thinking about standard ack mechanism (i.e. = a/g) but it could be extended to blockAck (802.11e or "n" version= s of a/g)?


Any feedback welcome...
Thnkz in advance!!!

Alex


--047d7b15ad979ce54c04edbbc6dc--