-
Notifications
You must be signed in to change notification settings - Fork 180
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Help]: Netgear A6210 Slow Download Speed (need testers, anyone with adapter that uses mt7612u) #504
Comments
This is not expected behavior. The mt7612u and rtl8812au chips give more or less the same performance. I have one of these Netgear adapters. Let me do some testing to see what I see. |
Here is what I am seeing: Band 2, 5 GHz
This is about what I would expect given the details at my location. I have very little congestion but the signal is not perfect but is not too bad. |
Many thanks for the quick response. It is good to see what the results should look like. I've just tested my three devices in a different client, a laptop running OpenSUSE Tumbleweed, which I've positioned a couple of meters away from the router. 5Ghz and -40 dBm. I still get the same sort of results. First device:
Second device:
Third device:
I'm at a complete loss as to why I'm not getting the same results as yourself. The devices were purchased at different times from different suppliers so I can't believe they are all bad. I get real problems trying to stream any kind of video (eg. online TV or video conferences) using the devices, which prompted my investigations, making them pretty much unusable to me. |
I can grab a laptop and try to get my signal around this reading to see what I get. I would estimate somewhere between 360-400 Mbps.
I took happened to turn on YouTubeTV to watch the morning news after I connected my Netgear A6210 to do the testing earlier. Very stable video and audio. I ran iperf3 while watching and the reading dropped by around 25 Mbps. I tried some other things and nothing caused problems with the video and audio. So, to the question of what could be causing this: Since you are comparing an rtl8812au based adapter and it is working better, maybe we need to look at the details:
Maybe we can stumble onto the cause with answers to the above. |
Thanks for following up.
In summary, whatever client machine I use, whatever USB port I use, whether I use the USB extension cable or not, whether I use radio 1 or radio 2 on various different channels, the rtl8812au devices work fine every time and the mt7612u devices always results in much slower download speeds with lots of retries. Weird! Can congestion affect one type of adapter but not another? Just to add, I have other Linux devices on the same network using PCI network cards and these all work fine (same as the rtl8812au devices). |
I don't have much time right now to explain but I think I saw this on a laptop this morning: Laptop is running Ubuntu 24.04 with kernel 6.08. I made a mistake earlier when I told you my main dev box here is running kernel 6.6... I actually had selected kernel 6.9 last time I had booted and forgot about it. I do a lot of testing so have many kernel installed. So, I am not seeing this with kernel 6.9. I can test more kernels later but I did see if on a laptop with kernel 6.8. So, the investigation is underway... when I have time to work it again... |
Thanks again. For info, I installed Debian on my laptop and tested using the following kernels: 6.1.0 The results were the same for every kernel. |
Good info to add to what we have. One thing we need to keep in mind is that when testing we may need to take the systems down to a cold boot between tests. I am busy but will continue as able. I do not think that it is your adapters that are faulty. My best guess at this point is that it could be something in the driver, wifi stack or usb stack. We have been seeing a lot of wifi problems lately and a lot of patches but it can take time for patches to work their way to us. I will be keeping an eye open and will continue testing. Keep me posted. FYI: I have other adapters with the mt7612u so I can test them as well. |
A quick update just to say that, having replaced the ath10k-ct firmware with the standard ath10k firmware on my OpenWrt router, I am now getting a much improved connection (both up & down speed plus stability) on all my client devices & adapters. For example, using one of the Netgear A6210 (mt7612u) devices now shows:
Still seeing lots of retransmissions with the Netgear A6210 (mt7612u) devices but the actual usage experience is significantly better. |
I have a ath10k based and my experience is the same as yours. The -ct version may have been better at some point in years past but it certainly is not these days. I have to wonder why OpenWRT does not make the default switch on many systems. |
Checklist
uname
Linux {obscured} 6.6.46 #1 SMP Sun Aug 18 00:39:55 UTC 2024 x86_64 GNU/Linux
lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 002: ID 8087:8000 Intel Corp. Integrated Rate Matching Hub Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 002: ID 0846:9053 NetGear, Inc. A6210
rfkill
1: phy1: wlan Soft blocked: no Hard blocked: no
dkms
iw
What happened?
I have a number of Netgear A6210 (mt7612u) devices.
Testing with iperf on various Linux based clients, against my router (Linksys MR8300 running OpenWrt) which is about seven meters away with a clean line of sight, shows a reasonable upload speed:
although there are a number of retries, however the download speed is much less:
Compared to the same clients using a TP-Link Archer T4U (rtl8812au) device:
where the upload and download speeds are similar and there are no retries.
I've tested these devices in various clients, using different Linux distros, with different kernel versions (5.x and 6.x), and the results are the same.
Testing using a different remote makes no difference.
Testing using a different Wi-FI channel makes no difference.
Testing using a different USB port makes no difference.
Does anyone know if this is simply expected behavior with this device type, if this is a known bug, or if there is any special configuration required to address the download speeds and number of retries?
Thanks in advance.
The text was updated successfully, but these errors were encountered: