Strange slowdowns and hitches at random times. FPS is at 60, yet feels like 15.
First my hardware specs:
CPU: AMD Ryzen 5 5600X
GPU: nVidia Geforce RTX 3060 Ti (8GB)
RAM: 32GiB (2x16 dual channel) Mushkin Redline @ 4GHz
Storage: The game runs on a Western Digital 1TB Blue SN570 NVMe (M.2) which goes up to 3500MB/s, the OS is separate on a PNY CS900 which isn't great, but still does around 500MB/s -- good enough for Windows and fast saves and such.
I initially asked about this in the Steam forums here: https://steamcommunity.com/app/244850/discussions/6/6760518612022379073/ I was advised to make a report on here instead, however had been too busy at the time (plus had to reliably reproduce the issue in a save without any mods) so I didn't get to it until a couple of days ago. I started up Frostbite and have had the issue quite a number of times. I messed around with several settings and thought at first setting light down helped, but then it happened again, so obviously not, so I thought I'd go ahead and post on here.
Basically what happens is I'll be playing the game a while and then just seemingly at a completely random point it will slow down for a while. It seems most likely to happen a while after if I tab out for a bit but can even happen completely without that -- it may not even really be related and that may be confirmation bias. I really can't be sure. If I add ReShade to the game and turn on the FPS counter I will see it constantly locked at 60 FPS (my monitor's refresh rate.) I do have vsync set to on. At no point does it ever drop below 60. However, when it starts slowing down it can feel like 30, 15, maybe even less sometimes. One time I had this happen on one of the starter scenarios (Alien Planet I believe it was) when one of the drones crashed into the ground after I ground bottom thrusters as it thrashed around trying to rotate and move and it seemed like it actually was moving slower and pieces were falling off slower, so perhaps it's a matter of the internal simulation itself slowing down.
Of note, my CPU is more than good enough as I already mentioned. I tend to play with it set to a fixed 4.4GHz speed which is likely to be at or equal to the 4.5GHz i7 the game recommends (since it doesn't mention generation my bet is this is actually faster than whatever it was tested on since that was likely several generations ago.) I started loading the Windows task manager and setting it to the performance tab after this problem began and letting it collect performance graphs. Generally every core runs extremely low. I turned off SMT to get more accurate metrics and I think most of the time all but two cores never exceed 20% or so, while the two that go higher maybe reach as much as 45%. The GPU is maybe around 50% at all times during the game. If there is any performance bottleneck it isn't visible on the graphs.
The only thing left I guess would be the RAM, but it's running at 4GHz (2x2000MHz of course) with a matching uncore (yes this CPU can run the uncore at 2GHz) with decent latencies and a 1T command rate, so while I don't have a graph on it, I seriously doubt this game be limited by this RAM. The GPU's VRAM is nearly completely full at all times though, so I did sort of wonder if that could be at all related -- however, this game used to run ok on a different system with a 1060, which is two generations back and not even a Ti model with only 6GB of VRAM at the same resolution (1080p monitor.) So I doubt either of those could be causing a limitation.
I'm not completely sure, but I think maybe many times this happens there may be significant particle effects. Sometimes it does feel like it slows very slightly when I'm drilling and the black smoke effects occur for example. Obviously that drone being destroyed created quite a lot of sparks and I'm sure some smoke for another example. In Frostbite there are frequent storms with lots of wind and such and some of the slowdowns did occur around that time, though I was inside a semi-shelter (not airtight, but enclosed enough in that it toned down the effects.) The most recent slowdown occurred as I came close to a turret I had previously destroyed (eg it had flames and smoke.) I'm really not sure if this is the culprit or not though. It continues to remain slow even after the effects are gone (except the drilling if that is the same problem at all or even really slowing down -- it's really hard to tell.)
Unfortunately I had already ground down the turret when I thought to save, but I did make a save and I've attached it here just in case it could be of any use. It was still running slow after I had ground the turret though, so I can't even be sure if that was the cause or not. When I reload the save now it does not run slow at all though, so this probably isn't useful at all and I just included it just on the very unlikely chance anything could be done with it somehow.
Let me know if there is anything more useful I can provide.
I have the same bug
As an update, I just noticed something interesting today. While I've had several times I noticed it slowing down at the same time it says it's doing an autosave (though it slows down sometimes without an autosave too, so that isn't the cause or at least not the sole cause) if I actually manually save from the menu while it is slowed down, suddenly it gets a lot better. Maybe 90% of normal. Not quite 100%, but a huge improvement. I have no idea why manual saves would make any difference (especially since autosaves don't.)
As an update, I just noticed something interesting today. While I've had several times I noticed it slowing down at the same time it says it's doing an autosave (though it slows down sometimes without an autosave too, so that isn't the cause or at least not the sole cause) if I actually manually save from the menu while it is slowed down, suddenly it gets a lot better. Maybe 90% of normal. Not quite 100%, but a huge improvement. I have no idea why manual saves would make any difference (especially since autosaves don't.)
Hello, engineer!
Thank you for writing to us, and we sincerely apologize for the issue you have been experiencing.
Could you kindly check if the game is running on the high-end nVidia GPU and not on the integrated GPU? To check this, visit this page and follow the steps mentioned.
If the correct GPU is selected, please check if the issue is resolved when you change your graphics settings to either Low or Medium? You can do this by navigating to the Main Menu > Options > Graphics > Quality Preset. Change it to Low or Medium, and then click OK to save your settings.
If the issue persists even on Low or Medium graphics settings, please try the following steps that might help resolve the issue:
Verify your game files on Steam
Delete SpaceEngineers.cfg file
Delete ShaderCache folder
Once completed, relaunch the game via Steam and check if the issue persists.
If the issue still occurs, consider uninstalling the game and then reinstalling it on the same SSD where your OS is installed. Additionally, try running the game on your PC's main display/monitor, in case you are using multiple monitors.
After making these changes, relaunch the game and check if the issue has been resolved.
If the issue still occurs, while in the game, press Shift + F11 to enable world stats, which will show the game's current FPS and other details. Please send us a screen recording/video (with world stats enabled) showing the issue as it occurs, along with the log file.
Kind Regards,
Keen Software House: QA Department
Hello, engineer!
Thank you for writing to us, and we sincerely apologize for the issue you have been experiencing.
Could you kindly check if the game is running on the high-end nVidia GPU and not on the integrated GPU? To check this, visit this page and follow the steps mentioned.
If the correct GPU is selected, please check if the issue is resolved when you change your graphics settings to either Low or Medium? You can do this by navigating to the Main Menu > Options > Graphics > Quality Preset. Change it to Low or Medium, and then click OK to save your settings.
If the issue persists even on Low or Medium graphics settings, please try the following steps that might help resolve the issue:
Verify your game files on Steam
Delete SpaceEngineers.cfg file
Delete ShaderCache folder
Once completed, relaunch the game via Steam and check if the issue persists.
If the issue still occurs, consider uninstalling the game and then reinstalling it on the same SSD where your OS is installed. Additionally, try running the game on your PC's main display/monitor, in case you are using multiple monitors.
After making these changes, relaunch the game and check if the issue has been resolved.
If the issue still occurs, while in the game, press Shift + F11 to enable world stats, which will show the game's current FPS and other details. Please send us a screen recording/video (with world stats enabled) showing the issue as it occurs, along with the log file.
Kind Regards,
Keen Software House: QA Department
"Could you kindly check if the game is running on the high-end nVidia GPU and not on the integrated GPU? To check this, visit this page and follow the steps mentioned."
The Ryzen 5 5600X is not an APU -- it does not have any GPU cores. There is no integrated GPU of any sort in this system, only a discreet GPU (the 3060Ti.)
"If the correct GPU is selected, please check if the issue is resolved when you change your graphics settings to either Low or Medium? You can do this by navigating to the Main Menu > Options > Graphics > Quality Preset. Change it to Low or Medium, and then click OK to save your settings."
Well, I've already lowered graphics settings. As I said though, the actual FPS is still a full 60 at all times. As far as I can determine the graphics aren't actually a limiting factor here. If anything I'd wonder if it could be physics (assuming the game gets some sort of physics acceleration from the GPU?) BTW, I forgot to mention, but this is a LHR model GPU (supposed to limit mining hash rates.) Numerous people have assured me that hash rate limits absolutely can't ever affect any gaming, but I still wonder about some non graphical stuff (such as physics perhaps.) Everyone insists it can't affect that, but I wonder sometimes.
"If the issue still occurs, consider uninstalling the game and then reinstalling it on the same SSD where your OS is installed. Additionally, try running the game on your PC's main display/monitor, in case you are using multiple monitors."
I can't really install it on the drive with the OS due to its size. The OS drive is very small and pretty much 100% dedicated to the OS itself. No room for games. Also, the purpose of it being separate is that means that even if the OS performs file operations in the background it does not in any way bottleneck games. I might add that they aren't even on the same bus (in fact, the M.2. drive the game is on is NVME, so uses PCI-E and basically doesn't have to share a bus with anything else.) So no matter how you look at it, it should run better on that drive.
Anyway, I tried the steps. Unfortunately that did not fix it. I recorded a video with stats on and found a way to fairly reliably reproduce the issue. If I drive around the mountainous area somewhat fast it starts hitching a lot. The stats are kind of interesting. At no point does it list a FPS (or UPS -- I guess that means updates per second?) below 60, but I found it interesting that it would show GPU percentage as high as 80% at times while the Windows performance counter says the GPU is being used at an absolute max of about 40%. Similarly I think maybe the CPU threads are listed also higher in the game than what the performance counter says (I still have SMT off -- though of course I also tried having it on before with no difference -- so it only shows 6 cores instead of 12, so when it says 45% it really is 45%) though in this case it seems more like ~20% higher than what the performance counters show instead of double. Does the game try to intentionally use less than 100% and the scale is based on that adjusted value? Either way though, it never shows near or at 100% usage on CPU or GPU.
I really don't know how you want me to upload the video. Given its nature, to really show the skips, I had to record full resolution and at 60 FPS, so that gets very large and the maximum I can upload here is 64MB it seems. I could try to clip a very small segment out, but it would be very difficult to get it down to 64MB and still be useful. For now I uploaded it here: https://www.mediafire.com/file/d2tdag42zrvpapa/output.mp4/file If you need it uploaded differently let me know. I'd suggest that it's easiest to see the hitching at about 20 seconds in as I turn -- watch the tower in the distance and the skipping should be very obvious.
"Could you kindly check if the game is running on the high-end nVidia GPU and not on the integrated GPU? To check this, visit this page and follow the steps mentioned."
The Ryzen 5 5600X is not an APU -- it does not have any GPU cores. There is no integrated GPU of any sort in this system, only a discreet GPU (the 3060Ti.)
"If the correct GPU is selected, please check if the issue is resolved when you change your graphics settings to either Low or Medium? You can do this by navigating to the Main Menu > Options > Graphics > Quality Preset. Change it to Low or Medium, and then click OK to save your settings."
Well, I've already lowered graphics settings. As I said though, the actual FPS is still a full 60 at all times. As far as I can determine the graphics aren't actually a limiting factor here. If anything I'd wonder if it could be physics (assuming the game gets some sort of physics acceleration from the GPU?) BTW, I forgot to mention, but this is a LHR model GPU (supposed to limit mining hash rates.) Numerous people have assured me that hash rate limits absolutely can't ever affect any gaming, but I still wonder about some non graphical stuff (such as physics perhaps.) Everyone insists it can't affect that, but I wonder sometimes.
"If the issue still occurs, consider uninstalling the game and then reinstalling it on the same SSD where your OS is installed. Additionally, try running the game on your PC's main display/monitor, in case you are using multiple monitors."
I can't really install it on the drive with the OS due to its size. The OS drive is very small and pretty much 100% dedicated to the OS itself. No room for games. Also, the purpose of it being separate is that means that even if the OS performs file operations in the background it does not in any way bottleneck games. I might add that they aren't even on the same bus (in fact, the M.2. drive the game is on is NVME, so uses PCI-E and basically doesn't have to share a bus with anything else.) So no matter how you look at it, it should run better on that drive.
Anyway, I tried the steps. Unfortunately that did not fix it. I recorded a video with stats on and found a way to fairly reliably reproduce the issue. If I drive around the mountainous area somewhat fast it starts hitching a lot. The stats are kind of interesting. At no point does it list a FPS (or UPS -- I guess that means updates per second?) below 60, but I found it interesting that it would show GPU percentage as high as 80% at times while the Windows performance counter says the GPU is being used at an absolute max of about 40%. Similarly I think maybe the CPU threads are listed also higher in the game than what the performance counter says (I still have SMT off -- though of course I also tried having it on before with no difference -- so it only shows 6 cores instead of 12, so when it says 45% it really is 45%) though in this case it seems more like ~20% higher than what the performance counters show instead of double. Does the game try to intentionally use less than 100% and the scale is based on that adjusted value? Either way though, it never shows near or at 100% usage on CPU or GPU.
I really don't know how you want me to upload the video. Given its nature, to really show the skips, I had to record full resolution and at 60 FPS, so that gets very large and the maximum I can upload here is 64MB it seems. I could try to clip a very small segment out, but it would be very difficult to get it down to 64MB and still be useful. For now I uploaded it here: https://www.mediafire.com/file/d2tdag42zrvpapa/output.mp4/file If you need it uploaded differently let me know. I'd suggest that it's easiest to see the hitching at about 20 seconds in as I turn -- watch the tower in the distance and the skipping should be very obvious.
So I've had a bit of a thought on this. Does this game use any random number generation? Something where entropy could run out? And maybe it resets it or something when you save? I'm given to understand that AMD's implementation of hardware acceleration of random number generation via TPM (or I guess PSP?) is less than ideal currently with things that rely on it slowing considerably once entropy has run out. I'm not sure of the exact specifics of this, but I know there was a significant complaint in the Linux kernel -- though since it's an issue of how the hardware itself works it would apply to Windows too if anything uses it. Supposedly the only complete hardware fix is to use a hardware TPM module (which I currently can't afford -- assuming my motherboard will take one as its documentation doesn't say anything at all about TPM one way or the other and the only slot that looks promising is not labeled.) Supposedly software solutions work much more efficiently in such cases, but these days are good enough for anything but the most extreme security situations anyway. (Eg software entropy generation should be fine for gaming.)
I'm not sure if that is in any way applicable to this or necessarily any other game, but it did make me wonder. I know there were hitching issues in the past directly related to TPM with the Zen 3 architecture, though those were supposed to have been fixed in 2022 via updates that were already integrated into boards before I got my current hardware so I can't help but to wonder if this could still be related. Since I currently can't afford to try an external TPM module to test with though I don't have the means to verify this. I can say that disabling TPM in my BIOS does not solve the issue, but I still see PSP show up as a device even when it is disabled, so it may still be utilizing the same hardware method for random number entropy generation, so it may be I can't test that way either. So I just can't tell if it's unrelated or not.
So I've had a bit of a thought on this. Does this game use any random number generation? Something where entropy could run out? And maybe it resets it or something when you save? I'm given to understand that AMD's implementation of hardware acceleration of random number generation via TPM (or I guess PSP?) is less than ideal currently with things that rely on it slowing considerably once entropy has run out. I'm not sure of the exact specifics of this, but I know there was a significant complaint in the Linux kernel -- though since it's an issue of how the hardware itself works it would apply to Windows too if anything uses it. Supposedly the only complete hardware fix is to use a hardware TPM module (which I currently can't afford -- assuming my motherboard will take one as its documentation doesn't say anything at all about TPM one way or the other and the only slot that looks promising is not labeled.) Supposedly software solutions work much more efficiently in such cases, but these days are good enough for anything but the most extreme security situations anyway. (Eg software entropy generation should be fine for gaming.)
I'm not sure if that is in any way applicable to this or necessarily any other game, but it did make me wonder. I know there were hitching issues in the past directly related to TPM with the Zen 3 architecture, though those were supposed to have been fixed in 2022 via updates that were already integrated into boards before I got my current hardware so I can't help but to wonder if this could still be related. Since I currently can't afford to try an external TPM module to test with though I don't have the means to verify this. I can say that disabling TPM in my BIOS does not solve the issue, but I still see PSP show up as a device even when it is disabled, so it may still be utilizing the same hardware method for random number entropy generation, so it may be I can't test that way either. So I just can't tell if it's unrelated or not.
Looking at this a bit more, I saw a couple of other bugs listed where garbage collection seems to apparently cause freezes for some people. I'm wondering if this could be related -- just less extreme for me (perhaps because each of the components has so much leeway compared to anything this game seems to really truly utilize anyway.) That certainly seems a lot less likely than the TPM thing given that that is supposedly basically fixed (and disabling it seems to do nothing besides.) I noticed in the log that with each save a garbage collection is manually performed and completed. Perhaps this might interrupt some runaway background GC process with a new one that runs and completes quickly? The game is using less than 8GB (of my 32 total) in RAM pretty much all the time, so if there's a way I can test reducing garbage collection or otherwise adjusting it just to see if it affects the issue I'd certainly be willing to try it (though it would likely only be buying time, even that in itself would be an improvement.)
Still, the most obvious thing is when I'm driving around it frequently gets choppy, so I still wonder if it could be physics related. It's just strange if so because it can slow down even when I'm standing around hardly doing anything beyond managing production and a refinery (not much physics involved in operating the menus I would think!) Even so, when I hit save it fixes it for a while, though sometimes only for a few moments before it messes up again.
BTW I moved saves to the same (faster) SSD as the game (symbolic link.) No change. I also tried disabling autosaves (I have a UPS anyway, so don't really need autosaves) to completely eliminate that factor (now it's only saving when I manually save.) So there definitely isn't any extra background writing as far as I know. (Probably no disk writes except the log files?) I didn't see any difference at all there either.
Looking at this a bit more, I saw a couple of other bugs listed where garbage collection seems to apparently cause freezes for some people. I'm wondering if this could be related -- just less extreme for me (perhaps because each of the components has so much leeway compared to anything this game seems to really truly utilize anyway.) That certainly seems a lot less likely than the TPM thing given that that is supposedly basically fixed (and disabling it seems to do nothing besides.) I noticed in the log that with each save a garbage collection is manually performed and completed. Perhaps this might interrupt some runaway background GC process with a new one that runs and completes quickly? The game is using less than 8GB (of my 32 total) in RAM pretty much all the time, so if there's a way I can test reducing garbage collection or otherwise adjusting it just to see if it affects the issue I'd certainly be willing to try it (though it would likely only be buying time, even that in itself would be an improvement.)
Still, the most obvious thing is when I'm driving around it frequently gets choppy, so I still wonder if it could be physics related. It's just strange if so because it can slow down even when I'm standing around hardly doing anything beyond managing production and a refinery (not much physics involved in operating the menus I would think!) Even so, when I hit save it fixes it for a while, though sometimes only for a few moments before it messes up again.
BTW I moved saves to the same (faster) SSD as the game (symbolic link.) No change. I also tried disabling autosaves (I have a UPS anyway, so don't really need autosaves) to completely eliminate that factor (now it's only saving when I manually save.) So there definitely isn't any extra background writing as far as I know. (Probably no disk writes except the log files?) I didn't see any difference at all there either.
Slight addition. No major changes, but I just upgraded to a Radeon 7800XT and in general every single game runs a tad bit smoother somehow (even though the FPS is the same in most.) Space Engineers does maybe seem to also run a bit smoother, but every now and then I still definitely get hitches and slowdowns. It seems to take a lot longer. The 7800XT has 16GB of VRAM versus the previous card, the 3060Ti having 8GB, so I do wonder if among all the other question of possibly garbage collection being related if it could in any way include the GPU. (Specifically, does it use any PhysX or other mechanisms of getting acceleration from the GPU of physics maybe?) I'm not really sure of this though, so all I can say for sure is that it's a lot better but still has the issue all the same.
Slight addition. No major changes, but I just upgraded to a Radeon 7800XT and in general every single game runs a tad bit smoother somehow (even though the FPS is the same in most.) Space Engineers does maybe seem to also run a bit smoother, but every now and then I still definitely get hitches and slowdowns. It seems to take a lot longer. The 7800XT has 16GB of VRAM versus the previous card, the 3060Ti having 8GB, so I do wonder if among all the other question of possibly garbage collection being related if it could in any way include the GPU. (Specifically, does it use any PhysX or other mechanisms of getting acceleration from the GPU of physics maybe?) I'm not really sure of this though, so all I can say for sure is that it's a lot better but still has the issue all the same.
Replies have been locked on this page!