hwnat in pandorabox is buggy that causes the issue afaik, just disable it. try test build r1597 or (16.10) 2017-01-03 build from downloads.pandorabox.com.cn site.
gonna switch to lede as soon as wireless is fixed.
distance: approx. 5m below the router, through a 50cm wall
2.4G TX max 65Mbps
2.4G RX max 82Mbps
5G TX max 90Mbps
5G RX max 85Mbps
this is without USB device, if using USB device the throughput drops. i've tried using 1.5A power supply instead of original xioami's 1A but the issue persists. so it must be some kind of driver/registers conflict or the CPU simply cannot handle that much traffic while operating an USB device. it is running at 620MHz and so far there seems to be no way of setting higher clocks from breed loader (i've tried contacting hackpascal about this but did not get any reply). probably will just revert ralink bootloader after some more testing
update: with latest ubuntu 16.10 speeds are crap: about 50Mbps TX and 30 RX on both interfaces
suggestions for a lightweight and functional OS like lucid are welcome
wifi range, tested at approx. 8m distance without obstacles
2.4GHz
TX: -42dBm RX: -51dBm
5GHz
TX: -50dBm RX: -65dBm
2.4GHz compared to pandorabox or stock fw has same signal strength with both TX and RX. pandorabox (any of the 3 builds tested) and trunk have quite unstable 2.4GHz TX. stock fw has stable 2.4GHz TX.
5GHz seem to have problem with both iPA/iLNA. disabling TSSI compensation and enabling temperature control gains ~4dB at TX level without throughput regression.
config wifi-device 'radio0'
option type 'mac80211'
option channel '40'
option hwmode '11ac'
option path 'pci0000:00/0000:00:00.0/0000:01:00.0'
option htmode 'VHT80'
option noscan '0'
config wifi-iface 'default_radio0'
option device 'radio0'
option network 'lan'
option mode 'ap'
option encryption 'psk2+ccmp'
option key 'password_here'
option macfilter 'allow'
list maclist '00:00:00:00:00:00'
option ssid 'WIFI 5G NAME HERE'
config wifi-device 'radio1'
option type 'mac80211'
option channel '3'
option hwmode '11g'
option path 'platform/10180000.wmac'
option htmode 'HT40'
option noscan '0'
config wifi-iface 'default_radio1'
option device 'radio1'
option network 'lan'
option mode 'ap'
option encryption 'psk2+ccmp'
option key 'password_here'
option macfilter 'allow'
list maclist '00:00:00:00:00:00'
option ssid 'WIFI 2G NAME HERE'
LEDE Reboot SNAPSHOT r3472
Not fully stable but usable with the settings above. If I add country code or transmit power value it becomes unstable.
And getting this error from time to time.
Mon Feb 20 04:07:27 2017 kern.err kernel: [53303.575047] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
Mon Feb 20 04:07:27 2017 kern.err kernel: [53303.584492] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
Mon Feb 20 04:07:27 2017 kern.err kernel: [53303.593953] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
Mon Feb 20 04:07:27 2017 kern.err kernel: [53303.603401] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
Mon Feb 20 04:07:27 2017 kern.err kernel: [53303.612847] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
Mon Feb 20 04:07:27 2017 kern.err kernel: [53303.622297] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
Mon Feb 20 04:07:27 2017 kern.err kernel: [53303.631748] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
Mon Feb 20 04:07:27 2017 kern.err kernel: [53303.641192] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
Speedtest wifi 2g: 6/7m with 2 walls distance 20-25 mbits DL 10-15 mbits UL.
5g seems to be getting capped to 50-60 mbits even if I'm standing next to the router.
Edit1:
All speedtest done with usb drive mounted.
Wired - http://beta.speedtest.net/result/6081768120
2G about 25 ft w/ 2/3 walls - http://www.speedtest.net/my-result/a/2654001492
2G about 30 ft w/ 3/4 walls - http://www.speedtest.net/my-result/a/2654014944
5G about 2 ft next to the router - http://www.speedtest.net/my-result/a/2654037149
Model: Xiaomi MiWiFi Mini
Firmware Version: LEDE Reboot SNAPSHOT r3472
Thanks with your help wireless seems more stable on dir-860l with lede 17.01.0
USB devices seem to cause throughput regression as I've already described: https://github.com/openwrt/mt76/issues/70
it seems to have an impact particularly on TX path since I've managed to get RX 155 Mbps at 5m distance through a concrete wall
patching eeprom at offset 8036 to value 02 will turn on temperature control. according to eeprom guide it is needed to patch 8053 to 57, 8054 to 47, 8055 to BA, 80F2 to 0F, 80F3 to 09, 80F4 to 0D and 80F5 to 10 for full TC operation. in some cases the TX gain could be 1-2dB higher, but it depends on placement of router antennas and signal dispersion - it can get up to 4dB. at this point both TX & RX rates were still 300Mbps, if needed max power patch offsets 8064 8069 806E 8073 8078 807D 8082 8087 808C 8091 8096 809B 80F8 to 2E. that will allow to set txpower of 23dBm which gains extra ~2dB but affects TX rate
This is what I was able to get from the next room (3m~)
but the max real world performance with usb drive is around
and about 80-90mbits ul/dl w/o the usb drive.
exact same dl/ul speeds i get when running iperf single-thread with default setting(openwrt r50082)
increasing buffer length and using 4 parallel streams almost doubles RX throughput, TX not tested yet
@psyborg I'm on the breed bootloader as well and would like to revert to the stock bootloader. Any chance you could share yours?
Another issue I have with this device is when using pandorabox I can't even connect to 2.4GHz wireless and LEDE is stuck in a bootloop... (both 17.01 and nightly)
The stock firmware however has no problems at all...
Any updates on this issue?
Lede 17.01.4
10mbit/sec on 2.4GHz
70mbit/sec on 5GHz
95mbit/sec on through cable.
On stock/pandora firmware I can have about 50mbits over 2.4GHz, and there is no USB device connected. Tried a lot of different combinations of options like rts/fragmentation. Android phone shows link speed 150mbits
Up, wifi not work correctly:
[25263.585308] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
[25263.594832] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
[25263.604313] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
[25263.613746] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
[25263.623207] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
[26543.858190] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
[26543.867717] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
[26543.877187] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
[26543.886659] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
[26543.896117] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2Does it mean that as you mentioned:
Please reopen this pull request
this patch:
+static struct rt2880_pmx_func pa_grp[] = { FUNC("pa", 0, 20, 2) };
this will not fix the issue ?
no, issue not fixing
some problem in NEXX WT3020H ( MediaTek MT7620n )
ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
Up any news?
please consider money support to my webmoney WMZ purse: Z290111431046 (PP,Bitcoin and others are not an option)
write and post MT7620 devices you use, their exact revision and wikidevi links to these devices
if there is enough interest (and support) i will try to get 4-5 most popular devices and continue to work on stabilizing wifi drivers. (another progress with mini has already been made)
The problem is not solved
Linux mi-mini 4.14.63 #0 Wed Aug 15 20:42:39 2018 mips GNU/Linux
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='18.06.1'
DISTRIB_REVISION='r7258-5eb055306f'
DISTRIB_TARGET='ramips/mt7620'
DISTRIB_ARCH='mipsel_24kc'
DISTRIB_DESCRIPTION='OpenWrt 18.06.1 r7258-5eb055306f'
DISTRIB_TAINTS=''
[ 1393.923791] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
[ 1393.933241] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
[ 1393.942686] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
[ 1393.952130] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
[ 1393.961574] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
I think it will never solved 
1 Like
The queue is either full because the radio is not properly tuned and interferences prevent the the packets from being transmitted or because the CPU is too busy on other tasks and ends us not having time to send them.
This driver should be optimized for the new version kernel in v18 but nobody, including the Mediatek, seems to have done it.
In other threads it looks like @psyborg was close to have it working but now got worse. The code of the MT7620A is shared with other chipsets and has been refactored so many times that when another chipset is improved it makes the MT7620A worse.
Fixing it seems a big job that requires determined people that know what they are doing. Probably it would require copy some older code and using that as starting point.