Re: Configuring Minstrel-Blues

[Thomas Hühn]

Hi Mike,

I am working on the Minstrel-Blues part to get it integrated into minstrel_ht. 
My working demo is with ath5k an legacy minstrel.
As soon as I have a testing patch, I am going to announce it here.

Greetings from Berlin
Thomas

> On 15 Aug 2016, at 23:41, Mike Mu  wrote:
> 
> Hi Linux-Wireless,
> 
> I am trying to enable Minstrel-Blues for the ath9k chipset that's used
> in Google Fiber's access points. I applied the patches in
> https://github.com/thuehn/Minstrel-Blues/tree/master/src onto our
> backports-20160122 tree, with some unsuspicious merge conflicts, and
> built an image.
> 
> To test, I ran iperf from the AP to a station very close by. I
> captured the packets to look at the RSSI with and without the
> Minstrel-Blues patches applied, but did not see any difference in
> RSSI.
> 
> Is there anything I need to configure first to make it work? Is it
> possible that I'm missing a patch that's not in backports-20160122?
> 
> Thanks!
> Mike

Release of RegMon - a fast in-kernel phy/mac dmonitoring tool for QCA/Atheros WiFi cards

[Thomas Hühn]

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 use case is the fine-grained monitoring and 
analysis of all busy states (tx, rx, energy detection  idle), TSF and noise 
floor of the mac/phy layer from an Atheros WiFi card. But it can be used to 
sample any available register (like NAV, error registers, ect.).
There are also a bunch of scripts in the repo to set-up a wireless experiment, 
collect RegMon traces, parse, merge and plot them with R.

Feel free to use and change RegMon for your own purpose. As RegMon is still 
work in progress I am happy to receive and include your feedback and ideas.

Greetings from Berlin
Thomas

Re: [ath9k-devel] AR9462 problems connecting again..

[Thomas Hühn]

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 mrr chains:

mrr[0]:= max_tp_rate[0]
mrr[1]:= max_tp_rate[1]
mrr[2]:= max_prob_rate
mrr[3]:= basic_rate

So for Minstrel Sampling Packets as well as for data packets, the 4th mrr stage 
should use the slowest rate in case all other 3 mrr stages failed with their 
retry attempts.

I do see two possible options for control frames like EAPOL to be send out in a 
more robust fashion:
 - exclude those frames from AMPDU aggragates 
 - change their mrr setup to be more conservative

What do you think about this ?

Greetings Thomas


 Am 24.02.2015 um 11:26 schrieb Jouni Malinen j...@w1.fi:
 
 On Tue, Feb 24, 2015 at 01:29:27PM +1100, Andrew McGregor wrote:
 Over the weekend I found a bug in minstrel-ht that might well be
 implicated here.
 
 The last retransmit rate is meant to be a 'get the packet there
 reliably' rate; minstrel-ht doesn't do that right, and can pick a
 fairly flaky rate instead.
 
 Can't generate a proper patch right now, so this diff might not apply
 cleanly, but the fix is simply to change 75 to 99 in the two places
 below:
 
 While this may indeed be helpful, I don't think it is sufficient for
 this EAPOL frame related issue. What I would like to see is minstrel_ht
 using a basic rate (something non-HT) at the end of the retry series for
 EAPOL frames.
 
 The current behavior looks very suspicious to me. The early EAPOL frames
 after association are being used to probe for higher rates. This results
 in the total number of retry attempts actually getting smaller than any
 other frame, i.e., minstrel_ht seems to be using significantly _less_
 robust choices for the EAPOL frames than following normal data frames!
 This should really be the other way around..
 
 As an example, I'm seeing this on 5 GHz band (with the 75 to 99 change
 in place, but behavior was more or less identical without it):
 - the first EAPOL frame (msg 2/4) getting one attempt at MCS 3, 2
  attempts at MCS 0, 2 attempts at MCS 0 (yes, identical to the previous
  one) with total maximum of 5 attempts
 - the second EAPOL frame (msg 4/4) getting one attempt at MCS 9, 2
  attempts at MCS 0, 2 attempts at MCS 0 with total maximum of 5
  attempts
 - another data frame after this: 5 attempts at MCS 9, 5 attempts at MCS
  3, 5 attempts at MCS 3 with total maximum of 15 attempts(!!)
 
 This cannot be the best approach here.. For the
 IEEE80211_TX_CTRL_PORT_CTRL_PROTO cases, there are identified issues
 where failing to deliver the frame results is significant issues either
 in getting connected in the first place or getting disconnected if
 rekeying fails. 
 
 I'm not sure how this would be implemented cleanly in minstrel_ht or
 whether that is even the best place (i.e., rate.c could do this
 instead), but I'd like that third attempt for control port cases to be
 dropped to use a (lowish) basic rate and non-MCS at that since there may
 be some interop issues with HT MCS early during association.
 Alternatively with drivers like ath9k that support 4 rate values, it
 would also be fine to add this basic rate attempt (or well, I'd have
 multiple, say 4, such attempts) as an additional 4th entry which does
 not currently seem to get used with minstrel at all.
 
 The (lowish) basic rate here could be defined as 6 Mbps OFDM for 5 GHz
 band and either that or maybe even 2 Mbps or 5.5 Mbps on 2.4 GHz (if
 included by the AP in basic rate set).
 
 -- 
 Jouni MalinenPGP id EFC895FA
 ___
 ath9k-devel mailing list
 ath9k-de...@lists.ath9k.org
 https://lists.ath9k.org/mailman/listinfo/ath9k-devel

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ath9k-devel] AR9462 problems connecting again..

[Thomas Hühn]

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 =
 -1) and only MCS values were used (i.e., not even a single case of basic
 rate visible; basic rates being 6, 12, 24 Mbps OFDM in this specific
 case with the AP that I used in the tests).

Minstrel_HT does only set mrr[0..2] and does not touch the fourth mrr[3], 
assumed chips with 4 mrr stages.
In function minstrel_ht_update_rates() the rate table struct 
ieee80211_sta_rates is set for the first 3 out of 4 rates and the fouth rate 
(mrr[3]) is „-1“.
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 table (struct ieee8021_sta_rate) IF (!rates[i].count || 
(rates[i].idx  0)) …
… so info-rates[3].Rate is untouched and still  „0“.

I just added a printk() to xmit.c in function ath_tx_fill_desc() just before 
ath9k_hw_set_txdesc() is called.
From the log I get, e.g.:

[  169.543554] mrr setup: mrr[0]:133 mrr[1]:132 mrr[2]:134 mrr[3]:0 

I have not check yet if info-rates[3].Rate == 0 is the lowest possible rate… 
but I would guess so.


Greetings Thomas

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] mac80211: improve minstrel_ht rate sorting by throughput probability

[Thomas Hühn]

Hi Felix,

Thank you for your review. I will send a v2 to fix all issues mentioned.

Greetings Thomas

On 08.09.2014, at 18:29, Felix Fietkau n...@openwrt.org wrote:

 On 2014-08-22 16:05, Thomas Huehn wrote:
 This patch improves the way minstrel_ht sorts rates according to throughput
 and success probability. 3 FOR-loops across the entire rate and mcs group set
 in function minstrel_ht_update_stats() which where used to determine the
 fastest, second fastest and most robust rate are reduced to 2 FOR-loops.
 
 The sorted list of rates according throughput is extended to the best four
 rates as we need them in upcoming joint rate and power control. The sorting
 is done via the new function minstrel_ht_sort_best_tp_rates(). The annotation
 of those 4 best throughput rates in the debugfs file rc-stats is changes to:
 A,B,C,D, where A is the fastest rate and D the 4th fastest.
 
 Signed-off-by: Thomas Huehn tho...@net.t-labs.tu-berlin.de
 Tested-by: Stefan Venz ikstrea...@gmail.com
 ---
 net/mac80211/rc80211_minstrel_ht.c | 215 
 -
 net/mac80211/rc80211_minstrel_ht.h |  17 +--
 net/mac80211/rc80211_minstrel_ht_debugfs.c |   8 +-
 3 files changed, 128 insertions(+), 112 deletions(-)
 
 diff --git a/net/mac80211/rc80211_minstrel_ht.c 
 b/net/mac80211/rc80211_minstrel_ht.c
 index 85c1e74..7f03c01 100644
 --- a/net/mac80211/rc80211_minstrel_ht.c
 +++ b/net/mac80211/rc80211_minstrel_ht.c
 @@ -228,8 +227,47 @@ minstrel_ht_calc_tp(struct minstrel_ht_sta *mi, int 
 group, int rate)
  nsecs += minstrel_mcs_groups[group].duration[rate];
 
  /* prob is scaled - see MINSTREL_FRAC above */
 -tp = 100 * ((prob * 1000) / nsecs);
 -mr-cur_tp = MINSTREL_TRUNC(tp);
 +mr-cur_tp = 100 * ((prob * 1000) / nsecs);
 +}
 +
 +/*
 + * Find  sort topmost throughput rates
 + *
 + * If multiple rates provide equal throughput the sorting is based on their
 + * current success probability. Higher success probability is preferred 
 among
 + * MCS groups, CCK rates do not provide aggregation and are therefore at 
 last.
 + */
 +static inline void
 You should drop the 'inline'
 
 +minstrel_ht_sort_best_tp_rates(struct minstrel_ht_sta *mi, unsigned int 
 index,
 +   unsigned int *tp_list)
 +{
 +int j = MAX_THR_RATES;
 +unsigned int cur_group, cur_idx, cur_thr, cur_prob;
 +unsigned int tmp_group, tmp_idx;
 +
 +cur_group = index / MCS_GROUP_RATES;
 +cur_idx = index % MCS_GROUP_RATES;
 +cur_thr = mi-groups[cur_group].rates[cur_idx].cur_tp;
 +cur_prob = mi-groups[cur_group].rates[cur_idx].probability;
 +tmp_group = tp_list[j - 1] / MCS_GROUP_RATES;
 +tmp_idx = tp_list[j - 1] % MCS_GROUP_RATES;
 +
 +
 +while (j  0  (cur_thr  mi-groups[tmp_group].rates[tmp_idx].cur_tp 
 ||
 +   (cur_thr == mi-groups[tmp_group].rates[tmp_idx].cur_tp 
 +   cur_prob  mi-groups[tmp_group].rates[tmp_idx].probability 
 +   cur_group != MINSTREL_CCK_GROUP))) {
 Missing one whitespace in indentation in the above two lines
 +j--;
 +tmp_group = tp_list[j - 1] / MCS_GROUP_RATES;
 +tmp_idx = tp_list[j - 1] % MCS_GROUP_RATES;
 One tab too many.
 I think it would probably make the code more readable if you just do
 while (j  0) { ... } and move the other checks inside the block.
   
 
 +}
 +
 +if (j  MAX_THR_RATES - 1) {
 +memmove(tp_list[j + 1], tp_list[j], (sizeof(*tp_list) *
 +   (MAX_THR_RATES - (j + 1;
 +}
 +if (j  MAX_THR_RATES)
 +tp_list[j] = index;
 }
 
 /*
 
 @@ -274,24 +312,17 @@ minstrel_ht_update_stats(struct minstrel_priv *mp, 
 struct minstrel_ht_sta *mi)
 
  mi-sample_count++;
 
 +/* (re)Initialize group rate indexes */
 +for(j = 0; j  MAX_THR_RATES; j++){
 +tmp_group_tp_rate[j] = group;
 +}
 You can drop the {} here.
 
 
 @@ -300,82 +331,72 @@ minstrel_ht_update_stats(struct minstrel_priv *mp, 
 struct minstrel_ht_sta *mi)
 [...]
 
 +/* try to sample all available rates during each interval */
 +mi-sample_count *= 8;
 +
 #ifdef CONFIG_MAC80211_DEBUGFS
  /* use fixed index if set */
  if (mp-fixed_rate_idx != -1) {
 -mi-max_tp_rate = mp-fixed_rate_idx;
 -mi-max_tp_rate2 = mp-fixed_rate_idx;
 +for (i = 0; i  4; i++) {
 +mi-max_tp_rate[i] = mp-fixed_rate_idx;
 +}
 You can drop the {}
  mi-max_prob_rate = mp-fixed_rate_idx;
  }
 #endif
 
 +/* Reset update timer */
  mi-stats_update = jiffies;
 }
 
 @@ -735,8 +756,8 @@ minstrel_get_sample_rate(struct minstrel_priv *mp, 
 struct minstrel_ht_sta *mi)
   * if the link is working perfectly.
   */
  sample_dur = minstrel_get_duration(sample_idx);
 -if (sample_dur = minstrel_get_duration(mi-max_tp_rate2) 
 -(mi-max_prob_streams 
 +if (sample_dur =