Systemd on (some) older hardware

[j2mcgreg]

@retroD0d0 wrote:

I was hoping to migrate my e-350 to MX too when W10 is EoL. Bit worried now

Try booting it into a live session so you won't affect your Win 10 install. You'll know in a hurry whether it's performance is acceptable.

[Nokkaelaein]

It's generally known that there is at least a slight performance hit when using MX with SystemD on any system regardless of age or complexity.

@j2mcgreg, see my previous post about this. If it's "generally known" MX performs worse when the init system is SystemD, regardless of hardware, it would be nice if you (or someone else in the MX team) could comment on it a bit more. What does a "performance hit" mean in this context, what kind of use, and what areas of operation are effected? Are there any technical stats/info on this available, and so on.

[paul1149]

If you don't mind a bit of fan noise (and warm fingers), have you thought about changing the CPU governor?

I wasn't aware of that. Cool. It is set to on-demand. I'm loathe to push it further, at this time anyway, but I will keep this gem in mind. The cpu has three frequencies, 780khz, 1.1mhz, and 1.3mhz. It doesn't take much to send it to level 3.

[paul1149]

@retroD0d0 , I did a little digging, and the schedutil level sounds very interesting. It sounds almost as strong as Performance, but willing to step down when unneeded.

Brave AI tells me:

Linux CPU Governor Levels

The "schedutil" governor in Linux aims to better integrate with the Linux kernel scheduler, allowing for dynamic frequency scaling based on system load It is designed to optimize CPU performance and power consumption by coordinating closely with the scheduler to determine the appropriate frequency for each CPU core This governor is increasingly becoming the default for many distributions, especially for AMD hardware

For AMD processors, the "amd_pstate" driver supports three operation modes: CPPC autonomous (active) mode, CPPC non-autonomous (passive) mode, and CPPC guided autonomous (guided) mode. The default mode is active, which can be changed with the kernel parameter `amd_pstate=active`, `amd_pstate=passive`, or `amd_pstate=guided`

In a comparison of the "schedutil" governor with the "performance" governor on a patched Linux 5.11 kernel, the performance governor was found to be just over 1% faster on average, but the difference was not significant in most workloads

To check the current CPU governor, you can use the `cpupower frequency-info` command or inspect the `/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor` file in the sysfs virtual file system

* Schedutil: Aims at better integration with the Linux kernel scheduler, optimizing CPU performance and power consumption
* Performance: Provides a constant high-performance state, often slightly faster than "schedutil" but with less power efficiency

[retroD0d0]

I'm loathe to push it further, at this time anyway,

I understand, my e-350 is actually in a nettop on a cabinet connected to a TV. At that distance, noise isn't an issue and the unit has a capable fan. The APUs (e-300/350) are only 18W TDP. However, with a laptop, the increased noise and heat can distract when it's under your fingertips. Good luck experimenting!

Try booting it into a live session so you won't affect your Win 10 install. You'll know in a hurry whether it's performance is acceptable.

Thx, and yes. I will of course.

@j2mcgreg, see my previous post about this. If it's "generally known" MX performs worse when the init system is SystemD, regardless of hardware, it would be nice if you (or someone else in the MX team) could comment on it a bit more. What does a "performance hit" mean in this context, what kind of use, and what areas of operation are effected? Are there any technical stats/info on this available, and so on.

Hi, I'm guessing no formal quantative analysis has been done on the performance delta between both init systems on MX. Actually I wasn't aware it could be such an issue but it might go some way to explaining why MX is so, subjectively speaking, performant on older hardware. Maybe a thread where people post their benchmarks in both modes could be informative? How/What to benchmark I am unsure yet.

[Nokkaelaein]

Hi, I'm guessing no formal quantative analysis has been done on the performance delta between both init systems on MX. Actually I wasn't aware it could be such an issue but it might go some way to explaining why MX is so, subjectively speaking, performant on older hardware. Maybe a thread where people post their benchmarks in both modes could be informative? How/What to benchmark I am unsure yet.

A benchmarking thread would be informative. My interest was piqued, I mean, if a forum staff member says it's generally known that there is some kind of performance hit in the distro on any system regardless of age or complexity, this comment must be based on some actual known data, right? So regardless of system age or complexity, in what use and in what way is there such a hit, and how can it be observed on any system. That's what I'm getting at. If it's generally known, then it can also likely be more specifically described and defined. Having used MX based systems for years, this kind of stuff is interesting to me, and if it's brought up in a general sense, a more detailed description would be nice.

[retroD0d0]

if a forum staff member says it's generally known that there is some kind of performance hit in the distro on any system regardless of age or complexity, this comment must be based on some actual known data, right?

I think he may have been giving his considerable experience gleaned from moderating the forums. We can't expect someone who is responsible for chaperoning community discussion to be intimately familiar with technical issues related to development. That would be something for the dev team themselves. Also, we can't assume this to be a particular priority for them either, especially given a conclusive opinion already appears to have been formed.

Yes, MX being the only distro of it's kind to offer dual init functionality offers the ideal opportunity to be a testbed for assessing init system performance impact, as in either mode, apart from the init systems, all factors remain identical (I think?) and therefore it presents a controlled environment to do fair testing.

If there is one thing I have learned using Linux, especially with a community distro, is that we can't expect this work to be done for us. We may have play our part ourselves! Hence why I suggested one of us in the community start a thread to gather some tangible data on the subject.

[j2mcgreg]

My $0.02. We have two init systems available with MX and while they are both exceptionally fast, one of them is going to be faster. That's just the way it is. For most people the difference will be almost imperceptible or they just won't care. For the rest, I say that there are bigger things in Linux to get busy about.

[paul1149]

I've got to say I'm perplexed at this machine. Everything was working well. I shut it down for the night, then the next day, with no changes having been done, it was back to it messed-up self again. It was restless, at war with itself, seldom dipping below CPU 15%. The mouse pointer was jerky and imprecise. Programs took long to close, or wouldn't close on mouse click. (It did close instantly via panel menu, but unplugging the mouse changed nothing, so I don’t think it's the cause.). All this was under SysV, not SysD.

Online advice said to reinstall a certain xorg service library. I went to, and found it wasn't installed, so I installed it. I also did a full update, consisting of 5 items. The last item, I saw, was a kernel update, to 6.1.x.37. Fine, I thought, maybe it will help. But the install froze at 76%. When I tried it in MXPI, the new kernel was not to be found. (it's currently on xxx.35)

Now the machine wouldn't shut down, kept delivering me to the login screen, so I forced it down. On reboot, that problem disappeared. And so did the CPU problem. Everything was perfect. Immediate regression to 1% CPU, perfect mouse, etc. I thought the updates had solved the problem. Even took another snapshot.

On the next reboot, the problem was back. At this, I turned my attention to the hardware. But the drive checked out good on a Long test. I changed the RAM. No difference.

At this point I would have to say that the problem probably isn’t related to Systemd after all. My next move may be to try this snapshot on another unit, if it works that might indict something in this hardware.

[CharlesV]

With that old of a hard drive ( 13 years - or more.. unless you have replaced it or seen a different date ) , I think you are seeing the beginning of hard drive issues.

My experience with Hitachi drives is that they do not show any indication of failure... until they fail. They *may* start having trouble finding / loading files, before they go, and this sounds kind of like that. (ie loading one time good, another time badly.etc)

I would try a small, fast ssd in that machine and see if it acts better.