Hi Luiz,
I am working on per packet power control and introduce therfore additional data
structureswithin
the mac80211 ieee80211_tx_info struct to have the power control algorith
running in the mac layer, I had also
to change the drivers in order to set the power level in the driver
Hi Luiz,
I am working on per packet power control and introduce therfore additional data
structureswithin
the mac80211 ieee80211_tx_info struct to have the power control algorith
running in the mac layer, I had also
to change the drivers in order to set the power level in the driver
Hi all,
Today I’ve released my WiFi register monitoring tool RegMon on GitHub:
https://github.com/thuehn/RegMon
RegMon consists of Atheros driver patches to monitor arbitrary registers under
ath9k, ath5k and madwifi from user space with high sampling rates (up to
~20kHz). My common research
Hi Jouni,
In case of ath9k, the driver in xmit.c allocates in function
ath_tx_fill_desc() a struct ath_tx_info info by memset(info, 0,
sizeof(info)) .. so all info-rates[xy].Rate == 0.
Than function ath_buf_set_rate() sets all info-rates[xy].Rate to those
values specified in the rate
Hi Jouni,
Currently Minstrel_HT just skips EAPOL packets for its rate sampling on non-mrr
chips by testing: (info-control.flags IEEE80211_TX_CTRL_PORT_CTRL_PROTO)
On mrr hardware it uses them for probing.
But the general MRR-chain should look like this for ath5k and ath9k chips that
support 4
Hi Jouni,
Currently Minstrel_HT just skips EAPOL packets for its rate sampling on non-mrr
chips by testing: (info
http://lxr.free-electrons.com/ident?i=info-control.flags
http://lxr.free-electrons.com/ident?i=flags
IEEE80211_TX_CTRL_PORT_CTRL_PROTO)
On mrr hardware it uses them for probing.
Hi Jouni,
Where is that mrr[3] part implemented? I did not find it when reviewing
the design (hw-max_rates = 3 is used, but not = 4) and this does not
match my experiments either when printing out all four values from
ath9k. In every single case I observed, the last entry was unused (idx =
Hi Hubert,
From my point of view the call-path of the functions look like this:
ath9k_init_queues
http://lxr.free-electrons.com/ident?i=ath9k_init_queues(struct ath_softc
http://lxr.free-electrons.com/ident?i=ath_softc *sc
http://lxr.free-electrons.com/ident?i=sc)
- ath_txq_setup
Hi Sergey,
You are right, the wrong mapping was caused by the call order.
Felix has already sent 3 patches to fix that bug. So lets test.
Greetings from Berlin
Thomas
Am 30.11.2014 um 19:18 schrieb Sergey Ryazanov ryazanov@gmail.com:
Hi Thomas,
2014-11-30 14:30 GMT+03:00 Thomas
Hi Lozenro,
As I am shaping up my TPC code and might comment as well :)
What about defining just:
#define AR_XmitPower0x003f
#define AR_XmitPower_S 16
#define AR_XmitPower2 0x3f00
#define AR_XmitPower2_S24
.. as AR_XmitPower1 == AR_XmitPower2 ==
Hi Lorenzo,
My comments are inline.
Add dynamic ack timeout estimation algorithm based on ack frame RX timestamp,
TX frame timestamp and frame duration.
Signed-off-by: Lorenzo Bianconi lorenzo.biancon...@gmail.com
---
drivers/net/wireless/ath/ath.h | 2 +
Hi Simon,
You said that even manually setting MC14 or MC15 as static rate fails. So seems
that it is not an issue at the mac layer rather than the phy layer.
I had once something similar on ath5k, where the power curves got not properly
assigned to high rates.
So just in case, could you check
HI Adrian,
Thx for those TPC info. I am currently adapting my Minstrel-Blues to include
ath9k.
Bye Thomas
On 20.04.2013, at 16:46, Adrian Chadd adr...@freebsd.org wrote:
Hi all,
The idea of correct per-packet TPC for ath9k chips has come up from
time to time.
I decided to get it
Hi Ben,
Any idea how feasible it is to do per-vif tx-power in ath9k? I think
it would come down to putting the desired tx-power into each packet
(as the VIF sends it towards the driver) and then changing the power
as packets were transmitted in the NIC...
No need for 'changing the power as
14 matches
Mail list logo
