I'm wondering if the cpu is running on a single core.
Here's full dmesg output: https://gist.github.com/JohnDowson/427b1dd947d3d2ce74f239bf1ed02870
1 Like
Doesn't look like it, from running a speedtest while looking at htop.
Edit:
I tried running another bufferbloat test from PC over 5Ghz, and the speed is way higher, despite the fact that absolutely nothing has changed in the configuration since the last try, besides a patchcord getting plugged into LAN1.
https://www.waveform.com/tools/bufferbloat?test-id=f94a876d-5192-4279-8a8b-f9d1f3db8603
1 Like
due to VHT EXT NSS BW flag
This means AUTO-BW regdom property is active and MAY halve channel in presence of high competition/noise. Check with iwinfo it is VHT80.
1 Like
It is
root@OpenWrt:~# iwinfo phy1-ap0 info
phy1-ap0 ESSID: "redacted"
Access Point: re:da:ct:ed
Mode: Master Channel: 132 (5.660 GHz) HT Mode: VHT80
Center Channel 1: 138 2: unknown
Tx-Power: 20 dBm Link Quality: 39/70
Signal: -71 dBm Noise: -91 dBm
Bit Rate: 332.4 MBit/s
Encryption: WPA2 PSK (CCMP)
Type: nl80211 HW Mode(s): 802.11ac/n
Hardware: 14C3:7615 7615:14C3 [MediaTek MT7615E]
TX power offset: none
Frequency offset: none
Supports VAPs: yes PHY name: phy1
Should be 433-866 normally, what could obstruct signal? Like fridgge near or steel tray?
cheers, you see dmesg confirms the ethernet is only connecting at
mt7530-mdio mdio-bus:1f lan1: Link is Up - 100Mbps/Full - flow control rx/tx
WAN seem fine though:
mtk_soc_eth 1e100000.ethernet wan: Link is Up - 1Gbps/Full - flow control off
1 Like
Unclear why 100Mbps though. Unless my landlord got scammed by by construction workers that wired up ethernet outlets, there shouldn't be anything limiting the bandwidth.
I get better 20m apart, if you suspect damage then it was water and antennas are still wet.
If you wire the PC directly into the ac2100 does it show 1Gbps in the dmesg?
He tried, was 100mbps 
1 Like
I'd change the channel to 149, this will then allow the ac2100 to use 149 - 165 in full.
if it's damaged on the MT7530 then it's not going to matter what we suggest as that has everything going through it.
Here's a rough layout of my apartment:
Image
The router is located by the entrance, so nearby a steel door, pretty high up, only about 40cm from the ceiling.
But I don't think any of this could explain why the performance is so much worse compared to OEM firmware.
Only bad coverage point visible is near drawn eth socket where you duly added wired connection for extender or alike.
You went near AP and it was still poor, not a fault there.
Make a picture from htop while running tests, fast.com can make much longer load. Unhiding kernel threads and adding CPU detail in bars to distinguich HW and SW (qdisc,firewall)interrupts
Actually, I think it might be worthwhile to explain the fucked up wiring I got going.
By the router, there's four ethernet cords sticking out of the wall. One is WAN, two go to ethernet outlets in each of the rooms, and the last one is a mystery.
The cords that connect to the outlets are extremely short, making them impossible to plug into the router directly. Therefore, one of them is coupled to a short patchcord that came with the router, and is plugged into LAN port on it. Then, after a length of wire hidden in the walls, there is a neat wall outlet. Into that is plugged a 7 meter cat 5e patchcord of somewhat dubious quality, which finally reaches my desktop.
Edit:
@brada4 would you recommend running the load for this through wifi or wired?
Dont connect last one anywhere, might be spare for parlophone or so.
If you can tolerate current slow WiFi for a few more days, you may want to wait a few days then try out a new build of main snapshot. Or you could try reverting to 23.05.3 stable.
The stable 23.05.4 release had some issues with WiFi performance that were fixed almost immediately with a new commit, but the issues were not considered serious enough to release a new stable 23.05.5 point release with the fix. Hence, 23.05.3 may solve your problem.
In the last week or so, a number of updates have been made to the mt76 driver in main snapshot and they did not go smoothly. There have been a few commits since and some reports that the regressions appear to be getting fixed. In other words, main snapshot should "smooth out" in a few days and be back to it's more typical good performance.
There's nothing wrong with trying to debug things in the mean time, but if your issues are bugs related to above, it will just be a lot of wasted time and effort. This just happens to be a rare time period when current stable and current main snapshot are both buggier than usual at the same time.
3 Likes
