Random dives in FPS in almost all games

General system Gaming, sound and video
1

inxi -Fxza

Basically, my problem is that when I’m playing something such as Sonic Robo Blast 2, a game in GZDoom, playing PsyDoom, Minecraft (modded for performance), or other potato-ish games, so no Baldur’s Gate 3 or Doom: The Dark Ages here. This has been happening for a long while and I got fed up with my brother getting free frags on me because of that.

I can set the games to lower settings so I can actually run the game at a consistent 60 FPS, and depending on the game, it’s usually just reducing the draw distance, turning off extra effects, etc., since most of the games I take an interest to are not particularly demanding anyway, and my other laptop (worse and has a broken fan) doesn’t have this issue. (For context, my laptop is passively cooled, and it’s never overheated ever.)

Then intermittently, the sound completely stops, and my FPS drops to a consistent 10-ish, then it’s back to normal for a while (usually 60, but if the game was already lagging, it’ll go back to that framerate with sound), and back over and over again. Restarting just seems to delay the first occurrence, but after that it doesn’t matter. The game looks some guy “playing” a video by holding forward in PowerPoint, where each slide is one frame of the video.

Side Tangent

The only programs this doesn’t happen with are Chocolate Doom (duh, you’re essentially playing the same thing as Doom back in 1993) and DuckStation (PS1 emulator, occasional microstutters occur instead, probably unrelated), and the same games on Windows run flawlessly (these programs have native Linux versions).

This does happen with Dolphin (the emulator, I play Smash Bros. games in it, well offline anyway, don’t ask me how I get it playable on my hardware) but what ends up happening is the game slowing down, and then speeding up too much, then at normal speed. This is also probably unrelated, as DuckStation uses Cubeb by default (I left it at that), and Dolphin has the options to use Cubeb, PulseAudio, or ALSA. I use ALSA in this case as Cubeb sounds weird. Of course, using no sound output is possible, but that’s lame.

2

I think this is miracle any game works on your laptop :slight_smile:

  1. Your BIOS needs update * F.75 Rev.A
  2. You have ZRAM - so it put’s extra stress on CPU. This could explain difference between Linux and Windows. And when you swap you swap to rotating hard disk - which is another bottleneck
  3. It always overheats - just thermally throttles. When was last time you cleaned inside and repasted?
  4. You can still squeeze more performance - disable CPU bugs mitigations, use noatime and commit=60 , disable networking or try iwd
  5. Btrfs has sligtly higher CPU usage than other file systems. So whenever game reads something from disk, you get CPU penalty

So yeah, on a system with slow processor, you want to minimize CPU work. ZRAM and Btrfs does not seem like a good fit for you. Ext4 would be a better choice.

Zen kernel or LQX also may yield better results.

1 Like
3

CPU’s will throttle down, in order to prevent overheating. So it’s a given that your CPU won’t overheat, but it will certainly get slower in the effort to not overheat.

You have an Intel Pentium N3710, which is a very low-end CPU even in it’s day (2016). For context, here’s how the Pentium N3710 compares against an even older 2015 mid-range Intel Core i5-6600K.

image
image1741×1934 175 KB

I don’t wish to discourage you, as I think these sorts of challenges are actually interesting. How can you squeeze the most out of a limited system? That sort of thing takes some consideration and thought.

@gladykov has offered some good pointers, but as a rule, you’ll need to fight for every bit of performance, and accept the limitations of the hardware.

4
Tangent

I think this is miracle any game works on your laptop :slight_smile:

I dunno about you, but a 2015 CPU can definitely run a 1993 game at a higher resolution :slight_smile:

Your BIOS needs update * F.75 Rev.A

I’ll get on it. Done.

You have ZRAM - so it put’s extra stress on CPU. This could explain difference between Linux and Windows. And when you swap you swap to rotating hard disk - which is another bottleneck

I never knew that (or I forgot). I know I’m swapping to a hard disk, but increasing the swap file from 4 to 8 GB (so more RAM is free in the first place) didn’t help.

It always overheats - just thermally throttles. When was last time you cleaned inside and repasted?

My other laptop with a broken fan, inxi -Fxza is here (AMD E2 Vision, lol) actually overheats (thermal shutdown) but you can’t tell until your progress turns into dopefish crap (or feeling the hot machine and deciding to save and quit). Also, this machine is a laptop that I’m too scared to open tbh, and as a result has never been repasted (laptops are hard to come by). I’ve always been the software guy, lol.

You can still squeeze more performance - disable CPU bugs mitigations, use noatime and commit=60 , disable networking or try iwd

I am already using noatime, it’s all over my /etc/fstab/ (well except my ESP and swapfile anyway, do those matter?)

I can’t afford to disable networking, normies (not me) use this system too. I’ll still test commit=60 however. Hell, I’ll even use mitigations=off if I really have to, but not even my other potato needs that.

Btrfs has sligtly higher CPU usage than other file systems. So whenever game reads something from disk, you get CPU penalty

If this ends up to be the causing factor then so be it, but I don’t think this is the case. My other laptop (that I know for certain is a weaker system) uses Btrfs and other than the overheating issue (caused by a broken fan) is working perfectly.

Zen kernel or LQX also may yield better results.

I’ll look at it, but I have rather exotic kernel modules if I say so myself, and I’d rather not deal with the headache unless I absolutely have to (don’t take this as me being picky with my solutions).

You have an Intel Pentium N3710, which is a very low-end CPU even in it’s day (2016).

I have known that for a while.

I don’t wish to discourage you, as I think these sorts of challenges are actually interesting. How can you squeeze the most out of a limited system?

I did not choose this system for myself, but I make the best out of it.

(and if you’re wondering why my other laptop is in the picture, it’s because it doesn’t have any of these issues but I know for certain it’s a weaker system (for example, Mario 64 chokes on it but does fine on my main laptop)

What I’ve tried: commit=60, BIOS update.
What I already did: noatime, disable zram*
What I haven’t tried yet: mitigations=off, reformat to use ext4, disabling networking (lol).

Asterisks

.* sudo zramctl returns nothing

Anyways, thanks for the responses, hopefully they fix the problem.

5

Just to clarify, you’re using the standard Arch zswap+swapfile config, not zram. With 4 GB RAM and 3 days uptime 320 MB swap seems totally healthy. What is the memory situation while gaming (free -h)?

Have you checked the journalctl after a stutter if something produced messages. Just to figure if some regular process is trying to run in the background. If even sound cuts out that usually indicates some serious load or I/O problems.

If you don’t want to switch kernels you could at least try a different scheduler. Just install scx-scheds and run e.g. sudo scx_bpfland before/while gaming.

6
Details

Just to clarify, you’re using the standard Arch zswap+swapfile config, not zram.

That explains why sudo zramctl returned nothing.

What is the memory situation while gaming (free -h)?

I assume you mean while it is and isn’t lagging, so I’ll add both.

Have you checked the journalctl after a stutter if something produced messages?

I’ll make sure to.

If you don’t want to switch kernels you could at least try a different scheduler. Just install scx-scheds and run e.g. sudo scx_bpfland before/while gaming.

I’ll make sure to try that.

What I’ve tried: commit=60, BIOS update.
What I’ve already done: noatime, no zram.
What I haven’t tried yet: mitigations=off, checking journalctl on stutter, checking free -h while in game, scx-scheds, disabling networking, and reformatting my drive to ext4 (lol).

7

Just to get a rough feeling, do we have memory pressure and a lot of swapping during the game, is there e.g. suddenly 2 GB of swap sitting on the HDD.

8

I haven’t checked yet, as I’m not exactly 100% available at this time, but I’ll make sure to. Sorry to keep you all waiting.

9

Totally fine, in that case let’s streamline the whole process. When you next look into the issue:

  • Start the game, let it run for a minute, tab out and do a cat /proc/meminfo
  • Repeat after the first stutter
  • Play for a few more stutters and repeat

With that we have three data points about what’s happening on the memory/swap front.

10

Here are the logs you asked for. If you need me to do the whole journalctl and free -h thing, that’s fine, just ask lol. These logs are for the game “Sonic Robo Blast 2”, and it happens to have an FPS counter.

Vanilla (1st minute here)

1 Minute

Stutter 1

Stutter 2

Stutter 3

Stutter 4

Stutter 5

With addons (I didn't restart the game for some reason)

Stutter 6

Stutter 7

Stutter 8

Stutter 9

Stutter 10

For more details on my very unscientific methodology, expand the below section.

Details (probably a tangent)

The 1st minute test and the first 5 stutters were with the vanilla game in the map “Meadow Match Zone”. Stutters 5-10 were on the same maps, but with 2 addons loaded: Battle Mod Jab Edition and Ringslinger NEO, these are addons we normally play with. Back when I used Windows, we used only regular Battle Mod as we only knew of that but even then there was no FPS difference (and keep in mind we used to play splitscreen!)

What I did was that I prepared a TTY (tty3 to be specific), then I’d prepare the command each time, then as soon as I felt an FPS dip (and the FPS counter turned red), I’d use the command with about a 1 second delay. The dips in vanilla were only to 20, lasted about 5 seconds each, and I felt there was approximately 5 minutes between each (like I said, very unscientific ideology). With the addons, the FPS dropped to 10 at about the same rate (maybe fewer and further between).

It doesn’t feel as bad as when I originally made the post, and that’s probably due to commit=60 rather than the UEFI BIOS update, as we don’t live in INT 21h days anymore, and that if it were purely a BIOS issue, Windows would’ve suffered too.

What I have tried so far: commit=60, BIOS update, sending cat /proc/meminfo results to @Schlaefer.
What I already tried: noatime, no zram.
What I have yet to try: mitigations=off, checking journalctl/free -h on stutter, scx-scheds, reformatting to ext4 (lol), and disabling networking (lol).

11

Ok, with that thorough data there seems to be zero issue with running out of memory, or swap playing any role. I think we can completely rule out anything related to memory or swap, or toying with zram. Imho.

The commit=60 can be tricky. It essentially indicates “do writing to disk less often”, but that also has the consequence of “when you do it, there’s more to do”, which could have a bigger impact when it happens. Tuning it feels like a long shot though.

We are aware of tuning a potato. So with that I would still be eager trying to figure out if there’s a background process spiking, which would be devastating with so few cores/threads available. Scx-scheds could help. That’s what I would try next if a more desktop oriented kernel like zen is out of the picture.

Not that I would expect wonders from zen either, just doing the best possible/eliminating variables.

12
Details

The commit=60 can be tricky. It essentially indicates “do writing to disk less often”, but that also has the consequence of “when you do it, there’s more to do”, which could have a bigger impact when it happens. Tuning it feels like a long shot though.

This means that I will potentially lose the last 60 seconds of work if there’s a crash, as it will only write every minute. This combines small writes into a big one which apparently helps performance.

What I have tried so far: commit=60, BIOS update, checking memory usage.
What I have yet to try: mitigations=off, checking journalctl on stutter, scx-scheds, reformatting to ext4 (lol), and disabling networking (lol).
What’s ruled out: Memory issues.

At this point it’s pretty late at my time, I’ll check out scx-scheds tomorrow morning.

13

tl;dr Yes, that’s what it means worst case.

I have no hard knowledge understanding all the code, so take it with the grain of salt.

There are other moving parts including the memory system influencing things (dirty_writeback, …). But it’s my understanding that a) this is the suggestion you indicate to the filesystem, and that’s the window of unwritten data that can be lost since it only exist in memory, and b) that is not an absolute, but an upper limit after you want to be sure that data is committed to disk - it can happen earlier.

14

I just checked my /etc/sysctl.d/ and I have 2 files there, them being 90-ethernet-share.conf and 90-override.conf. The first just enables some IP forwarding flags (read my featured post for why) and the second has these contents:

# This has been the default on Arch for a while, reason: Winblows games
vm.max_map_count=2147483642
# Apparently this controls how much the kernel likes to swap
vm.swappiness=1
# Apparently these function the opposite of commit=x? I'll go ahead and delete them.
vm.dirty_background_bytes = 0
vm.dirty_bytes = 0
15

Oh, I missed that little 1 for swappiness in the inxi, my brain just parsed it as “it’s on the default 60”. That changes some past interpretation. But - question aside if 1 is best for overall experience - from the meminfo we can still see you sit at 2+ GB free memory at all time. Imho the conclusion that it isn’t a memory/swap issue is still valid.

dirty_background_bytes and vm.dirty_bytes are 0 by default anyway (in which case vm.dirty_background_ratio/vm.dirty_ratio are used), so deleting them should not change any behavior.

16
Details

Also, scx-scheds didn’t seem to get rid of the stutters. It could be a coincidence, but I found that my FPS would dip ever-so-slightly less. And before you ask, I was using the sudo scx_bpfland command before I launched the game.

Also, after comparing the vulnerabilities section of both inxi’s, I found that my main machine is affected by mds, meltdown, mmio_stale_data, spectre_v1 and spectre_v2, but my other laptop is affected only by spectre_v1 and spectre_v2. This makes sense, as the other machine is an AMD system. However, even though both are affected by spectre_v2, my main machine mitigates it differently. That’s probably due to my main machine being an Intel system.

IMO, CPU manufacturers should be held liable for performance hacks that lead to vulnerabilities like this (we wouldn’t have grown to expect the performance otherwise), but this is a tangent for another day.

I’m just wondering maybe the extra mitigations that the other system doesn’t need are the reason I’m lagging out and it’s not, but unless Windows is also not mitigating these vulnerabilities, then it just doesn’t make sense.

What I’ve tried: commit=60, BIOS update, checking memory usage, and scx-scheds.
What I’ve yet to try: mitigations=off, journalctl on stutter (didn’t show a line when I tried), reformatting to ext4 (lol), Zen kernel (only if my modules work with it), and disabling networking (lol).

17

That makes sense, bpfland tries to give priority to interactive tasks while heavy background tasks are going on.

Just to point out the obvious, it was checked that nothing else spikes in the background during the stutter? All the other microptimizations like changing the file system or mitigations can make things run a little smoother, but wont save constant 60 to 10 fps dips.

18

Neither sudo journalctl -k -b0 nor sudo dmesg --follow showed anything of interest. Sometimes journalctl would show Under memory pressure, flushing caches., but this does not coincide with the slideshow periods and barely happens.

What I’ve tried: commit=60, BIOS update journalctl, scx_scheds, memory checks, noatime, no zram, vm.swapiness=1.

What I haven’t tried: using ext4 (lol), disabling networking (lolwut), mitigations=off, setting swapiness back to 60 (my other, weaker system uses this and has no issues)

19

Bump. I thought to open htop when my game was lagging and it showed that all my CPU cores were at 100% usage, while memory was barely half full (and swap was barely utilized)

What I’ve tried: commit=60, BIOS update journalctl, scx_scheds, memory checks, noatime, no zram, vm.swapiness=1.

What I haven’t tried: mitigations=off, using ext4 (lol), disabling networking (lolwut), setting swapiness back to 60 (my other, weaker system uses swappiness 1 and has no issues)

20
Tangent You May Want To Read

Well it’s AMAZING to discover that ext4 made no difference (after a day and a half of setting it up, thankfully I kept my btrfs system).

I kept all the sysctl.d settings at default, and commit too, so maybe adding them again would help (it hardly, if at all, helped my perfomance, probably placebo)

When I first used Endeavour (2020-ish), I didn’t have this problem, I believe it started happening last year, even without VMware kernel modules in memory.

So this means probably. some package(s) I installed on both systems are wildly slowing down my system. The only difference I noticed is a faster bootup, but we all know that goes away eventually.

Tangential Suspects:

  • VMware (maybe, kernel modules or services are suspects, but I enabled the path units and I’m definitely not running VMs while playing.
  • XScreensaver (its daemon appears at the bottom of htop, so probably not)
  • VirtualBox (was never installed on ext4, so probably not)
  • XFCE (it’s known for being light, so probably some plugin (like docklike-taskbar), but I highly doubt it.
  • Tilda (it runs in the background all the time, but it should consume less CPU than starting a terminal, lol)

On my btrfs install, I even tried ibt=off and mitigations=off and if there’s a difference I’m imagining it (placebo).

If you missed my last post, I mentioned that my CPU usage would spike to 100%, causing these sputters.

TL;DR: ext4 made no difference, probably some process eating my CPU.

What I’ve tried: commit=60, BIOS update journalctl, scx_scheds, memory checks, noatime, no zram, vm.swapiness=1, ext4 system (lol), ibt=off and mitigations=off.

What I haven’t tried: disabling networking completely (lolwut).