It doesn't 
I'd just like to get the most out of the device, it is not about it being usable or unusable.
Look at the work done within the Make Wi-Fi Fast project... they fight for every ms!
Joining a bit the discussion:
Let's be clear: the clock frequency is an important factor but it's not the actual solution. More fine tuning is needed, and some of it is already included in my custom build from things I've learnt from the OEM firmware.
That makes a difference, as noted by @bill888. It's a clear difference even between the rc2 with the clock a max speed. Source code of my work is available for anyone to test it but...
It will never ever reach OpenWrt upstream. See, they are really "conservative" and the latency fixed done by Linksys and tuned by me can be considered "too cutting edge". I have no problems with it, and I know what I do: I came from XDA-Developers so I understand how to tune an embedded Linux system. Still, they won't accept any of these changes ever. It's a shame to close the door to improvements in the sake of "stability".
Among other things, my custom build includes:
- Overclocking (optional)
- A brand new clock frequency scaling
- Fully preemptive, tickless @ 500Hz kernel
- Removed the double tagging of the WAN/LAN switch
- System daemons are actually fine tuned using a tool which is only available for desktops (chrt), boosting system responsiveness under load (read SQM/OpenVPN)
- A brand new subsystem for compressed memory designed and fine tuned by me to avoid memory starvation under pressure (read Samba/CIFS)
All of them works and help, but none of them will reach upstream ever. Give my snapshots a try and then you can grab some modifications to build your own image!
The brand new scheduler "schedutil" has proven to be superior in every aspect compared to the "ondemand". In fact, the Linux people want to replace all governors with "schedutil" some day. The problem: it requires a modification to the kernel in order to enable it. OpenWrt will not ever think of getting it upstream.
No positive changes with this so far:
-
ondemandsettings from nbg6617 firmware as pointed out by @mezo - ath10k-ct driver with ath10k firmware (newest 10.4-3.5.3-00078 as well as 10.4-3.6-00140)
- ath10k-ct-smallbuffers
- switch to a
CONFIG_PREEMPT=ykernel - fixing
sleep_clkfrom32768to32000and setting this 32 kHz clock for e.g.wcss5g_rtc_clk - looking for something else in the kernel patches and config in the Linksys GPL code
- irqbalance on/off
The 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.
The 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 performance governor.
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.
https://forum.openwrt.org/t/zyxel-nbg6617-ipq4019-regression-in-wifi-5ghz/50544
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.
1 Like
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:
https://www.dropbox.com/sh/ikepkmlqfqi02vw/AACuSniTpvQgFTJQ2w7bn8gCa?dl=0
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
https://forum.openwrt.org/t/ipq40xx-ea6350-v3-as-wap-wifi-to-lan-latency/51623/22
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.
https://bugs.openwrt.org/index.php?do=details&task_id=2679
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.
1 Like
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.