Thank you Peter, for this very detailed report.
On 4 Aug 2021, at 20:37, Peter Müller peter.mueller@ipfire.org wrote:
Hello *,
Core Update 159 (testing, see: https://blog.ipfire.org/post/ipfire-2-25-core-update-159-available-for-testi...) is running here for about 24 hours by now, without any noticeable issue during after the upgrade procedure so far.
While upgrading to the testing release, I noticed the Pakfire CGI not displaying the usual log and progress indicator. Instead, it appeared to have stalled while downloading the update itself - this is a rather aesthetic issue, but might confuse users because they could suspect their IPFire machine crashed.
Having installed the upgrade, the Pakfire CGI required a reload to properly display Core Update 159 as being installed, and a reboot being necessary. This may or may not be related to the missing upgrade procedure indicator.
Having rebooted, I enjoy the Linux kernel 5.10.x ever since. On my testing machine (running an Intel N3150 CPU), it improved the following aspects:
- IRQ load decreased significantly, from about 5 to 2.2 percent on my machine.
- Governing the CPU frequency now works better - before, the machine used to run at maximum frequency all the
time, despite cpufreq(|utils) being installed and active.
- Measured latencies to my PPPoE gateway are now more evenly, most probably due to increased networking
schedulers or other improved algorithms. While this is not a noticeable change in the daily usage, it can be measured for VoIP calls and VPN connections as well. This might affect IPFire users sitting behind more unreliable connections even more.
This is great news. Arne said that he doesn’t feel that the new kernel has improved performance very much, but this suggests it does.
I am planning to test with Daniel on our appliances next week so that we have some tangible numbers and we can see from there.
Do you have graphs for these things, too?
Speaking of VoIP calls, I am currently unable to test if the sporadic broken RTP streams occur again. They were never really reproducible well, and got more rare after Core Update 157 - let's hope kernel 5.10.x finally fixes this. If not, I will report back.
Please do.
IPS performance hasn't improved much on my machine: The bandwidth available to clients behind IPFire still differs by orders of magnitude if the IPS is enabled or not. To be fair, my testing machine is not very well equipped (passive NICs and a weak Intel CPU - yuck), and you can't have your cake and eat it. I am not complaining. :-)
Yes, this is going to be a massive pain point and we should have a look at this soon.
Lots of “common” hardware is way too weak to handle the IPS and that is a problem. People switch it off and disable a massively important feature that keeps their network safe and/or provides insight.
Skimming through IPFire's web interface, I noticed a small glitch regarding the CPU load graph: In some occasions, it shows the CPU to be running on full load (see attached sample). After reloading the graph, the load is actually fine. This looks confusing at first, too, but does not seem to indicate something more serious.
That seems to be a rendering issue. I have observed this too. However, the load isn’t being checked live. It would be the data point that was collected last that is being printed and an actual outlier. I am not sure what can be done about this.
To cut it short: I look forward to the release of Core Update 159. Special thanks of mine go to Arne for making this updated Linux kernel possible. :-)
*thumbs up*
-Michael
Thanks, and best regards, Peter Müller <ipfire_c159_cpu_load_graph_uptick.png>