Just reporting that all throughout the release candidate stages, I’ve not been able to get the scan feature of 5ghz to work. I think the only place it worked was on @daniel ‘s initial flashing build.
I can get iw dev wlan1 scan to work about 10% of the time, other times it says device or resource busy. Not a huge issue, but still annoying.
Thanks all, for clearing this up. After cleaning out rc.local, rebooted and confirmed everything is good.
root@rtr02:~# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies
437500 600000 812500 1025000 1137500 1262500 1350000
root@rtr02:~# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors
conservative ondemand userspace powersave performance schedutil
root@rtr02:~# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
userspace
root@rtr02:~# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq
437500
root@rtr02:~# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq
1350000
Another item off the list!
Edit: In case anyone is reading this later and wants to know more about the governor values and their meaning, arch has excellent docs: https://wiki.archlinux.org/title/CPU_frequency_scaling#Scaling_governors
Yeah, that sounds familiar, I asked about issues with iwinfo wlan1 scan back in May, which caused all the 5 GHz devices to be dropped. Now it simply reports Scanning not possible and I can't get iw dev wlan1 info to ever work:
root@rtr02:/etc# for i in $(seq 1 100) ; do
> iw dev wlan1 scan
> sleep 1
> done
command failed: Resource busy (-16)
command failed: Resource busy (-16)
... 98 more times
@moeller0 see this:
Speed test downloading to iPhone 13 on 5GHz radio:
ondemand: 475.5 ± 3.5 Mbps download (n=4 tries)schedutil: 409.3 ± 3.5 Mbps download (n=4 tries)
has any analysis been done in respect of the effect of the scheduler on the CAKE algorithm, especially in respect of non-CPU-saturating loads? One imagines highly localized temporal CPU capacity variation could have quite a big effect in terms of that algorithm?
Any chance you could expand on this? Originally well above in this thread the use of 'schedutil' was proposed to help preserve the longevity of our devices. Is this no longer the case?
The discussion here was about stability, reboot hangs, I thought.
And the performance (or in practice also the "userspace") governor should be the stablest. CPU runs at full speed, so there are no CPU speed changes causing possible "boot hangs" as efahl wrote.
Using schedutil or ondemand might lower the CPU temp a bit, so in theory they might add a bit to the life of the device.
But my answer was purely toward the question "are those two lines needed to guard against boot hangs due to CPU speeds?"
Regarding cake, my own experience with R7800 is not that great with it, and I usually use fq_codel as the qdisc. I suspect that cake has too many intricate calculations that react badly for CPU frequency changes. Pure intuition, but still.
Additionally, cake is not that CPU power friendly any more. Quite many bells and whistles were added to it during the long development process. See this interesting discussion from 2018 starting here: https://lists.bufferbloat.net/pipermail/cake/2018-April/003384.html
(Using cake with mid-level mobile CPU with gigabit level speeds is not the original design case.)
Have you or @soxrok2212 tried rc6 yet? Just checked mine (rc6) and scan is working ok on 5ghz.
That was my intent also, actually "do I need to pay attention to this issue when I tell someone to put OpenWrt on their RT3200/E8450". Performance issues are another tangential matter (which is of course interesting, too), but I just wanted to be sure that a noob installer didn't run into reboot problems.
Not sure what I can add, my current routers both operate on fixed frequencies, so all I could offer is regurgitated hearsay from the forum...
However one thing I note is that cake/HTB+fq_codel are not strictly CPU hogs in that they cause a super high load (they are demanding but not excessively so) but rather that unless they get the CPU with very low delay when they need it throughput will suffer. For HTB+fq_codel we have a few toggles to trade-in a bit more latency for more thoughput, but cake has no exposed toggles affecting the batching...
Yes, all of those examples above were performed today using rc6. (My previous post on May 29 was using rc1.)
Yep, just showing "No Data" for me on RC6.
Just to double check, do both the RT3200 and E8450 still need the UBI installer strategy to make the OpenWRT image permanent?
Additionally, the No Data (or Scanning not possible from cmdline) comes back instantly, whereas if I run a scan on the 2.4 channel, it pauses a second or two, then blurts out 100 stations.
Identical behavior regardless of whether there are active connections (or not) on either radio.
root@rtr02:~# time iwinfo wlan1 scan
Scanning not possible
real 0m 0.00s
user 0m 0.00s
sys 0m 0.00s
root@rtr02:~# time iwinfo wlan0 scan
...
Cell 107 - Address: A4:56:CC:B0:6C:A8
ESSID: "turdburgler"
Mode: Master Channel: 11
Signal: -79 dBm Quality: 31/70
Encryption: mixed WPA/WPA2 802.1X (CCMP)
HT Operation:
Primary Channel: 11
Secondary Channel Offset: no secondary
Channel Width: unknown
real 0m 1.37s
user 0m 0.01s
sys 0m 0.01s
Another issue I'm facing -- I have an RT3200 and an E8450 in WDS mode. E8450 is the client. When I put both into 160MHz on channel 100, the client device sees great RX speeds but the uplink speeds are cut to 136.1mbit/s. It's almost like its being cut at 802.11n speeds. Put it back to 80MHz and it does right back up to over 1gbit/s. Both are on snapshot RC6.
I have 2 MacBooks (albeit 80MHz) that have normal link rates (~1gbit) and an Intel AX200 (160MHz) on my Windows desktop that is reporting a 1.8gbit/s link rate no problem, so looks like an issue specifically for client mode in the MT7915.
Possibly related? https://github.com/openwrt/mt76/issues/683
Are you using a DFS channel in a FCC regulatory domain (e.g. US, CA etc.) by chance? If so, that's the cause for the resource busy error. Since the radio has to monitor for radar pulses it's not allowed to do off channel scanning. This is standard behavior for all 5GHz WiFi chips operating on a DFS channel. Example from a unit I have here:
841-t6-B460-linux: ~ # iw reg get | grep country
country US: DFS-FCC
841-t6-B460-linux: ~ # iwinfo wifi5g info
wifi5g ESSID: "Intellifi"
Access Point: E8:2C:6D:81:B4:6A
Mode: Master Channel: 64 (5.320 GHz)
Center Channel 1: 58 2: unknown
Tx-Power: 24 dBm Link Quality: 59/70
Signal: -51 dBm Noise: -91 dBm
Bit Rate: 952.7 MBit/s
Encryption: WPA2 PSK (CCMP)
Type: nl80211 HW Mode(s): 802.11nacax
Hardware: 14C3:7915 14C3:7915 [MediaTek MT7915E]
TX power offset: none
Frequency offset: none
Supports VAPs: yes PHY name: phy1
841-t6-B460-linux: ~ # iw dev wifi5g scan
command failed: Resource busy (-16)
841-t6-B460-linux: ~ #
If I switch to a non-DFS channel (such as 44) then scanning works.
For ETSI country codes my memory is a bit hazy.. I can't recall if they adopt the same behavior or if they allow scanning. Maybe @nbd knows off the top of his head.
I am, I’m on channel one 100. I’ll have to make a point to test on a non-DFS channel at some point. Maybe 1/10 of the scans will actually go through.
Can I update my firmware to rc6? Right now, my 2.4 ghz band wifi is sooo bad that even my mobile network is better than that.
Likewise, I'm using US DFS-FCC, channel 52. Am I correct in thinking this would also explain my observations back in May, when scanning did work, but it did so by killing the connection and just using a non-broadcasting radio?
I think the drop out when you scan is because it only has one 5G radio. Some routers have an extra radio just for DFS scanning.
Any examples?
Some call it zero-wait DFS.