[ath9k-devel] ath9k EDMA behaviour with TXOP?

Adrian Chadd <[email protected]>
Newsgroups org.ath9k.lists.ath9k-devel
Message-ID <CAJ-VmomiachpnCBvtmHLQzONgGY7+cZdfqhO5B+_pFZ_rLTYeA@mail.gmail.com>
hi,

I've noticed something reasonably quirky with the AR9380 and later
EDMA engine and I'd like to see if anyone else has seen it with ath9k.

It /looks/ like the TXOP gating for burstTime (ie, WMM bursts) is
gated by a TX FIFO entry. Ie, if you queue 8 separate TX FIFO entries,
each with a single MPDU, then you end up only getting one frame per
burst window.

For TDMA it shows up as frames only going out every time I push new
frames into the FIFO. It's very .. odd.

Now, if I try /really hard/ to keep pushing groups of frames into the
FIFO (ie, a list of frames per TX FIFO slot) and I don't push a single
frame here and there in, I get reasonably consistent 30mbit
performance each way, which is what I'm expecting without A-MPDU or
A-MSDU aggregation.

But if I schedule say, 5 groups of 32 frames and then one frame, the
PCU/QCU doesn't seem to grant that queue any more airtime until I push
/another/ frame into the TX FIFO. Merely just hitting TXE for that
queue doesn't work - I have to push in more frames to keep it
immediately going rather than waiting for the next TXOP/gating time.

So, I have some local hacks that only push groups of X (where X is 16
atm) frames into TX FIFO slots to keep the engine happy and will only
push a shorter amount of frames into the TX FIFO if the FIFO itself is
empty. That gets the performance on part with TDMA on AR5416/AR9280,
which was the initial goal.

Ok, so with all of the above - has anyone seen this kind of behaviour
with ath9k? eg, doing lots of non-aggregate frames to some WMM burst
queue, like voice or video?

Thanks,

-adrian
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.