[multicore-sys-monitor@ccadeptic23] Stuttering during video playback, indeed caused by the multicore-sys-monitor Applet

[SteffenDuenner]

Applet version/Build date

2.2.1

Cinnamon version

6.4.8

Distribution

22.1

Graphics hardware and driver used

NVIDIA GeForce RTX 2070 SUPER Mobile / Max-Q, drivers 575.57.08

Applet name and maintainer

multicore-sys-monitor@ccadeptic23 @claudiux

What happened?

At first I didn't connect this to this applet, but after investigating stuttering video playback in windowed mode (that I haven't had any problems with before) I noticed, it had to do with the 2.x release of the multicore-sys-monitor's refresh rate.

Indeed not only video playback is affected but e.g. also smooth browser scrolling or moving windows.
After recreating my X-settings, reinstalling nVidia-drivers, checking my monitor's sync and refresh rate, checking mutter compositor's settings I noticed that removing the multicore-sys-monitor applet solved all my stuttering problems. The stuttering happened every 1000ms = the applet's refresh rate.

Something seems to upset the compositor, which the 1.x versions didn't.

Other information

No response

[SteffenDuenner]

Another quick way to see the stuttering is running the glxgears app.
The gears had a hickup every second, but now with multicore-sys-monitor removed the gears spin buttery smooth.

[SteffenDuenner]

Oh, and even when using "Without any Graphics" it still stutters.

[Bernsteinnn]

Thanks for this report! I didn't notice any obvious stuttering in normal desktop use, but the issue is pretty noticeable in glxgears
Removing the applet instantly fixed a stutter issue in an OpenGL app I spent a long time troubleshooting with no effect.

Something seems to upset the compositor, which the 1.x versions didn't.

I'm not entirely sure about the second part; the 1000ms OpenGL stutter I mentioned earlier was already present before the 2.0.0 launch. It's entirely possible that the apparently extensive 2.0 update exacerbated the issue - see also #7458.
This Reddit post mentioned resource monitoring applets in general causing performance issues for some, and, as you suggested, that's possibly related to how the applets interact with the compositor.

I'm not sure this issue can be fully resolved.

[SteffenDuenner]

Thanks for your reply.

Maybe I didn't notice the stuttering with pre-2.0 versions because I had some other performance problems during the past few days (with nvmes going into sleep mode and never waking up again, which is now "fixed" by not allowing them to sleep anymore ;) ).
Currently I removed the much loved multicore-sys-monitor applet and replaced it with this alternative:

... and notice zero performance issues. Actually my system is running smoother than ever before (4k60fps videos run like butter in the browser and in all players like VLC or MPV). So there must be a secret way to keep everything smooth.

[Bernsteinnn]

I just want to emphasize again how your bug report solved an issue that I spent hours troubleshooting. As someone who recently had to switch to Linux with only surface-level knowledge of how components interact, I would never have imagined that a resource-monitoring applet could cause these kinds of problems.

Currently I removed the much loved multicore-sys-monitor applet

Yeah, same. While I wasn’t affected by the bugs introduced in 2.0 to the same extent, the OpenGL stutter is, unfortunately, a dealbreaker. I ended up removing all hardware monitor applets, actually.

replaced it with this alternative

So did I! Then I ran glxgears ... A different applet caused these issues; sysmonitor@orcus doesn't seem to introduce noticeable stutter.

So there must be a secret way to keep everything smooth.

To look at it charitably, the codebase has been stable for nearly half a decade, and the last few changes have mostly focused on minimizing these kinds of issues. Not introducing complexity by adding new features might have helped.

However, it appears that designing a system-monitoring applet that doesn’t introduce disproportionate overhead is essentially impossible. requires a specific approach.
See here and here.

Some applets evidently cause more noticeable issues than others, and while it's possible to reduce their impact by increasing refresh intervals, this seems to be something that authors can mitigate but never entirely prevent.

Edit: Retested sysmonitor@orcus and took a closer look at both its code and the GLib issue; I've changed a few inaccurate points accordingly.

@SteffenDuenner's comment below is much more concise, and I would appreciate hearing @claudiux’s thoughts on this.

[SteffenDuenner]

After reading this, I found that multicore-sys-monitor@ccadeptic23 was using GLib.spawn_async_with_pipes() or the async Gio.Subprocess() , while sysmonitor@orcus isn't using it.
Since I switched to the sysmonitor@orcus applet I didn't have any stutters or higher CPU usage, maybe this could help multicore-sys-monitor, too?

[Bernsteinnn]

I’m still seeing a very noticeable amount of stutter with multicore-sys-monitor@ccadeptic23 compared to sysmonitor@orcus on my system. It’s easy to reproduce just by running glxgears.

[Bernsteinnn]

Unfortunately, no significant change with 2.6.0.

[claudiux]

@SteffenDuenner

After reading this, I found that multicore-sys-monitor@ccadeptic23 was using GLib.spawn_async_with_pipes() or the async Gio.Subprocess() , while sysmonitor@orcus isn't using it. Since I switched to the sysmonitor@orcus applet I didn't have any stutters or higher CPU usage, maybe this could help multicore-sys-monitor, too?

The version for Cinnamon 6.4 does not use GLib.spawn_async_with_pipes() nor the async Gio.Subprocess() nor glibtop from GTop, which is not recommended by the Cinnamon team.

Unlike other system monitoring applets, this one is not classified as dangerous (⚠︎) by Cinnamon 6.4:

[claudiux]

Starting with version 2.9.0 of multicore-sys-monitor@ccadeptic23, data retrieval time has been reduced by a factor of 50!