schedutil governor is enabled (but seem to be not the default) in imx6, armv7, mt7622 and tegra targets. So maybe it will become more popular and eventually default for more targets in the future.
Are there any disadvantages to operating permanently in 'performance' mode? eg. overheating, stability?
I'm currently testing this on my EA6350 (added to /etc/rc.local script), alternating with NoTengoBattery's optimised build. Used only as a simple WAP so probably not CPU intensive.
performance governor and the
ondemand governor had the same idle power usage on my power meter (which has an accuracy of 100 mW), so I see no real downside in using the
It may increase the heat generation and power usage overall a little bit, as there is no delay from frequency switching to the more power hungry operation mode once the CPU has load. If the device does get little ventilation or is located in a generally warm place (think closed cabinet or with direct sun exposure), I would recommend sticking to
ondemand, just to be safe.
If the device is under constant and/or heavy load, it's probably better to stay with
ondemand to allow lower CPU frequencies and avoid thermal throttling.
Turning off one radio or reducing the transmit power does way more for the idle consumption.
I have not tested the impact of using USB.
EA6350 is not in an exposed location to heat etc.
I changed it back to 'ondemand' about 30 minutes ago. Speed tests only slightly improved to 15 Mbps if thermal throttling is suspected. Rebooting EA6350 is next task. I'm using 19.07.0-rc2.
I have to admit when previously testing OpenWrt (with default settings) as a WAP , I can't remember whether I checked speeds after a day or two of use before switching back to Linksys OEM firmware.
Correction. Turned out to be issue with laptop
If you use it only as pure WAP, there is probably not a lot of CPU load and thus not a lot of heat from the CPU.
I switched to
performance to help SQM performance as well as DNS lookups with DNSSEC... both of these are not stellar at the initial 48 MHz. Maybe 200 MHz mininum frequency on
ondemand is a good compromise.
Oops!! My mistake.
Rebooted EA6350. Low speeds persisted....
I then decided to check speeds with two other computers and they were fine....
It was the laptop I was using that is mysteriously returning low speed test results all of a sudden. Never had issues before with this laptop.
I will return to using 'performance' setting on EA6350.
Update: It looks like the issue I am having with some old Intel wifi cards (6205 and 6300). It is NOT related to the bug in hostapd v2.9.
I flashed an old 19.07-r10293-snapshot to my EA6350v3 and speed tests no longer capped at 12-15 Mbps with Intel 6300 wifi card on 2.4 and 5 GHz. All OK.
Update 2: Discovered a buffering problem old Roberts Stream 83i internet radio with 802.11 b/g wifi. OpenWrt reported downstream link speed was only 2.8 Mbps (upstream was usual 54 Mbps). I've now abandoned using OpenWrt as a pure AP, and returned to using 'Access Point' mode in LInksys OEM firmware.
Are the pings any different on the old snapshot with good throughput compared to the newer affected 19.07.0-xx versions?
I still have to apply your 'performance' fix to reduce ping times.
I found several old snapshot files and uploaded them to my dropbox for anyone who wishes to try them. Look in the 'Old Snapshots' folder:
Gigabit LAN to 5 GHz AC 80MHz wifi transfer speeds appear to be similar to what I previously tested with 19.07.0-rc2 on EA6350v3 with a Windows 10 laptop fitted with Intel AC7260 2x2 wifi card. ie. not as good as stock Linksys OEM firmware, but can still manage 330+ Mbps when briefly tested with iperf3 with multiple streams.
I have the same problem with the DVFS governor and wireguard on Zyxel nbg6617. If I let the default ondemand then wireguard throuput is very low(probably it doesn't reach the up threshold?) but with the performance governor everything is back to snapshot performance. That and the hostapd 2.8 downgrade have returned the peformance back to normal.
I'm also experiencing this on my Fritzbox 4040 thats doing NAT/AP and ad blocking. Both with latest snapshot and the stable. Pings are between 100-200ms from lan -> wifi and wifi -> wifi.
The speeds are good but the pings are all over the place. Sometimes it even starts out with some packet loss. On the stock firmware pings are all below 10ms.
Is this fixable or an issue with the chipset? I'm still within the return period and I much rather swap it out for something else if there's issues with this platform.
Have you tried the fix described in
Forcing the processor to constantly run at full speed is not a fix. Not to mention a waste of energy and potential shortening of it’s lifespan.
But have you tried it, even if only briefly, to confirm setting SoC to maximum performance does not fix your issue?
This thread discussed the 'small' increase in latency. eg. <5 ms.
Whereas, the excessive >100 ms pings times you are witnessing suggest you have a different problem.
The latest hostapd 2.9 fix (in 19.07.1) addressed poor throughput and excessive ping times affecting certain wifi chipsets fitted to devices.
But I still had issues with poor speeds (not ping times) with 2 devices, so had to abandon openwrt and revert to linksys OEM firmware for AP use.
Ohh thanks! I misinterpreted the fix as permanent fix. I can try for a while yes, do some experimenting with different hosted versions too. The cpu itself isn't overloaded or anything (if I can believe the graphs).
I'm quite happy with the router and luckily the 'lag' isn't there all the time but the delays when its there when opening websites is annoying. I might also try to disable everything thats not essential though I doubt that will help given ram and cpu is plenty for the simple tasks I gave it.
Experienced this as well with my Zyxel NBG6617, fix from @bill888 works. Still getting ping spikes but unsure if this is down to OpenWrt or not.
Since you asked, I have a fritzbox 7530 gone from 19.07.7 > 21.02.0-rc2 and both suffering from LAN latency however at first i was getting limit speeds over LAN > WAN and was capped at 600Mbps however when investigating with htop i can see that only CPU 0 was been hit maxed with other 1-3 cores was sort of IDLE,
irqbalance help and max my 1G FTTH connection at about 950Mbps what is good enough but the ping latency still reminds.there,
Router > NAS via LAN
root@FB750:~# ping 192.168.2.10 PING 192.168.2.10 (192.168.2.10): 56 data bytes 64 bytes from 192.168.2.10: seq=0 ttl=128 time=0.605 ms 64 bytes from 192.168.2.10: seq=1 ttl=128 time=2.152 ms 64 bytes from 192.168.2.10: seq=2 ttl=128 time=2.193 ms 64 bytes from 192.168.2.10: seq=3 ttl=128 time=3.716 ms 64 bytes from 192.168.2.10: seq=4 ttl=128 time=2.646 ms 64 bytes from 192.168.2.10: seq=5 ttl=128 time=2.216 ms
I found a solution to the fix that might help someone thanks to @bill888 no need for the CPU freq to change.
echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor echo performance > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor echo performance > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor
Router > NAS via LAN
root@FB750:~# ping 192.168.2.10 PING 192.168.2.10 (192.168.2.10): 56 data bytes 64 bytes from 192.168.2.10: seq=0 ttl=128 time=0.589 ms 64 bytes from 192.168.2.10: seq=1 ttl=128 time=0.513 ms 64 bytes from 192.168.2.10: seq=2 ttl=128 time=0.512 ms 64 bytes from 192.168.2.10: seq=3 ttl=128 time=0.503 ms 64 bytes from 192.168.2.10: seq=4 ttl=128 time=0.510 ms 64 bytes from 192.168.2.10: seq=5 ttl=128 time=0.509 ms
To everyone, are you sure your wifi host is not using power save mode? This, in addition to following much of the advice in this thread, solved the ping spikes for me when pinging my desktop, which is connected via wifi. I knew that the RF environment was more or less perfect. Now I get consistent sub 5ms pings, instead of spikes that could rocket up to over 4000ms.
I don't have WiFi enabled, Is just a pure LAN only router and using WAN for PPPoE