No subject

[<bogus@does.not.exist.com>]

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

<div dir=3D"ltr">Hello everybody!<br>I&#39;s my first time writing to the l=
ist, while I&#39;m following it with interest for some time.<br><br>We&#39;=
re developing some MAC functions in software for testing purposes.<br><br>

The most challenging part seems to be generating Acks in software.<br><br>T=
hree main tasks:<br>1. Disabling Link Layer Acks in hardware<br>2. Generati=
ng Acks as &quot;low&quot; as possible in driver stack<br>3. sending such a=
cks as quickly as possible<br>

<br>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.<br><br>We have a problem in task 3.<br>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&#39;ve been put in the tx queu=
e.<br>

<br>Test environment<br>Access Point <br>Hardware: Alix 2d2 board, Compex W=
LM200NX MiniPCI network adapter (should be Chipset AR9220 according to vend=
or datasheet - kernel Dmesg says &quot;ieee80211 phy0: Atheros AR9280 Rev:2=
 mem=3D0xd0ca0000, irq=3D9&quot;) <br>

Software: OpenWRT REVISION r37112<br><br>Client<br>any WiFi compliant clien=
t such as smartphones and laptop<br><br>Sniffer<br>wireshark on a laptop wi=
th a mon interface<br><br><br>Results<br>From a sniffer perspective you can=
not distinguish between hw and sw generated acks.<br>

Enabling hw acks results in duplicate, identical acks being sent by the acc=
ess point on successful frame receipt.<br>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=
.<br>

<br>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).<br><br>Tried =
a few flags with no success (tested with or without such flags and no appar=
ent change happened).<br>

Flags are:<br><br>AR_DIAG_FORCE_RX_CLEAR<br>AR_DIAG_FORCE_CH_IDLE_HIGH<br>A=
R_DIAG_IGNORE_VIRT_CS<br>AR_D_GBL_IFS_MISC_IGNORE_BACKOFF<br><br><br>Possib=
le &quot;next steps&quot;:<br><br>- choose the correct hw queue =A0(now usi=
ng queue skb-&gt;queue_mapping=3D3 and skb-&gt;priority=3D7)<br>

- find out the correct register values for disabling the virtual and physic=
al carrier sense (AR_DIAG_SW) for ath9k.<br>- find out if such values are &=
quot;honored&quot; in our card or if should be better to simply change the =
atheros chipset family or card manufacturer<br>

- disabling back-off setting the cwmin and cwmax to zero on the choosen que=
ue And also setting AIFS=3D1 (or zero?)<br>- disabling any debug code possi=
bly inserted during coding phase (according to <a href=3D"http://adrianchad=
d.blogspot.it/2012/11/be-careful-of-adding-debugging-as.html">http://adrian=
chadd.blogspot.it/2012/11/be-careful-of-adding-debugging-as.html</a>)<br>

<br><br>Any suggestion?<br>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 &quot;n&quot; version=
s of a/g)?<div>

<br></div><div><br>Any feedback welcome...<br>Thnkz in advance!!!</div><div=
><br></div><div>Alex</div><div><br></div><div><br></div></div>

--047d7b15ad979ce54c04edbbc6dc--