- 28 11月, 2014 1 次提交
-
-
由 Felix Fietkau 提交于
Preparation for adding a no-skb tx status path Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 20 11月, 2014 1 次提交
-
-
由 Felix Fietkau 提交于
Check the queue mapping earlier, skb->queue_mapping is more likely than skb->data to still be in d-cache. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 27 10月, 2014 1 次提交
-
-
由 Karl Beldan 提交于
When CONFIG_MAC80211_RC_MINSTREL_VHT is set, the module param minstrel_vht_only tells minstrel_ht whether to allow the mix of ht rates with vht rates. ATM, minstrel_ht skips ht rates when minstrel_vht_only is true, but it does that even if vht is not supported, which makes the sta rates fallback to legacy as no ht rate gets enabled. Fixes: 9208247d ("mac80211: minstrel_ht: add basic support for VHT rates <= 3SS@80MHz") Signed-off-by: NKarl Beldan <karl.beldan@rivierawaves.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 21 10月, 2014 4 次提交
-
-
由 Karl Beldan 提交于
When the new CONFIG_MAC80211_RC_MINSTREL_VHT is not set (default 'N'), there is no behavioral change including in sampling and MCS_GROUP_RATES remains 8. Otherwise MCS_GROUP_RATES is 10, and a module parameter *vht_only* (default 'true'), restricts the rates selection to VHT when VHT is supported. Regarding the debugfs stats buffer: It is explicitly increased from 8k to 32k to fit every rates incl. when both HT and VHT rates are enabled, as for the format, before: type rate tpt eprob *prob ret *ok(*cum) ok( cum) HT20/LGI ABCDP MCS0 0.0 0.0 0.0 1 0( 0) 0( 0) after: type rate tpt eprob *prob ret *ok(*cum) ok( cum) HT20/LGI ABCDP MCS0 0.0 0.0 0.0 1 0( 0) 0( 0) VHT40/LGI MCS5/2 0.0 0.0 0.0 0 0( 0) 0( 0) Signed-off-by: NKarl Beldan <karl.beldan@rivierawaves.com> Cc: Felix Fietkau <nbd@openwrt.org> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Karl Beldan 提交于
ATM, we grep cck rates idx with idx / MCS_GROUP_RATES == MINSTREL_CCK_GROUP. Matching neither-cck-non-ht rates could be done by replacing '==' with '>', however it would be less versatile or explicit. This will allow to match VHT rates with IEEE80211_TX_RC_VHT_MCS. Signed-off-by: NKarl Beldan <karl.beldan@rivierawaves.com> Cc: Felix Fietkau <nbd@openwrt.org> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Karl Beldan 提交于
No functional change. Signed-off-by: NKarl Beldan <karl.beldan@rivierawaves.com> Cc: Felix Fietkau <nbd@openwrt.org> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Karl Beldan 提交于
Since 5935839a ("mac80211: improve minstrel_ht rate sorting by throughput & probability"), the rate indexes are manipulated via u8's and hence allow for a maximum of 256 mcs_group entries in minstrel_mcs_groups. ATM, minstrel_ht advertizes support up to 3HTSS@40MHz, consuming: 8(MCS_GROUP_RATES) * (3(SS)*2(GI)*2(BW)+1(CCK)), i.e. 104 entries. Support for 3VHTSS@80MHz will require: 10(MCS_GROUP_RATES) * (3(SS)*2(GI)*2(BW)+1(CCK)) + 10(MCS_GROUP_RATES) * (3(SS)*2(GI)*3(BW)), i.e. 130 + 180 entries. This change moves from u8s to u16s where necessary. Signed-off-by: NKarl Beldan <karl.beldan@rivierawaves.com> Cc: Felix Fietkau <nbd@openwrt.org> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 09 10月, 2014 1 次提交
-
-
由 Karl Beldan 提交于
Commit 5935839a ("mac80211: improve minstrel_ht rate sorting by throughput & probability") replaced the constant 8 with MCS_GROUP_RATES when getting the number of streams of an HT MCS. See commit 7a5e3fa2 ("mac80211: minstrel_ht: replace some occurences of MCS_GROUP_RATES"). Fixes: 5935839a ("mac80211: improve minstrel_ht rate sorting by throughput & probability") Signed-off-by: NKarl Beldan <karl.beldan@rivierawaves.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 11 9月, 2014 1 次提交
-
-
由 Thomas Huehn 提交于
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-loop. 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 C the 4th fastest. Signed-off-by: NThomas Huehn <thomas@net.t-labs.tu-berlin.de> Tested-by: NStefan Venz <ikstream86@gmail.com> Acked-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 21 5月, 2014 1 次提交
-
-
由 Antonio Quartulli 提交于
Add get_expected_throughput() API to mac80211 so that each driver can implement its own version based on the RC algorithm they are using (might be using an HW RC algo). The API returns a value expressed in Kbps. Also, add the new get_expected_throughput() member to the rate_control_ops structure in order to be able to query the RC algorithm (this patch provides an implementation of this API for both minstrel and minstrel_ht). The related member in the station_info object is now filled accordingly when dumping a station. Cc: Felix Fietkau <nbd@openwrt.org> Signed-off-by: NAntonio Quartulli <antonio@open-mesh.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 19 5月, 2014 1 次提交
-
-
由 Johannes Berg 提交于
Antonio and I were looking over this code and some things didn't immediately make sense, so we came up with two small clarifications. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 05 2月, 2014 2 次提交
-
-
由 Johannes Berg 提交于
The sample table is initialized only once at module start, so is really __read_mostly. Additionally, the code to init it can be marked __init since it will never be needed again, it is likely automatically inlined into the __init function already by the compiler, so this doesn't really make a difference. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
Change the code to allow making all the rate control ops const, nothing ever needs to change them. Also change all drivers to make use of this and mark the ops const. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 18 12月, 2013 1 次提交
-
-
由 Weilong Chen 提交于
Fix a number of different checkpatch errors. Signed-off-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 26 11月, 2013 3 次提交
-
-
由 Karl Beldan 提交于
ATM minstrel_ht does not check whether a sampling rate is supported. Unsupported rates attempts can trigger when there are holes in bitfields of supported MCSes belonging to the same group (e.g many devices are MCS32 capable without MCS33->39 capable, also we systematically have a hole for CCK rates). Drop any attempts to sample unsupported rates, as suggested by Felix. This is not a problem in minstrel which fills a per STA sample table with only supported rates (though only at init). Signed-off-by: NKarl Beldan <karl.beldan@rivierawaves.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Karl Beldan 提交于
ATM, only the first array value returned by get_random_bytes is used. This change moves the call to get_random_bytes from the nested loop it is in to its parent. While at it, replace get_random_bytes with prandom_bytes since PRNs are way enough for the selection process. After this, minstrel_ht reclaims 80 PR-bytes instead of 640 R-bytes. minstrels use sample tables to probe different rates in a randomized manner. minstrel_ht inits one single sample table upon registration (during subsys_initcalls) and minstrel uses one per STA addition in minstrel. Signed-off-by: NKarl Beldan <karl.beldan@rivierawaves.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Karl Beldan 提交于
Consecutive MCSes in [8*(NSS-1)->8*NSS[ have the same number NSS of streams (except for MCS32 which is mishandled ATM). ATM minstrel_ht uses MCS_GROUP_RATES in place of this 8 modulus. This change replaces such occurences and by doing so allows for different values of MCS_GROUP_RATES (e.g to cope with VHT MCS8,9). Signed-off-by: NKarl Beldan <karl.beldan@rivierawaves.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 25 11月, 2013 2 次提交
-
-
由 Karl Beldan 提交于
Commit 3e8b1eb2 "mac80211/minstrel_ht: improve rate selection stability" introduced a local capped prob in minstrel_ht_calc_tp but omitted to use it to compute the per rate throughput. Signed-off-by: NKarl Beldan <karl.beldan@rivierawaves.com> Cc: Felix Fietkau <nbd@openwrt.org> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Karl Beldan 提交于
When initializing rates selections starting indexes upon stats update, the minstrel_sta->max_* rates should be 'group * MCS_GROUP_RATES + i' not 'i'. This affects settings where one of the peers does not support any of the rates of the group 0 (i.e. when ht_cap.mcs.rx_mask[0] == 0). Signed-off-by: NKarl Beldan <karl.beldan@rivierawaves.com> Acked-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 26 9月, 2013 1 次提交
-
-
由 Lorenzo Bianconi 提交于
Do not override max_tp_rate, max_tp_rate2 and max_prob_rate configured according to fixed_rate in minstrel_ht_update_stats throughput computation Signed-off-by: NLorenzo Bianconi <lorenzo.bianconi83@gmail.com> Acked-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 22 8月, 2013 1 次提交
-
-
由 Johannes Berg 提交于
Sujith reports that my commit af61a165 ("mac80211: add control port protocol TX control flag") broke ath9k (aggregation). The reason is that I made minstrel_ht use the flag in the TX status path, where it can have been overwritten by the driver. Since we have no more space in info->flags, revert that part of the change for now, until we can reshuffle the flags or so. Reported-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 21 8月, 2013 1 次提交
-
-
由 Felix Fietkau 提交于
brcm80211 cannot handle sending frames with CCK rates as part of an A-MPDU session. Other drivers may have issues too. Set the flag in all drivers that have been tested with CCK rates. This fixes a reported brcmsmac regression introduced in commit ef47a5e4f1aaf1d0e2e6875e34b2c9595897bef6 "mac80211/minstrel_ht: fix cck rate sampling" Cc: stable@vger.kernel.org # 3.10 Reported-by: NTom Gundersen <teg@jklm.no> Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 12 8月, 2013 1 次提交
-
-
由 Johannes Berg 提交于
A lot of drivers check the frame protocol for ETH_P_PAE, for various reasons (like making those more reliable). Add a new flags bitmap to the TX control info and a new flag indicating the control port protocol is in use to let all drivers also apply such logic to other control port protocols, should they be configured. Also use the new flag in the iwlwifi drivers. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 16 7月, 2013 3 次提交
-
-
由 Simon Wunderlich 提交于
according to IEEE 802.11-2012 section 18, various timings change when using 5 MHz and 10 MHz. Reflect this by using a "shift" when calculating durations. Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: NMathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de> Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
-
由 Simon Wunderlich 提交于
5 and 10 MHz support needs to know the current operating channel width, add the chandef to the rate control API. Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: NMathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de> Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
-
由 Felix Fietkau 提交于
The CCK group needs special treatment to set the right flags and rate index. Add this missing check to prevent setting broken rates for tx packets. Cc: stable@vger.kernel.org # 3.10 Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
-
- 22 4月, 2013 3 次提交
-
-
由 Felix Fietkau 提交于
Pass the rate selection table to mac80211 from minstrel_ht_update_stats. Only rates for sample attempts are set in info->control.rates. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Karl Beldan 提交于
Initialize {mp,mi}->{max_tp_rate,max_tp_rate2,max_prob_rate} in minstrel_ht's rate_init and rate_update. Signed-off-by: NKarl Beldan <karl.beldan@rivierawaves.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Karl Beldan 提交于
minstrel_ht initializes max_tp_rate max_tp_rate2 and max_prob_rate to zero both for minstrel_ht_sta and minstrel_mcs_group_data. This is wrong since there is no guarantee that the 1st rate of any group is supported. Signed-off-by: NKarl Beldan <karl.beldan@rivierawaves.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 19 3月, 2013 3 次提交
-
-
由 Felix Fietkau 提交于
max_tp_rate2 and max_prob_rate tend to get used occasionally during retransmission, which is more useful for the statistics than probing with individual probe packets. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Felix Fietkau 提交于
Slow rates that have >95% success probability do not need to be monitored continuously. When the channel conditions change rapidly, the slow sampling results are useless anyway. When conditions change slowly, they will be monitored by gradual downgrading of the actively used rates. This patch slightly improves throughput under good conditions. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Felix Fietkau 提交于
Under load, otherwise stable rates can easily fluctuate because of collisions. In my tests on a clean channel, the success probability of the max throughput rate often stays somewhere between 90% and 100% under load. This can cause some unnecessary switching to lower rates. This patch improves stability by treating success probability values between 90% and 100% the same. In my tests on a 3x3 HT20 link with lots of TCP traffic, it improves the average throughput by a few mbit/s. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 06 3月, 2013 8 次提交
-
-
由 Thomas Huehn 提交于
While minstrel bootstraps and fills the success probabilities of each rate the lowest rate has typically a very high success probability (often 100% in our tests). Its statistics are never updated but considered to setup the mrr chain. In our tests we see that especially the 3rd mrr stage (which is that rate providing highest success probability) is filled with the lowest rate because its initial high sucess probability is never updated. By design the 4th mrr stage is filled with the lowest rate so often 3rd and 4th mrr stage are equal. This patch follows minstrels general approach of assuming as little as possible about rate dependencies. Consequently we include the lowest rate into the random sampling table to get balanced up-to-date statistics of all rates and therefore balanced decisions. Acked-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NThomas Huehn <thomas@net.t-labs.tu-berlin.de> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Thomas Huehn 提交于
Both rate control algorithms (minstrel and minstrel_ht) calculate averages based on EWMA. Shift function minstrel_ewma() into rc80211_minstrel.h and make use of it in both minstrel version. Also shift the default EWMA level (75%) definition to the header file and clean up variable usage. Acked-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NThomas Huehn <thomas@net.t-labs.tu-berlin.de> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Felix Fietkau 提交于
The last minstrel_ht changes increased the sampling frequency for potentially useful rates to decrease the response time to rate fluctuations. This caused an increase in sampling frequency that can slightly reduce throughput, so this patch limits the sampling attempts to one per rate instead of two. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Felix Fietkau 提交于
A sample attempt should only count in mi->sample_tries if the sample attempt wasn't skipped based on slower rate criteria. This patch increases the sampling frequency for potentially desirable rates and thus enables faster recovery from interference or collisions. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Felix Fietkau 提交于
If a rate is below the max_tp_rate, sample it frequently if: - it is above max_tp_rate2, or - it is above max_prob_rate and is a candidate for max_prob_rate (has fewer streams than max_tp_rate). This helps the retry chain recover more quickly from bad statistics caused by collisions or interference, and slightly reduces throughput fluctuations with higher rates. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Felix Fietkau 提交于
Try to sample all available rates, as sample attempts do not cost much airtime and are appropriately spaced based on the average A-MPDU length. This helps with faster recovery on rate fluctuations. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Felix Fietkau 提交于
max_prob_rate should be selected to be very reliable, however limiting it to single-stream on 3-stream devices is a bit much. Allow max_prob_rate to use one stream less than the max_tp_rate. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Felix Fietkau 提交于
At high data rates the average frame transmission durations are small enough for rounding errors to matter, sometimes causing minstrel to use slightly lower transmit rates than necessary. To fix this, change the unit of the duration value to nanoseconds instead of microseconds, and reorder the multiplications/divisions when calculating the throughput metric so that they don't overflow or truncate prematurely. At 2-stream HT40 this makes TCP throughput a bit more stable. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-