Hmm okay, I do get a little more bandwidth at distance with my U6+, but nothing to be concerned about. Haven't tested it at the fringes like you are describing but good to know.
1 Like
I also have range issues with the MT6000 using the open mt76 drivers, especially with 2.4 GHz. The throughput on 2.4 GHz drops precipitously at range, such as to my doorbell and cameras, whereas the MTK drivers containing 4.5.7/4.5.8 firmware does not have this issue. My R7800 on ath10k blows the GL-MT6000 out of the water for 2.4 GHz function. As others have mentioned, the range issue seems unrelated to signal strength, which can be measured as normal at the ranges where throughput becomes an issue.
I actually thought that 5 GHz range was good on mt76, but I did not do much testing.
The 2.4 GHz throughput and connectivity at range issue is separate from lack of 256-QAM, which of course is not really a bug.
This is not an endorsement of the closed source drivers, which have their share of issues. I only brought them up for direct comparison of 2.4 GHz at range performance, and personally hope to switch to my own build as soon as I can. That was my whole reason for buying this router in the first place.
1 Like
I seem to have the same situation the range problem is very strange on 2.4ghz.
With mt76 my poco x6 pro gets trouble with handshaking or drops internet from 15 meters away and there are only 2 plaster walls in between.
But when i use mtk drivers, my reach is even 4th floors down outside of my appartment, its a magnitude of difference.
But im skeptic if its the dbm and not something what desynchronizes with the link tracking or maybe in the antenna domain for mt76, i did one very strange observation which i can repeat:
in my custom build ive applied the 256qam patches from leans openwrt just to be sure clients can get higher speeds, but when i start my speed test i get 180 mbs download, when i walk away 15 meters and do it again i hang or wifi gets down, when i do a speedtest back on my first location i don't get more than 50mb/s, i also had this before i used the patches.
^ i think if i repeat that i think i will have no 2.4ghz at all, and that gives me the suspicion something is not synchronized.
Edit:
I need to redo my testing, after the removal of my usb stick inside the usb port, the range improved and there was connectivity again on 15 meters, but i should check longer distances now.
A thorough comparison between MT6000 running a recent snapshot and Uni 6+ would be very useful to establish a baseline. I’ve been wondering recently what kind of real world performance these semi-pro (?) dedicated devices provide. A Samsung/Google phone vs iPhone client comparison would be a great addition.
You could install ImmortalWrt to test 2.4 GHz with 256-QAM. Just be sure to enable the 256-QAM setting for the radio from the advanced settings tab.
https://forum.openwrt.org/t/gl-inet-flint-2-gl-mt6000-discussions/173524/657
https://forum.openwrt.org/t/gl-inet-flint-2-gl-mt6000-discussions/173524/662
"ImmortalWrt is a fork of OpenWrt for mainland China users" Lol pass.
But all of the code is on GitHub and the firmware isn't in Chinese.
I would of suggested compiling OpenWrt with the VHT/QAM-256 pull requests, but they're over a year old and they require multiple changes now. So it's easier to backup your config, flash and test the feature in ImmortalWrt and then revert back to OpenWrt.
Have you done any SQM tests with 23.05.3?
Nah running snapshot
Hello All GL-MT6000 users,
Just wonder are you able to chip in queries from How OpenWrt Vanquishes Bufferbloat - #30 by richb-hanover-priv ?
Basically need to ssh into the router and run "iw list" to show whether it fully supports wireless's bufferbloat taming features ( TXQS , AIRTIME_FAIRNESS and AQL).
Thanks
Basically need to ssh into the router and run "iw list"
You mean this:
Supported extended features:
* [ VHT_IBSS ]: VHT-IBSS
* [ RRM ]: RRM
* [ BEACON_RATE_LEGACY ]: legacy beacon rate setting
* [ BEACON_RATE_HT ]: HT beacon rate setting
* [ BEACON_RATE_VHT ]: VHT beacon rate setting
* [ FILS_STA ]: STA FILS (Fast Initial Link Setup)
* [ CQM_RSSI_LIST ]: multiple CQM_RSSI_THOLD records
* [ CONTROL_PORT_OVER_NL80211 ]: control port over nl80211
* [ ACK_SIGNAL_SUPPORT ]: ack signal level support
* [ TXQS ]: FQ-CoDel-enabled intermediate TXQs
* [ SCAN_RANDOM_SN ]: use random sequence numbers in scans
* [ SCAN_MIN_PREQ_CONTENT ]: use probe request with only rate IEs in scans
* [ CAN_REPLACE_PTK0 ]: can safely replace PTK 0 when rekeying
* [ AIRTIME_FAIRNESS ]: airtime fairness scheduling
* [ STA_TX_PWR ]: TX power control per station
* [ AQL ]: Airtime Queue Limits (AQL)
* [ CONTROL_PORT_NO_PREAUTH ]: disable pre-auth over nl80211 control port support
* [ DEL_IBSS_STA ]: deletion of IBSS station support
* [ SCAN_FREQ_KHZ ]: scan on kHz frequency support
* [ CONTROL_PORT_OVER_NL80211_TX_STATUS ]: tx status for nl80211 control port support
* [ FILS_DISCOVERY ]: FILS discovery frame transmission support
* [ UNSOL_BCAST_PROBE_RESP ]: unsolicated broadcast probe response transmission support
* [ BEACON_RATE_HE ]: HE beacon rate support (AP/mesh)
* [ BSS_COLOR ]: BSS coloring support
* [ RADAR_BACKGROUND ]: Radar background support
2 Likes
That's right, thanks.
Confirmed it fully supported the wireless bufferbloat mitigation with these setting:
- [ TXQS ]: FQ-CoDel-enabled intermediate TXQs
- [ AQL ]: Airtime Queue Limits (AQL)
- [ AIRTIME_FAIRNESS ]: airtime fairness scheduling
2 Likes
So firmware with this older code will just experience slower transfer rates? Any other negative effects?
You should only experience slower rates since it broke beamforming.
1 Like
Looks like it was resolved last night. New MT drivers pushed 4/3.
2 Likes
Yeah, I mentioned it the other day 
Everything's working great now. No issues at all on my end.
2 Likes
Is it in the main snapshot yet? Or do we have to wait a couple more days for it?
The fix is in the latest snapshot (r25773-766ec55966).
2 Likes
I'm waiting for the 4/4 snapshot to hit which should be very soon.
9-day uptime on my current snapshot with a million added packages, things are rock solid right now. Time to bump to 6.6 so we can start stress testing again
4 Likes
If you use the image builder, just rebuild your image and it will pull in the latest packages. If you’re using the firmware selector, 4/4 should include it.
1 Like