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
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.
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
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.
@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
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 
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.
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
No, I didn't. Should I try it? It might be difficult for me to compile openwrt from sources.
It is worth to try it.
@Killbrum There are a lot of changes that went in on Sep 26 relevant to the MT7620 (including the ones from @psyborg ) :
You could try the latest snapshot http://downloads.openwrt.org/snapshots/targets
@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.
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.
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
if you ment padavan-ng - yes - it works perfectly - but what about kernel - it's probably not maintained
I thought same when I tried about ~20 different OpenWrt images :))) but actually no, it is not better. There are two different bugs (or who knows? might be the same bug with different behavior). The first bug leads to unstable connection, low speed, problems with TX/RX power above 10 and possible random router crashes, yep, exactly - OpenWRT crash. The second bug - leads to accidental (or not?) disconnects from AP. I can't recall exact message, but in general, openwrt says that something wrong with the connected client and disconnects it. No speed drop, no package drop, everything is ok, but OpenWRT disconnects that client. Recent patches fixed the first bug, second - no. And still now with patches from September I have random disconnects from AP. I have them ONLY with one device (my Galaxy Note 5). When I'm trying to use my laptop (Intel Centrino blah-blah), it works normal.
P.S. I found one untouched NEXX 3020 with OpenWRT on board. Will upgrade it, and we will see
I don't care about kernel version. There are thousands of old devices with outdated core, but they works like a charm. I think that we need to have, as a first thing, working device, and only then - updated kernel. Nobody care about kernel if device works almost like a brick
@Killbrum, thanks. Yes, I think it's the 2nd bug which I've experienced.
Now I have connected 3020F to different router - well, Banana Pro on latest Armbian in master mode (also via WIFI as a client) and since almost 24h I don't have this disconnects problem.
Connectivity is not fast (Banana can get 802.11n set to 75MBit/s max and measured transfer rates give stable 22MBit/s through 2 walls now), but so far this connection seems to be rock stable.
It's strange as none of my other routers (I have nearly 10 of them) experienced such problems, also none of client devices (laptops, phones, tablets,...) with the router which was problematic to this 3020F.
It's all on yesterday's master snapshot.
I've made few more tests with builds from both:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=shortlog;h=refs/heads/openwrt-18.06
and
https://git.openwrt.org/?p=openwrt/openwrt.git;a=shortlog;h=refs/heads/master
Results are that:
Would someone port WiFi driver fixes from master to openwrt-18.06 tree?