Re: Core Update 159 (testing) report

Re: Core Update 159 (testing) report

[Bernhard Bitsch]

[-- Attachment #1: Type: text/plain, Size: 3086 bytes --]

Hello,

Am 04.08.2021 um 20:37 schrieb Peter Müller:
> Hello *,
> 
> Core Update 159 (testing, see: 
> https://blog.ipfire.org/post/ipfire-2-25-core-update-159-available-for-testing) 
> 
> 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.
> 
> 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.
> 
> 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. :-)
> 
> 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.
>

I do see this glitch in Core Update 158 also (sometimes). I think it is 
generated by the temporarily load for graph generation.

Regards,
Bernhard

> 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. :-)
> 
> Thanks, and best regards,
> Peter Müller

Re: Core Update 159 (testing) report

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 3838 bytes --]

Thank you Peter, for this very detailed report.

> On 4 Aug 2021, at 20:37, Peter Müller <peter.mueller(a)ipfire.org> wrote:
> 
> Hello *,
> 
> Core Update 159 (testing, see: https://blog.ipfire.org/post/ipfire-2-25-core-update-159-available-for-testing)
> 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>