[OpenWrt-Devel] [PATCH] Improve wifi speed up to 2 times in AP mode.

2015-06-28 Thread N.Leiten 
Hi.

There's some general problem in hostapd configuration for several devices
was observed. In vanilla trunk versions of openwrt I got nearly 40-45Mbit/s
speed on Ralink RT5350 based devices and Atheros AR71xx platform (tp-link
wr841nd). The problem was in /var/run/hostapd-phy0.conf. It seems it is not
enough just set 'wmm_enable=1' to actually enable WME/WMM on interface, it
also need all WMM related keys be set. So I just added it with standart
definitions from hostapd.conf to /lib/netifd/hostapd.sh.

As a result I got full 100Mbit/s on AR71XX platform and 70-80Mbit on
Ralink. I think it is good performance improvement at this moment.

Patch was created against current trunk version.
diff -c -r a/package/network/services/hostapd/files/netifd.sh b/package/network/services/hostapd/files/netifd.sh
*** a/package/network/services/hostapd/files/netifd.sh	2015-06-09 15:00:07.0 +0300
--- b/package/network/services/hostapd/files/netifd.sh	2015-06-28 21:01:39.054827123 +0300
***
*** 207,212 
--- 207,235 
  	append bss_conf "disassoc_low_ack=$disassoc_low_ack" "$N"
  	append bss_conf "preamble=$short_preamble" "$N"
  	append bss_conf "wmm_enabled=$wmm" "$N"
+ 	if [ "$wmm" -gt 0 ];then
+ 		append bss_conf "wmm_ac_bk_cwmin=4" "$N"
+ 		append bss_conf "wmm_ac_bk_cwmax=10" "$N"
+ 		append bss_conf "wmm_ac_bk_aifs=7" "$N"
+ 		append bss_conf "wmm_ac_bk_txop_limit=0" "$N"
+ 		append bss_conf "wmm_ac_bk_acm=0" "$N"
+ 		append bss_conf "wmm_ac_be_aifs=3" "$N"
+ 		append bss_conf "wmm_ac_be_cwmin=4" "$N"
+ 		append bss_conf "wmm_ac_be_cwmax=10" "$N"
+ 		append bss_conf "wmm_ac_be_txop_limit=0" "$N"
+ 		append bss_conf "wmm_ac_be_acm=0" "$N"
+ 		append bss_conf "wmm_ac_vi_aifs=2" "$N"
+ 		append bss_conf "wmm_ac_vi_cwmin=3" "$N"
+ 		append bss_conf "wmm_ac_vi_cwmax=4" "$N"
+ 		append bss_conf "wmm_ac_vi_txop_limit=94" "$N"
+ 		append bss_conf "wmm_ac_vi_acm=0" "$N"
+ 		append bss_conf "wmm_ac_vo_aifs=2" "$N"
+ 		append bss_conf "wmm_ac_vo_cwmin=2" "$N"
+ 		append bss_conf "wmm_ac_vo_cwmax=3" "$N"
+ 		append bss_conf "wmm_ac_vo_txop_limit=47" "$N"
+ 		append bss_conf "wmm_ac_vo_acm=0" "$N"
+ 	fi
+ 
  	append bss_conf "ignore_broadcast_ssid=$hidden" "$N"
  	append bss_conf "uapsd_advertisement_enabled=$uapsd" "$N"
  
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] Improve wifi speed up to 2 times in AP mode.

2015-06-28 Thread N.Leiten 
The thing is - this parameters I've got from hostapd.conf on my host
machine and due to comments they are strictly set from 802.11. As for
hostapd itself, I don't gone in deep inspection of WMM part but I saw
some default values regarding tx_queue* parameters (according to
comments this section is used to prioritize traffic from AP to STAs,
and WMM part is in opposite direction, in my oppinion last one is also
used to determine WMM capable stations which gives us such speed
improvements) in source code of hostapd, maybe there's some analogue
for WMM but somehow it don't get applied when configuration file
loaded. So for now the easiest and fast way to fix this is to set
config with parameters that hostapd expects.

2015-06-29 0:21 GMT+03:00 Linus Lüssing :
> On Sun, Jun 28, 2015 at 09:16:58PM +0300, N.Leiten wrote:
>> As a result I got full 100Mbit/s on AR71XX platform and 70-80Mbit on
>> Ralink. I think it is good performance improvement at this moment.
>
> Interesting, thanks for sharing your results!
>
> If these settings are generally diserable, maybe it might make
> sense to patch hostapd to set them by default if they aren't set
> explicitly, instead of through netifd? That way anyone, not only
> OpenWRT users might benefit from it.
>
> Cheers, Linus
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] Improve wifi speed up to 2 times in AP mode.

2015-06-29 Thread N.Leiten 
Resending patch in text format. Return of wmm_* parameters to
hostapd.conf file for wifi speed up.

2015-06-29 0:59 GMT+03:00 N.Leiten :
> The thing is - this parameters I've got from hostapd.conf on my host
> machine and due to comments they are strictly set from 802.11. As for
> hostapd itself, I don't gone in deep inspection of WMM part but I saw
> some default values regarding tx_queue* parameters (according to
> comments this section is used to prioritize traffic from AP to STAs,
> and WMM part is in opposite direction, in my oppinion last one is also
> used to determine WMM capable stations which gives us such speed
> improvements) in source code of hostapd, maybe there's some analogue
> for WMM but somehow it don't get applied when configuration file
> loaded. So for now the easiest and fast way to fix this is to set
> config with parameters that hostapd expects.
>
> 2015-06-29 0:21 GMT+03:00 Linus Lüssing :
>> On Sun, Jun 28, 2015 at 09:16:58PM +0300, N.Leiten wrote:
>>> As a result I got full 100Mbit/s on AR71XX platform and 70-80Mbit on
>>> Ralink. I think it is good performance improvement at this moment.
>>
>> Interesting, thanks for sharing your results!
>>
>> If these settings are generally diserable, maybe it might make
>> sense to patch hostapd to set them by default if they aren't set
>> explicitly, instead of through netifd? That way anyone, not only
>> OpenWRT users might benefit from it.
>>
>> Cheers, Linus
diff -c -r a/package/network/services/hostapd/files/netifd.sh b/package/network/services/hostapd/files/netifd.sh
*** a/package/network/services/hostapd/files/netifd.sh	2015-06-09 15:00:07.0 +0300
--- b/package/network/services/hostapd/files/netifd.sh	2015-06-28 21:01:39.054827123 +0300
***
*** 207,212 
--- 207,235 
  	append bss_conf "disassoc_low_ack=$disassoc_low_ack" "$N"
  	append bss_conf "preamble=$short_preamble" "$N"
  	append bss_conf "wmm_enabled=$wmm" "$N"
+ 	if [ "$wmm" -gt 0 ];then
+ 		append bss_conf "wmm_ac_bk_cwmin=4" "$N"
+ 		append bss_conf "wmm_ac_bk_cwmax=10" "$N"
+ 		append bss_conf "wmm_ac_bk_aifs=7" "$N"
+ 		append bss_conf "wmm_ac_bk_txop_limit=0" "$N"
+ 		append bss_conf "wmm_ac_bk_acm=0" "$N"
+ 		append bss_conf "wmm_ac_be_aifs=3" "$N"
+ 		append bss_conf "wmm_ac_be_cwmin=4" "$N"
+ 		append bss_conf "wmm_ac_be_cwmax=10" "$N"
+ 		append bss_conf "wmm_ac_be_txop_limit=0" "$N"
+ 		append bss_conf "wmm_ac_be_acm=0" "$N"
+ 		append bss_conf "wmm_ac_vi_aifs=2" "$N"
+ 		append bss_conf "wmm_ac_vi_cwmin=3" "$N"
+ 		append bss_conf "wmm_ac_vi_cwmax=4" "$N"
+ 		append bss_conf "wmm_ac_vi_txop_limit=94" "$N"
+ 		append bss_conf "wmm_ac_vi_acm=0" "$N"
+ 		append bss_conf "wmm_ac_vo_aifs=2" "$N"
+ 		append bss_conf "wmm_ac_vo_cwmin=2" "$N"
+ 		append bss_conf "wmm_ac_vo_cwmax=3" "$N"
+ 		append bss_conf "wmm_ac_vo_txop_limit=47" "$N"
+ 		append bss_conf "wmm_ac_vo_acm=0" "$N"
+ 	fi
+ 
  	append bss_conf "ignore_broadcast_ssid=$hidden" "$N"
  	append bss_conf "uapsd_advertisement_enabled=$uapsd" "$N"
  
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] hostapd netifd wmm configuration for speedup wifi.

2015-06-30 Thread N.Leiten 
Speed up wifi up to 2 times in Access Point mode. On rt5350 platfrom I
got speed up from 35-40Mbit to 70-80Mbit, on ar71xx I got improvement
from 45Mbit to 100Mbit with this parameters set in hostapd.conf. It
seems that hostapd expects not only 'wmm_enabled=1' key but also
parameters for WMM.


Signed-off-by: Vadim Gamov 

diff -c -r a/package/network/services/hostapd/files/netifd.sh
b/package/network/services/hostapd/files/netifd.sh
*** a/package/network/services/hostapd/files/netifd.sh2015-06-09
15:00:07.0 +0300
--- b/package/network/services/hostapd/files/netifd.sh2015-06-30
11:55:34.905366123 +0300
***
*** 207,212 
--- 207,250 
  append bss_conf "disassoc_low_ack=$disassoc_low_ack" "$N"
  append bss_conf "preamble=$short_preamble" "$N"
  append bss_conf "wmm_enabled=$wmm" "$N"
+ if [ "$wmm" -gt 0 ];then
+ append bss_conf "wmm_ac_bk_cwmin=4" "$N"
+ append bss_conf "wmm_ac_bk_cwmax=10" "$N"
+ append bss_conf "wmm_ac_bk_aifs=7" "$N"
+ append bss_conf "wmm_ac_bk_txop_limit=0" "$N"
+ append bss_conf "wmm_ac_bk_acm=0" "$N"
+ append bss_conf "wmm_ac_be_aifs=3" "$N"
+ append bss_conf "wmm_ac_be_cwmin=4" "$N"
+ append bss_conf "wmm_ac_be_cwmax=10" "$N"
+ append bss_conf "wmm_ac_be_txop_limit=0" "$N"
+ append bss_conf "wmm_ac_be_acm=0" "$N"
+ append bss_conf "wmm_ac_vi_aifs=2" "$N"
+ append bss_conf "wmm_ac_vi_cwmin=3" "$N"
+ append bss_conf "wmm_ac_vi_cwmax=4" "$N"
+ append bss_conf "wmm_ac_vi_txop_limit=94" "$N"
+ append bss_conf "wmm_ac_vi_acm=0" "$N"
+ append bss_conf "wmm_ac_vo_aifs=2" "$N"
+ append bss_conf "wmm_ac_vo_cwmin=2" "$N"
+ append bss_conf "wmm_ac_vo_cwmax=3" "$N"
+ append bss_conf "wmm_ac_vo_txop_limit=47" "$N"
+ append bss_conf "wmm_ac_vo_acm=0" "$N"
+ fi
+ append bss_conf "tx_queue_data3_aifs=7" "$N"
+ append bss_conf "tx_queue_data3_cwmin=15" "$N"
+ append bss_conf "tx_queue_data3_cwmax=1023" "$N"
+ append bss_conf "tx_queue_data3_burst=0" "$N"
+ append bss_conf "tx_queue_data2_aifs=3" "$N"
+ append bss_conf "tx_queue_data2_cwmin=15" "$N"
+ append bss_conf "tx_queue_data2_cwmax=63" "$N"
+ append bss_conf "tx_queue_data2_burst=0" "$N"
+ append bss_conf "tx_queue_data1_aifs=1" "$N"
+ append bss_conf "tx_queue_data1_cwmin=7" "$N"
+ append bss_conf "tx_queue_data1_cwmax=15" "$N"
+ append bss_conf "tx_queue_data1_burst=3.0" "$N"
+ append bss_conf "tx_queue_data0_aifs=1" "$N"
+ append bss_conf "tx_queue_data0_cwmin=3" "$N"
+ append bss_conf "tx_queue_data0_cwmax=7" "$N"
+ append bss_conf "tx_queue_data0_burst=1.5" "$N"
  append bss_conf "ignore_broadcast_ssid=$hidden" "$N"
  append bss_conf "uapsd_advertisement_enabled=$uapsd" "$N"
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Where is the maximum binary size defined for each board?

2015-06-30 Thread N.Leiten 
Hi,

It is selected in target//image/Makefile.
Actually there's many rules for each target, so, probably you need to write own 
rule for own target there.

In email dated Вторник - 30 июня 2015 19:57:44 user Baptiste Clenet wrote:
> Hi,
> 
> By slecting a board in menuconfig, OpenWRT sets a maximum binary size
> for this specific board. Where is this maximum defined?
> Since I don't use the default flash, the maximum size is bigger.
> 
> Regards,
> 
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] For RG100A-AA, How to modify the default value of /etc/config/network?

2015-07-01 Thread N.Leiten 
There's two ways of default configuration - first is statically for all 
platforms in package/base-files/files/etc/config/network and using 
'uci-default' hooks.
The second type is used for target depended configurations (either different 
ports on switch as lan/wan or even different interfaces for lan/wan, migration 
between different version of firmware, etc). The scripts itself are executed 
every time at bootup, but deleted when they return zero code. So they're never 
executed twice if all gone ok. They are located in etc/uci-defaults. Generally 
they are gotten from target/linux//base-files/etc/uci-defaults 

In email dated Среда - 01 июля 2015 21:02:06 user zhengfish wrote:
> Hi, All
> 
> I'm using openwrt-14.07.
> 
> I want to modify the default value of /etc/config/network while I build the
> images for RG100A-AA.
> I tried to modify this file -- package/base-files/files/etc/config/network,
> but it seems have no effect.
> Which file should I modify?
> 
> 
> Here is my network by default on RG100A-AA.
> 
> # cat /etc/config/network
> 
> config interface 'loopback'
> option ifname 'lo'
> option proto 'static'
> option ipaddr '127.0.0.1'
> option netmask '255.0.0.0'
> 
> config globals 'globals'
> option ula_prefix 'fd4a:ad7a:34c0::/48'
> 
> config interface 'lan'
> option ifname 'eth1'
> option force_link '1'
> option type 'bridge'
> option proto 'static'
> option ipaddr '192.168.1.1'
> option netmask '255.255.255.0'
> option ip6assign '60'
> 
> config interface 'wan'
> option ifname 'eth0'
> option proto 'dhcp'
> 
> config interface 'wan6'
> option ifname '@wan'
> option proto 'dhcpv6'
> 
> config switch
> option name 'eth1'
> option reset '1'
> option enable_vlan '1'
> 
> config switch_vlan
> option device 'eth1'
> option vlan '1'
> option ports '0 1 2 3 4 5'
> 
> 
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] Improve wifi speed up to 2 times in AP mode.

2015-07-14 Thread N.Leiten 
Sorry, I must admit that there was a mistake in my tests.
Patch already declined.


In email dated Вторник - 14 июля 2015 22:43:36 user Daniel Petre wrote:
> On 06/28/2015 09:16 PM, N.Leiten wrote:
> > Hi.
> > 
> > There's some general problem in hostapd configuration for several devices 
> > was observed. In vanilla trunk versions of openwrt I got nearly 40-45Mbit/s 
> > speed on Ralink RT5350 based devices and Atheros AR71xx platform (tp-link 
> > wr841nd). The problem was in /var/run/hostapd-phy0.conf. It seems it is not 
> > enough just set 'wmm_enable=1' to actually enable WME/WMM on interface, it 
> > also need all WMM related keys be set. So I just added it with standart 
> > definitions from hostapd.conf to /lib/netifd/hostapd.sh.
> > 
> > As a result I got full 100Mbit/s on AR71XX platform and 70-80Mbit on 
> > Ralink. I think it is good performance improvement at this moment.
> > 
> 
> Hi, this does not seem to make any difference in CC with a tp-link wdr3600..
> 
> > Patch was created against current trunk version.
> > 
> > 
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> > 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Change OpenWrt Wifi default settings

2015-07-31 Thread N.Leiten 
In email dated Пятница - 31 июля 2015 17:08:23 user John kerry wrote:
> Hi,
> 
> I am working on Ar71xx openWRT Luci project. By default the Wi-Fi is
> disabled and SSID is OpenWrt. I need to change the default settings.
> Could anyone help me to change the default settings.
> 
> 
> Best Regards,
> John

You can look at mac80211 package, in 
package/kernel/mac80211/files/lib/wifi/mac80211.sh there's function 
detect_mac80211() and at the end of file there's block of default wifi 
parameters.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Change OpenWrt Wifi default settings

2015-08-01 Thread N.Leiten 
You can also use uci-defaults mechanism for your purpose. Just put
script in base-files/etc/uci-defaults and set your preferrable
parameters with uci and don't forget to 'exit 0' at the end of script,
in elsecase it'll be run every time at boot ruining changes.

2015-07-31 12:08 GMT+03:00 John kerry :
> Hi,
>
> I am working on Ar71xx openWRT Luci project. By default the Wi-Fi is
> disabled and SSID is OpenWrt. I need to change the default settings.
> Could anyone help me to change the default settings.
>
>
> Best Regards,
> John
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Change OpenWrt Wifi default settings

2015-08-02 Thread N.Leiten 
Hi,

Don't answer to my e-mail only, you need to add openwrt-devel maillist to CC or 
just answer to CC, in each case I'll receive message but also everyone could 
see all discussion.

In email dated Воскресенье - 02 августа 2015 12:54:32 user John kerry wrote:
> Hi Leiten,
> 
> I have added new files under and written below :
> vi target/linux/ar71xx/base-files/etc/uci-defaults/wireless

Use index in prefix of filename to set order of execution, so it'll be like 
'99-wireless'.

> 
> #!/bin/sh
> #
> # Copyright (c) 2013 The Linux Foundation. All rights reserved.
> # Copyright (C) 2011 OpenWrt.org
> #
> 
> [ -e /etc/config/wireless ] && exit 0

Here is the problem. When uci-defaults invoke scripts there's already 
preconfiguration done and /etc/config/wireless already exists, so your script 
just exit at this point. Remove this line.

> 
> touch /etc/config/wireless
> 
> uci set wireless.@wifi-device[0].disabled=0;
> uci set system.@system[0].hostname=test_ap
> uci set wireless.@wifi-iface[0].mode=ap
> uci set wireless.@wifi-iface[0].ssid=CD-2.4D
> uci set wireless.@wifi-iface[0].encryption=none
> uci set wireless.@wifi-iface[0].wds=1
> uci set wireless.radio0.disabled=0
> 
> uci commit wireless
> 
> exit 0
> 
> and compile the source code using make V=s but still not changed default
> settings.
> 
> Please help me to make it works.
> 
> Thanks,
> 
> 
> On Sat, Aug 1, 2015 at 4:38 PM, N.Leiten  wrote:
> 
> > You can also use uci-defaults mechanism for your purpose. Just put
> > script in base-files/etc/uci-defaults and set your preferrable
> > parameters with uci and don't forget to 'exit 0' at the end of script,
> > in elsecase it'll be run every time at boot ruining changes.
> >
> > 2015-07-31 12:08 GMT+03:00 John kerry :
> > > Hi,
> > >
> > > I am working on Ar71xx openWRT Luci project. By default the Wi-Fi is
> > > disabled and SSID is OpenWrt. I need to change the default settings.
> > > Could anyone help me to change the default settings.
> > >
> > >
> > > Best Regards,
> > > John
> > >
> > > ___
> > > openwrt-devel mailing list
> > > openwrt-devel@lists.openwrt.org
> > > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> > >
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> >
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] Fix 'Dropping frame due to full tx queue' for Ralink wifi get stuck.

2015-09-11 Thread N.Leiten 
Fix instability of Ralink WiFi general queue management on high load.
rt2x00 driver logs in dmesg "Dropping frame due to full queue ..." several 
times and at some point get stuck.

Solutions in patch:
1) Increasing number of frames in each TX queue helps with speed and decreases 
queue overflows. Actually 256 frames can be increased to 512 (this number of 
frames used in proprietary drivers for every queue).
2) Setting number of frames in TX/RX queues to equal values resolves async 
speed behaviour with better RX on AP-side (uplink from STAs), where it needs to 
be at least equal or better on TX queue on AP (download to STA).
3) In rt2x00mac.c additional check for queue full added and reassignment in 
this case, so interface will not drop frame.
4) Fixes in queue initialization. Default values for AC_BK, AC_BE, AC_VI, AC_VO 
set from WMM.

Tested on RT3883, RT5350, MT7620 SoCs and on RT3092 pcie interface for 10 days.

I'm planning to send this patch to mac80211 soon, but need to be sure that it 
works on other Ralink/Mediatek platforms and it's appropriate to do so.


Signed-off-by: Nick Leiten 
diff --git a/package/kernel/mac80211/patches/999-rt2x00-queue-update.patch 
b/package/kernel/mac80211/patches/999-rt2x00-queue-update.patch
new file mode 100644
index 000..9239bec
--- /dev/null
+++ b/package/kernel/mac80211/patches/999-rt2x00-queue-update.patch
@@ -0,0 +1,142 @@
+Only in compat-wireless-2015-03-09/drivers/net/wireless/rt2x00: limit
+diff -c -r 
compat-wireless-2015-03-09-orig/drivers/net/wireless/rt2x00/rt2800mmio.c 
compat-wireless-2015-03-09/drivers/net/wireless/rt2x00/rt2800mmio.c
+*** compat-wireless-2015-03-09-orig/drivers/net/wireless/rt2x00/rt2800mmio.c   
2015-06-16 13:02:30.0 +0300
+--- compat-wireless-2015-03-09/drivers/net/wireless/rt2x00/rt2800mmio.c
2015-09-04 11:50:09.665148666 +0300
+***
+*** 700,706 
+  
+   switch (queue->qid) {
+   case QID_RX:
+!  queue->limit = 128;
+   queue->data_size = AGGREGATION_SIZE;
+   queue->desc_size = RXD_DESC_SIZE;
+   queue->winfo_size = rxwi_size;
+--- 700,706 
+  
+   switch (queue->qid) {
+   case QID_RX:
+!  queue->limit = 256;
+   queue->data_size = AGGREGATION_SIZE;
+   queue->desc_size = RXD_DESC_SIZE;
+   queue->winfo_size = rxwi_size;
+***
+*** 711,717 
+   case QID_AC_VI:
+   case QID_AC_BE:
+   case QID_AC_BK:
+!  queue->limit = 64;
+   queue->data_size = AGGREGATION_SIZE;
+   queue->desc_size = TXD_DESC_SIZE;
+   queue->winfo_size = txwi_size;
+--- 711,717 
+   case QID_AC_VI:
+   case QID_AC_BE:
+   case QID_AC_BK:
+!  queue->limit = 256;
+   queue->data_size = AGGREGATION_SIZE;
+   queue->desc_size = TXD_DESC_SIZE;
+   queue->winfo_size = txwi_size;
+diff -c -r 
compat-wireless-2015-03-09-orig/drivers/net/wireless/rt2x00/rt2x00mac.c 
compat-wireless-2015-03-09/drivers/net/wireless/rt2x00/rt2x00mac.c
+*** compat-wireless-2015-03-09-orig/drivers/net/wireless/rt2x00/rt2x00mac.c
2015-06-16 13:02:30.0 +0300
+--- compat-wireless-2015-03-09/drivers/net/wireless/rt2x00/rt2x00mac.c 
2015-09-04 11:47:45.845449209 +0300
+***
+*** 26,31 
+--- 26,32 
+  
+  #include "rt2x00.h"
+  #include "rt2x00lib.h"
++ #include "rt2x00queue.h"
+  
+  static int rt2x00mac_tx_rts_cts(struct rt2x00_dev *rt2x00dev,
+   struct data_queue *queue,
+***
+*** 115,120 
+--- 116,141 
+   if (!test_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags))
+   goto exit_free_skb;
+  
++  /* Dirty hack for Queue overrun protection,
++   * if AC_VO/AC_VI/AC_BE is full, use next queue.
++   * if AC_BK is full use previous queue.
++   */
++  if (qid < 4) {
++  queue = rt2x00queue_get_tx_queue(rt2x00dev,qid);
++  if (unlikely(rt2x00queue_full(queue))){
++  switch(qid){
++  case 0: /* QID_AC_VO */
++  case 1: /* QID_AC_VI */
++  case 2: /* QID_AC_BE */
++  qid++;
++  break;
++  case 3: /* QID_AC_BK */
++  qid--;
++  break;
++  }
++  }
++  }
++  
+   /*
+* Use the ATIM queue if appropriate and present.
+*/
+diff -c -r 
compat-wireless-2015-03-09-orig/drivers/net/wireless/rt2x00/rt2x00queue.c 
compat-wireless-2015-03-09/drivers/net/wireless/rt2x00/rt2x00queue.c
+*** compat-wireless-2015-03-09-orig/drivers/net/wireless/rt2x00/rt2x00queue.c  
2015-03-10 05:37:16.0 +0200
+--- compat-wireless-2015-03-09/drivers/net/wireless/rt2x00/rt2x

Re: [OpenWrt-Devel] [PATCH] Fix 'Dropping frame due to full tx queue' for Ralink wifi get stuck.

2015-09-11 Thread N.Leiten 
Hi,

Ok, I'll do it.

In email dated Пятница - 11 сентября 2015 13:39:54 user John Crispin wrote:
> Hi,
> 
> before looking at this in detail, could please send a properly formatted
> patch. the patch you sent is not using the unified option when
> generating it. upstream linux-wireless wont accept it otherwise and we
> wont either.
> 
> also please prefix the email with "mac80211: " so that we know which
> subsystem it applies to.
> 
> that being said, the bug has been annoying me for eons and i never had
> time to fix it so thanks for the time debugging this :)
> 
>   John
> 
> 
> On 11/09/2015 13:33, N.Leiten wrote:
> > Fix instability of Ralink WiFi general queue management on high load.
> > rt2x00 driver logs in dmesg "Dropping frame due to full queue ..." several 
> > times and at some point get stuck.
> > 
> > Solutions in patch:
> > 1) Increasing number of frames in each TX queue helps with speed and 
> > decreases queue overflows. Actually 256 frames can be increased to 512 
> > (this number of frames used in proprietary drivers for every queue).
> > 2) Setting number of frames in TX/RX queues to equal values resolves async 
> > speed behaviour with better RX on AP-side (uplink from STAs), where it 
> > needs to be at least equal or better on TX queue on AP (download to STA).
> > 3) In rt2x00mac.c additional check for queue full added and reassignment in 
> > this case, so interface will not drop frame.
> > 4) Fixes in queue initialization. Default values for AC_BK, AC_BE, AC_VI, 
> > AC_VO set from WMM.
> > 
> > Tested on RT3883, RT5350, MT7620 SoCs and on RT3092 pcie interface for 10 
> > days.
> > 
> > I'm planning to send this patch to mac80211 soon, but need to be sure that 
> > it works on other Ralink/Mediatek platforms and it's appropriate to do so.
> > 
> > 
> > Signed-off-by: Nick Leiten 
> > diff --git a/package/kernel/mac80211/patches/999-rt2x00-queue-update.patch 
> > b/package/kernel/mac80211/patches/999-rt2x00-queue-update.patch
> > new file mode 100644
> > index 000..9239bec
> > --- /dev/null
> > +++ b/package/kernel/mac80211/patches/999-rt2x00-queue-update.patch
> > @@ -0,0 +1,142 @@
> > +Only in compat-wireless-2015-03-09/drivers/net/wireless/rt2x00: limit
> > +diff -c -r 
> > compat-wireless-2015-03-09-orig/drivers/net/wireless/rt2x00/rt2800mmio.c 
> > compat-wireless-2015-03-09/drivers/net/wireless/rt2x00/rt2800mmio.c
> > +*** 
> > compat-wireless-2015-03-09-orig/drivers/net/wireless/rt2x00/rt2800mmio.c
> >2015-06-16 13:02:30.0 +0300
> > +--- compat-wireless-2015-03-09/drivers/net/wireless/rt2x00/rt2800mmio.c
> > 2015-09-04 11:50:09.665148666 +0300
> > +***
> > +*** 700,706 
> > +  
> > +   switch (queue->qid) {
> > +   case QID_RX:
> > +!  queue->limit = 128;
> > +   queue->data_size = AGGREGATION_SIZE;
> > +   queue->desc_size = RXD_DESC_SIZE;
> > +   queue->winfo_size = rxwi_size;
> > +--- 700,706 
> > +  
> > +   switch (queue->qid) {
> > +   case QID_RX:
> > +!  queue->limit = 256;
> > +   queue->data_size = AGGREGATION_SIZE;
> > +   queue->desc_size = RXD_DESC_SIZE;
> > +   queue->winfo_size = rxwi_size;
> > +***
> > +*** 711,717 
> > +   case QID_AC_VI:
> > +   case QID_AC_BE:
> > +   case QID_AC_BK:
> > +!  queue->limit = 64;
> > +   queue->data_size = AGGREGATION_SIZE;
> > +   queue->desc_size = TXD_DESC_SIZE;
> > +   queue->winfo_size = txwi_size;
> > +--- 711,717 
> > +   case QID_AC_VI:
> > +   case QID_AC_BE:
> > +   case QID_AC_BK:
> > +!  queue->limit = 256;
> > +   queue->data_size = AGGREGATION_SIZE;
> > +   queue->desc_size = TXD_DESC_SIZE;
> > +   queue->winfo_size = txwi_size;
> > +diff -c -r 
> > compat-wireless-2015-03-09-orig/drivers/net/wireless/rt2x00/rt2x00mac.c 
> > compat-wireless-2015-03-09/drivers/net/wireless/rt2x00/rt2x00mac.c
> > +*** 
> > compat-wireless-2015-03-09-orig/drivers/net/wireless/rt2x00/rt2x00mac.c 
> >2015-06-16 13:02:30.0 +0300
> > +--- compat-wireless-2015-03-09/drivers/net/wireless/rt2x00/rt2x00mac.c 
> > 2015-09-04 11:47:45.845449209 +0300
> > +***
> > +*** 26,31 
> > +--- 26,32 
> > +  
> > +  #include "rt2x00.h"
> &

Re: [OpenWrt-Devel] [PATCH] Fix 'Dropping frame due to full tx queue' for Ralink wifi get stuck.

2015-09-11 Thread N.Leiten 
In email dated Пятница - 11 сентября 2015 13:49:26 user Felix Fietkau wrote:
> On 2015-09-11 13:33, N.Leiten wrote:
> > Fix instability of Ralink WiFi general queue management on high load.
> > rt2x00 driver logs in dmesg "Dropping frame due to full queue ..." several 
> > times and at some point get stuck.
> > 
> > Solutions in patch:
> > 1) Increasing number of frames in each TX queue helps with speed and
> > decreases queue overflows. Actually 256 frames can be increased to
> > 512 (this number of frames used in proprietary drivers for every
> > queue).
> 512 frames seems to be overly excessive. Ever heard of bufferbloat?
> It seems to me that the driver should simply call ieee80211_stop_queue
> earlier to ensure that mac80211 does not attempt to fill the queues as
> much. The driver queue length should probably be around 64 or less.
> 

I agree. The patch was made for internal use on own hardware reference design 
in our company, so I had to look through proprietary and opensource drivers to 
see the difference. The point was to use recent versions of OpenWRT with 
mac80211 stack because proprietary still uses linux-2.6. And it makes porting 
full of pain in nails and bloody eyes reading that piece of code. For now 
mac80211 is preferrable.
As to bufferbloat - yes I'm aware of it. Maybe I'm wrong in observations, but 
simply increasing queue num to 128 frames make driver more stable but not 
enough, so I started digging in ralink drivers for maximum value, tried it and 
it increased stability even more, but still hang at some point. So I decreased 
it to 256. Well, I'll try to remove this part and test again.

> > 2) Setting number of frames in TX/RX queues to equal values
> > resolves async speed behaviour with better RX on AP-side (uplink from
> > STAs), where it needs to be at least equal or better on TX queue on
> > AP (download to STA).
> That also doesn't make much sense to me as queueing behavior is
> completely different between rx and tx. Rx queue processing speed is
> determined by CPU speed, Tx queue processing speed is determined by
> shared medium speed.
> 

I agree, that was another step in digging. As I can understand it's better even 
use NAPI for RX queue. But I found only one mention of it in mac80211 sources, 
need to explore this.
I'll remove it, test again and make new patch. Can you direct me with this kind 
of behaviour? On rt3092 (2T2R) we can get 30-40Mbit/s download and 80-120Mbit/s 
upload speeds in separate tests, on 1T1R and 2T2R stations.

> > 3) In rt2x00mac.c additional check for queue
> > full added and reassignment in this case, so interface will not drop
> > frame.
> Why? If the queues are full, it's better to just drop packets instead of
> making the problem worse.
> 

It was the simpliest solution at this point. I'll try to use 
ieee80211_stop_queue instead, but don't know how much time it'll consume.
Maybe there's problem in "kick/pause" queue mechanism? I managed to explore 
behaviour after hang-point. It seems that only QID_AC_* queues stuck, station 
assoc/auth goes fine but actual data not transmitted on AP-side, but it 
receives DHCP-requests from station and it looks like no network access on 
hanged AP.

> > 4) Fixes in queue initialization. Default values for AC_BK,
> > AC_BE, AC_VI, AC_VO set from WMM.
> Why do you hardcode that stuff inside the driver? What difference do
> these values make?
> 
> > Tested on RT3883, RT5350, MT7620 SoCs and on RT3092 pcie interface for 10 
> > days.
> > 
> > I'm planning to send this patch to mac80211 soon, but need to be sure that 
> > it works on other Ralink/Mediatek platforms and it's appropriate to do so.
> > 
> > 
> > Signed-off-by: Nick Leiten 
> > diff --git a/package/kernel/mac80211/patches/999-rt2x00-queue-update.patch 
> > b/package/kernel/mac80211/patches/999-rt2x00-queue-update.patch
> > new file mode 100644
> > index 000..9239bec
> > --- /dev/null
> > +++ b/package/kernel/mac80211/patches/999-rt2x00-queue-update.patch
> > @@ -0,0 +1,142 @@
> > +Only in compat-wireless-2015-03-09/drivers/net/wireless/rt2x00: limit
> > +diff -c -r 
> > compat-wireless-2015-03-09-orig/drivers/net/wireless/rt2x00/rt2800mmio.c 
> > compat-wireless-2015-03-09/drivers/net/wireless/rt2x00/rt2800mmio.c
> > +*** 
> > compat-wireless-2015-03-09-orig/drivers/net/wireless/rt2x00/rt2800mmio.c
> >2015-06-16 13:02:30.0 +0300
> > +--- compat-wireless-2015-03-09/drivers/net/wireless/rt2x00/rt2800mmio.c
> > 2015-09-04 11:50:09.665148666 +0300
> > +***
> > +*** 700,706 
> > +  
> > +   switch (

Re: [OpenWrt-Devel] [PATCH] Fix 'Dropping frame due to full tx queue' for Ralink wifi get stuck.

2015-09-11 Thread N.Leiten 
Hi.

In email dated Пятница - 11 сентября 2015 17:16:35 user Mikko Hissa wrote:
> 
> > On 11 Sep 2015, at 15:43, N.Leiten  wrote:
> > 
> > In email dated Пятница - 11 сентября 2015 13:49:26 user Felix Fietkau wrote:
> >> On 2015-09-11 13:33, N.Leiten wrote:
> >>> Fix instability of Ralink WiFi general queue management on high load.
> >>> rt2x00 driver logs in dmesg "Dropping frame due to full queue ..." 
> >>> several times and at some point get stuck.
> >>> 
> >>> Solutions in patch:
> >>> 1) Increasing number of frames in each TX queue helps with speed and
> >>> decreases queue overflows. Actually 256 frames can be increased to
> >>> 512 (this number of frames used in proprietary drivers for every
> >>> queue).
> >> 512 frames seems to be overly excessive. Ever heard of bufferbloat?
> >> It seems to me that the driver should simply call ieee80211_stop_queue
> >> earlier to ensure that mac80211 does not attempt to fill the queues as
> >> much. The driver queue length should probably be around 64 or less.
> >> 
> > 
> > I agree. The patch was made for internal use on own hardware reference 
> > design in our company, so I had to look through proprietary and opensource 
> > drivers to see the difference. The point was to use recent versions of 
> > OpenWRT with mac80211 stack because proprietary still uses linux-2.6. And 
> > it makes porting full of pain in nails and bloody eyes reading that piece 
> > of code. For now mac80211 is preferrable.
> > As to bufferbloat - yes I'm aware of it. Maybe I'm wrong in observations, 
> > but simply increasing queue num to 128 frames make driver more stable but 
> > not enough, so I started digging in ralink drivers for maximum value, tried 
> > it and it increased stability even more, but still hang at some point. So I 
> > decreased it to 256. Well, I'll try to remove this part and test again.
> 
> I think I solved the stuck tx-queue issue a few years ago by increasing the 
> size of the txstatus fifo. Now looking at the code, I suggest you to try the 
> following. 
> 
> in rt2800mmio.c:
>   static void rt2800mmio_txstatus_interrupt(struct rt2x00_dev *rt2x00dev…
>   I don’t know to what end was this added here but anyways remove 
> the read limit, since it’s obvious that there might be more than just one 
> tx-queue being used. Exiting the interrupt handler here with half full hw 
> fifo (16 entries) will lead to lost txstatuses for sure:
>   if (++i >= rt2x00dev->tx->limit)
> break;
> 
Ok, I'll try that.

> in rt2x00dev.c
>   static int rt2x00lib_probe_hw(struct rt2x00_dev *rt2x00dev)…
>   I used a static value here, but it seems that the hw might 
> generate excess txstatuses (who knows why). So bigger is better!
>   -int kfifo_size = roundup_pow_of_two(rt2x00dev->ops->tx_queues 
> * rt2x00dev->tx->limit * sizeof(u32));
>   +int kfifo_size = roundup_pow_of_two(2048 * sizeof(u32));
> 
> With these you should no longer be experiencing stuck tx-queues!
> 

Actually,
   int kfifo_size = roundup_pow_of_two(2048 * sizeof(u32));
is the same way I go, but I increase rt2x00dev->tx->limit to 512 at first place 
and after tests decreased it to 256. So in math we got the same value  there (4 
queues * 512 frames = 2048).

> > 
> >>> 2) Setting number of frames in TX/RX queues to equal values
> >>> resolves async speed behaviour with better RX on AP-side (uplink from
> >>> STAs), where it needs to be at least equal or better on TX queue on
> >>> AP (download to STA).
> >> That also doesn't make much sense to me as queueing behavior is
> >> completely different between rx and tx. Rx queue processing speed is
> >> determined by CPU speed, Tx queue processing speed is determined by
> >> shared medium speed.
> >> 
> > 
> > I agree, that was another step in digging. As I can understand it's better 
> > even use NAPI for RX queue. But I found only one mention of it in mac80211 
> > sources, need to explore this.
> 
> The driver already uses tasklets and rx-interrupts stay disabled until the 
> driver "catches up” with the rx-queue. So, there’s little to none performance 
> gain here with napi. Although, I did see a noticeable performance increase by 
> enabling delayed rx-interrupts from the hw. As if the hw is sending a BA 
> every time when RX_CRX_IDX register is written? 
> 
> > I'll remove it, test again and make new patch. Can you direct me wit

[OpenWrt-Devel] [PATCH 1/1] [SIGNED-OFF] ramips: Ralink RT3883 RGMII pinmux fix.

2015-09-24 Thread N.Leiten 
Due to datasheet of rt3883 SoC rgmii1 port handles pins 84-95 and rgmii2 port 
handles pins 72-83. When this function ports gets added to rt3883_pinmux_data 
there's wrong pinmux bits set (RT3883_GPIO_MODE_GE1 manages 84-95 pins and 
RT3883_GPIO_MODE_GE2 manages 72-83). So when enabling rgmii2 as GPIO driver 
confuses hardware and nothing work, neither rgmii nor gpio.
Also in '0030-pinctrl-ralink-add-pinctrl-driver.patch' typo in name of rgmii2 
port.


Signed-off-by: Nick Leiten 

diff -pur 
chaoscalmer.git/target/linux/ramips/patches-3.18/0030-pinctrl-ralink-add-pinctrl-driver.patch
 
chaoscalmer.git-diff/target/linux/ramips/patches-3.18/0030-pinctrl-ralink-add-pinctrl-driver.patch
--- 
chaoscalmer.git/target/linux/ramips/patches-3.18/0030-pinctrl-ralink-add-pinctrl-driver.patch
   2015-09-24 16:21:21.521925769 +0300
+++ 
chaoscalmer.git-diff/target/linux/ramips/patches-3.18/0030-pinctrl-ralink-add-pinctrl-driver.patch
  2015-09-24 16:23:24.940957645 +0300
@@ -828,8 +828,8 @@ Signed-off-by: John Crispin https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Huawei hg556a ralink eeprom bug ?

2015-12-07 Thread N.Leiten 
Does it happen on every boot or only on first boot after firmware update?

The reason of this error is absence of 'firmware' (like ART on Atheros-based 
boards) partition on flash due to firmware structure itself or error in DTS 
files.
In OpenWRT kernel falls back to usermode generation of EEPROM on some boards. 
Telnet on your board and look into /etc/hotplug.d/firmware/10-rt2x00-eeprom 
script which generates eeprom in overlayFS filesystem. 
So error itself is not like ERROR, but WARNING notifies that we using some 
custom eeprom. Maybe in hotplug script it is needed to add your board for 
proper generation of this eeprom file. Notification will not go away, but MAC 
will be different.

In email dated Вторник - 08 декабря 2015 06:23:20 user Soulkey wrote:
> [  76.724897] NET: Registered protocol family 24 
> [  76.795698] PCI: Enabling device :00:01.0 ( -> 0002) 
> [  76.803518] rt2800pci :00:01.0: failed to load eeprom property 
> [  76.809963] ieee80211 phy0: rt2x00lib_request_eeprom_file: Info - Loading 
> EEPROM data from 'rt2x00.eeprom'. 
> [  76.820564] rt2800pci :00:01.0: Direct firmware load for rt2x00.eeprom 
> failed with error -2 
> [  76.829595] rt2800pci :00:01.0: Falling back to user helper 
> [  83.235050] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 3572, rev 0223 
> detected 
> [  83.243146] ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 0008 detected 
> [  83.251793] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' 
> [  89.653747] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready 
> [  91.132554] eth0: link UP - 100/full - flow control off 
> [  91.146204] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready 
> [  102.639205] device eth0.1 entered promiscuous mode 
> [  102.644225] device eth0 entered promiscuous mode 
> [  102.684722] br-lan: port 1(eth0.1) entered forwarding state 
> [  102.690589] br-lan: port 1(eth0.1) entered forwarding state 
> [  103.732202] eth0: link UP - 100/full - flow control off 
> [  104.694171] br-lan: port 1(eth0.1) entered forwarding state 
> [  108.587444] ieee80211 phy0: rt2x00lib_request_firmware: Info - Loading 
> firmware file 'rt2860.bin' 
> [  109.148045] ieee80211 phy0: rt2x00lib_request_firmware: Info - Firmware 
> detected - version: 0.34 
> [  109.281432] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready 
> 
> 
> 
> 
> I got this log in the firmware from Chaos Calmer 15.05, 
> and it would lead to different machines have the same WIFI MAC. 
> 
> So, how to solve it ? 
> 
> Thank you very much.
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel