NEXX 3020 (MT7620) Wi-Fi issues

Installing and Using OpenWrt
1

Good time of the day!

I have 5 (five) NEXX 3020 routers which are based on the MT7620N chip. If I understood correctly then internally it has RT5390 (or not?). After reading different materials, I see that my router(s) has same Wi-Fi performance issues as Xiaomi Wi-Fi, some Asus (like RT-N14U) and other routers based on MT76** chips.

Also after reading different topics/manuals/posts, here and not only, I understood that LEDE/OpenWRT is using open-source MTK drivers which are not so good and that's why peoples around tries to patch it using proprietary MTK drivers.

Then I made a couple of tests with different LEDE/OpenWRT versions to measure Wi-Fi performance. All tests were made using iperf3 (10 minutes of testing). All other settings defaulted. Setup was also very simple:

Laptop(Centrino N2230) -> NEXX 3020 (via Wi-Fi) -> PC (via Ethernet, link = 1 Gbit).

Mini-router (NEXX 3020) was placed 10-30 cm from Laptop. It was without a plastic case. Like just uncovered board. Also, I put a radiator on the chip. Spent some time measuring temperature (to exclude throttling) and I can say that with radiator temperature never rose more than 40 C.

OpenWrt SNAPSHOT r7309-333e609703. Kernel Version 4.14.50

Average speed: 38.1 Mbit/sec
Min speed: 16.7 Mbit/sec
Max speed: 53.5 Mbit/sec

Desc.: as you see there were a lot of down pikes. Sometimes I see better results, like avg speed ~45-50 Mbit, but it must be even better. Usual stability test runs OK, but in case if I will connect my android device then AP disconnects it (yes, that device) right after few seconds.

main

Lede 17.01.4. Kernel 4.4.92

Average speed: 23.2 Mbit/sec
Min speed: 0 Mbit/sec
Max speed: 55.4 Mbit/sec

Desc.: Much more different pikes. Only here I saw packets drop, etc. Also only this F/W has error known as "Error - Dropping frame due to full tx queue 2". So, connection stability is very poor. The router can "die" at any time. First of all because of above error.

OpenWRT 15.05. Kernel 3.18.23

Average speed: 85.1 Mbit/sec
Min speed: 19.9 Mbit/sec
Max speed: 95.7 Mbit/sec

Desc.: Best connection stability. No issues with phones, no problems with usual connection stability tests. No bug "Error - Dropping frame due to full tx queue 2". Only sometimes I see connection speed drops.

So, in general, OpenWRT 15.05 is the best choice for my NEXX 3020 at this moment. But I would like to use latest available S/W and F/W. But I see a lot of raised topics, questions, and bugs related to Wi-Fi performance and stability with latest LEDE/OpenWRT (like starting from 2017).

Please tell me the current status of Wi-Fi issues related to MT7620. Are there any workarounds to stay with latest LEDE release? Are there any other options which I can tune up? Why do we see such huge stability & performance drop on latest releases?

Many thanks!

P.S. sorry, I can put only one image in the post

2

the community is not interested in anything better.. there were some attempts by @daniel but mainly for a reason of catching some quick money Better support for MT7620A/N in OpenWrt/LEDE. when i asked for a piece of cake he refused me with excuses that i still need to do this and that calibration... his progress was minimal and in general worthless... probably you'd be better reverting everything he done and using Roman Yeryomin 's original patch [PATCH 0/4] add support for mt7620 wifi

a week after i've posted how the ones interested in solving these problems can support me Xiaomi MiWifi mini wireless signal question there was zero support received. your decision.

so long mediatek. to the garbage can you go.

3

I'm using MT7628 based $20US routers in AP mode for my Wifi. The pppoe doesn't work and there is only 2M of flash onboard. The AP mode passes through dual-stack off the lan okay. https://www.ebay.ca/itm/300M-2-4GHz-Wireless-WiFi-Router-1-WAN-4-LAN-Port-Dual-External-Antenna-802-11n-/112547457065?hash=item1a3459e829&_uhb=1

4

@psyborg: so we are talking about https://www.bountysource.com/issues/32309542-no-connection-on-wlan-in-2-4g , right?
just to be clear about my perception of what happened here: you didn't ask for a "piece of the cake", but rather you asked me to abuse administrative priviledges of the (now anyway frozen) dev.openwrt.org trac instance to close a bug so you can cash-in the bounty. if the bug was actually resolved by anything you did i wouldn't see any problem with you asking for that, however, as there wasn't a single report or what-so-ever supporting your claim of having resolved the issue and you asking me in private to close the bug, so you can take the $300 or something simply isn't an option.
The kickstarter project you mentioned (read the description) had the main intention to clean up the existing code and make sure it can go upstream, so we won't loose support for MT7620 wifi in the long run, as our local patchery grew out of control -- and far below any code-quality standards.
This goal was achieved as you can see that support for MT7620 is now part of the rt2x00 driver in vanilla Linux. General problems with that driver (which do also affect Rt3052, Rt3050, Rt5350) are beyond the scope of a $1000 funding (which, counting the hours spent on that MT7620 cleaning, fixing and upstreaming, already ends up to be less than minimum wage)
My motivation to even use kickstarter and patreon to beging with was that after completing and upstreaming support for Rt3352 and Rt5350 I felt that doing the same for MT7620 simply isn't a simple 1-night-task but will take much more time and it's not the kind of work I would choose to do unpaid.

Sorry for replying to this in public, but that was your choice by making that accusation public.

1 Like
5

upstreaming a single patch is rather a poor excuse to mess with the code, screw up and even get paid for it.

and there never will be unless you read through mailing list carefuly, because i'm sure this guy is lying or his tests are inaccurate or you will find another reason to discredit him

6

Well, you should have looked at the patch before, and simply running checkpatch.pl would have told you about 2000+ codestyle issues which had to be fixed before even getting close to the idea of sending the patch to linux-wireless for upstreaming (or doing a decent review).
The screenshot of that email you present dates long after the dev.openwrt.org trac instance had already been set to read-only mode, so at that point nobody had the power to close that bug ticket, which is sad, because now nobody can get that bountysource award unless they move it to another bug-ticket on bugs.openwrt.org. However, this is unlikely to happend, because the original ticket was quite a collection of maybe or maybe not at all interrelated problems when running rt2x00 on MT7620A/N, with no defined way to repduce "the bug" and hence ever showing that it has been resolved. Nevertheless, if Jamie or anyone in the community would explicitely confirm that a fix you made resolves that infamous tx-queue-issue, I would be on your side. However, you fail to provide any such reference.
By the way, at least up to what I can see, the issue had recently resolved by Stanislaw Gruszka by reverting an earlier commit. The culprit has been:
commit fb47ada8dc3c30c8e7b415da155742b49536c61e
Author: Stanislaw Gruszka sgruszka@redhat.com
Date: Wed Feb 15 10:25:12 2017 +0100

rt2800: use TXOP_BACKOFF for probe frames

Which degraded performance on MT7620 and apparently also caused the "failed to stop TX queue" issue when running AP mode. Neither me nor you caused that problem, neither me nor you were able to spot it.

I'm sorry for your obvious misery. Please go annoy other people.

7

First of all, gruszka sent revert of his foolish commit on may 28 2018, evensen already had done tests by may 14 2018 so i doubt gruszka actually fixed anything. He is only capable of doing mess just like you which proved back in 2013 when he moved dbg logs to err level which flooded sys/kern logs causing massive slowdowns with USB devices. It's sad such people's patches are accepted without verification.

Second, as far as i read there were some attempts to simply reload kernel objects on driver hang which would cause 1 sec interface freeze and resume operation normally afterwards. i don't know if these patches are in your git tree and if they could make the problem seem to go away but even if they are it's obvious it's not a real fix.

I was pretty sure the trac destiny was going to freeze that bounty award and they have they rules probably to leave those 65$ to themselves after nobody can get it since original trac ticket can never be closed. That's why i asked bounty starter to make refund request and get his 250$ back. Bountysource support confirmed this.

Finally I've made the driver modifications to work at normal power settings (without ADJUST_POWER_CONSUMPTION_SUPPORT) while maintaining 100+ Mbps of TCP throughput in both directions but guess what: no support for me - these patches won't see the light of day.... end of story and annoyance with fakers like you

8

Huh guys... I see that this is a hot/hard topic for you.
If I understood correctly then the problem with "Error - Dropping frame due to full tx queue 2" is very simple. Someone added something by mistake and after few months that mistake was reverted. Okay, shit happens.

But what about speed degradation? Because it is very horrible. Like an hour ago I was able to reach ~100-105 Mbit/sec using OpenWRT 15.05. And it's very sad when I see such huge downgrade on LEDE/main.

10

@psyborg I saw your PR#626 on github. Your changes seem very promising. I am not sure why nobody posed anything. Thank you very much for working on it!

Are the files here https://github.com/openwrt/openwrt/pull/626#issuecomment-360844957 the ones that about the "driver modifications to work at normal power settings (without ADJUST_POWER_CONSUMPTION_SUPPORT) while maintaining 100+ Mbps of TCP throughput in both directions" ?

How difficult will be to make them work on a Xiaomi Mini Router?
Would they fix also the problem with the USB like these ?

Best, Camicia

11

I just read the whole tread at Xiaomi MiWifi mini wireless signal question

@psyborg According to @coldfire7, your changes created a pretty impressive improvement. From Xiaomi MiWifi mini wireless signal question to Xiaomi MiWifi mini wireless signal question

@coldfire7 Did you use the images posted by @psyborg in https://forum.openwrt.org/viewtopic.php?pid=349582#p349582 111 to achieve those improvements?

By the way, the link is not available anymore :roll_eyes:

12

And just to see if anyone else has noted the issue reported https://bugs.openwrt.org/index.php?do=details&task_id=557
regarding low reported rx sensitivity.And if this may have any bearing on the throughput issue.

13

Sorry guys... but you're asking for performance improvement, right? Do you have a stable wi-fi connection? Even with 18.06 (and mt7620 chip of course) it is VERY unstable for me

14

@Killbrum Did you try a build with this patch https://github.com/openwrt/openwrt/pull/626 ?

15

No, I didn't. Should I try it? It might be difficult for me to compile openwrt from sources.

16

It is worth to try it.

17

@Killbrum There are a lot of changes that went in on Sep 26 relevant to the MT7620 (including the ones from @psyborg ) :

patches

You could try the latest snapshot http://downloads.openwrt.org/snapshots/targets

18

@Camicia, just tested currently built snapshot from 18.06 line: https://git.openwrt.org/?p=openwrt/openwrt.git;a=shortlog;h=refs/heads/openwrt-18.06
It didn't make any difference since 18.06.1. Big packet loss few times per minute.
In my configuration it's set as a wireless client, connected to other 802.11n router (which works stable for me for 10+ different devices since years) about just 2-2.5 meters away from this WT3020F.
On stock fw, it (WT3020F) was used in WIFI master mode, connected to other router via WAN ethernet port and had stable WIFI performance (iperf from laptop via WIFI connected through WT3020F with router on WAN showed 80-95.5MBit/s), without packet loss. Now it's even hard to measure.

19

With latest precompiled snapshot:
wt3020-8M-squashfs-sysupgrade.bin 23b65e43f96607d97dae2942679daed7620c013e73d2b6bfaa46de71e5ea7098 3840.7 KB Sun Oct 21 04:47:02 2018
it seems to be a bit better, but still gets packet loss.

20

Just fleshed four different NEXX 3020 devices using a bit different firmware (not openwrt). Works perfect, no issues. So, I mean the problem is only with openwrt

21

if you ment padavan-ng - yes - it works perfectly - but what about kernel - it's probably not maintained