Update on the regular-as-clockwork bad stutter. 1st reported in December after PP2.0, more noticeable since Trailblazers in Feb

Status
Thread Closed: Not open for further replies.
The very repeatable annoying visual stutter issue (which is related to CPU processing spiking, not GPU load - which in fact drops during the stutters) is as described here, just adding my notes here from Reddit...

To re-iterate, the following is NOT an issue with drivers or your GPU, it is not your rig failing and needing an expensive upgrade. It is some element of design failing us.

Monitoring​

The following info with options in main menu > Network settings > Logging ON - this provides detailed logging in the netLog files shown in the game install directory, e.g.

[install directory]\Elite Dangerous\Products\elite-dangerous-odyssey-64\Logs

Behaviour​

Normally what happens is when you start a game session, there are a bunch of things that get read and traffic goes back and forth with the servers as always, i.e. when you first start a session there is a bit of lag and stutters for a minute or so. That's all par for the course sadly. Nothing unusual there (annoying as it is!).

The difference now is that there is a new additional step apparently since Powerplay 2.0 released (this issue was first logged by someone in December) something causes a lot of lag and gets logged (when detailed netlog files is set on) with the prefix "GPSS" -- this is first logged at startup after a minute or so, and then this same process will repeat at VERY regular intervals like clockwork i.e. as much as every 10 minutes apart

NOTE: I suspect, due to timing of when the issue started being reported shortly after PP2.0 launch, that GPSS means something like Global Powerplay System State. Another clue is that one of the messages prefixed with this also refers to "Octree" which is a kind of database structure used to partition a three-dimensional space by recursively subdividing it into eight octants - and anyone who knows how stellar forge works will recognise this.

Sometimes the timings of the minutes of stutter followed by log messages will be at different times for other people, I think it is user session dependant - but it always occurs at one or more of the regular timing intervals after the hour, such as around:

  • 5-6 minutes past the hour (very common)
  • 11-12m (occasional one not following the usual "H:n5m" rule!)
  • 15-16m (common)
  • 21-22m (occasional one not following the usual "H:n5m" rule!)
  • 25-26m (common) and
  • 55-56m (seems to be rarer)
UPDATE: It seems the number of the incidents per hour seems to be dependant on the time of day or how busy the servers are. E.g. peak times in the UK have multiple events per hour, off peak for the UK, i.e. NZ afternoon and evening I am only seeing one or two per hour.

But again, at the worst times, it can now also happen every ten minutes or more.

NOT GOOD ENOUGH DAMMIT, NOT GOOD ENOUGH!

Source: https://www.youtube.com/watch?v=yiWAWdDsnII


This issue is a perfect example of a seemingly minor (to some) and fairly isolated thing, but when taken cumulatively in addition to other QOL issues and bugs like the shadow flicker reintroduced (and previously fixed) over 2 years ago, it becomes a growing detriment to enjoyment, the "death by a thousand papercuts" I often refer to.

This one has had many people worried that their gaming rigs are needing fixing or upgrading, it's that bad. I've been playing for 9 years and this is one of the worst examples of design disrespecting smooth gameplay performance.

Minimizing lag, stutter and smooth framerates and visuals generally (i.e. lighting and shadows and LOD) should be treated as sacrosanct, it is the first, key, selling point of the game - everything else relies upon it.

It affects ability to enjoy playing long periods, the worst instances of this minute+ long stutterfest results in
  • very frustrating combat or other fast-paced activity, which has far less performance even at the best of times, as it is severely affected by this
  • simply flying your ship, for example the thought of buying a new ship with cash, becomes not as fun (not buying the new one until this is fixed)
  • finding yourself put off from playing at all if you know one of those intervals is coming up, I don't want to be in the middle of something hectic or intricate like mining when they occur.
  • streamers videos being marred by these flaws, videos which normally do a great job of showcasing and promoting content and enticing new players, ends up deterring them.
In short, fix this!

I worry that without exhibiting some sense of urgency with fixes and QOL, any goodwill is going to start eroding again.


Issue Tracker Link​

Well voted on and reproduced in over 14 pages since mid December (EDIT: Now over 24 pages, well done! it is now marked as "Acknowledged")

https://issues.frontierstore.net/issue-detail/70049

Log message examples and timings​

Remember that these log messages appear when Network settings > Logging is ON and start to appear about a minute each time AFTER the stuttering has started.

I think there seems to be a lot of inefficient calculations or something going on for about a minute (during which is a lot of stutter) in this example stutter started at about 16m past the hour then this message appears in the logs at 16m48s past the hour...

{19:16:48GMT 1694.512s} GPSS set state foci (49775, 40733, 23902)->(50197, 41169, 24294)
This log message seems to be the final stage of the current process, where some server updating process gets logged by a whole bunch more of these "GPSS" messages get fired into the log, very rapid fire, like this

{19:16:56GMT 1702.856s} GPSS ReadyOctree fallthrough
{19:16:57GMT 1703.130s} GPSS ProcessSystemStates: Processing state change 3->0
{19:16:57GMT 1703.140s} GPSS AddJobs state change 0->6
{19:16:57GMT 1703.150s} GPSS m_systemMapIt != m_systemMap.End() state change 6->5
{19:16:57GMT 1703.160s} GPSS AddJobs state change 5->6
... etc., etc., about 150 or more like these, abridged here for ease of reading.
Then finally at about the same time you get that final massive stutter...


{19:17:03GMT 1709.513s} GPSS has taken 15.00s: 2, 7
Control systems not ready:[]
Home systems not ready:[]
The same process repeats like clockwork. At start up, and then at very regular infuriating intervals, e.g. a minute's worth of stutter, then these log messages start (and another 10 seconds of stutter) at...

Session Day 1. Startup + subsequent stuttersSession Day 2. Startup + subsequent stutters
{18:51:27GMT 173.233s} GPSS set state{18:44:12GMT 174.008s} GPSS set state
{19:16:48GMT 1694.512s} GPSS set state{19:06:51GMT 1532.875s} GPSS set state
{20:06:50GMT 4696.993s} GPSS set state{20:06:59GMT 5140.580s} GPSS set state
{20:16:54GMT 5300.198s} GPSS set state{20:16:50GMT 5732.170s} GPSS set state
{20:26:54GMT 5900.276s} GPSS set state{20:22:09GMT 6050.350s} GPSS set state
{21:11:52GMT 8598.624s} GPSS set state{20:26:56GMT 6338.141s} GPSS set state
{21:16:46GMT 8892.523s} GPSS set state^ I gave up at this point, it was a bad stutter day!
Session Day 3. Startup + subsequent stutters
notice that timings seem to have become less consistent
{18:55:34GMT 175.586s} GPSS set state
{19:18:38GMT 1558.834s} GPSS set state
{19:27:16GMT 2077.199s} GPSS set state
{20:01:56GMT 4157.205s} GPSS set state
{21:06:51GMT 8052.397s} GPSS set state
{21:16:52GMT 8653.182s} GPSS set state
{22:11:50GMT 11951.440s} GPSS set state

Demo of Stutter​

A sprint around my cutter during the 05-07 minute mark past the hour... watch for the 10-20 FPS dips in the bottom left and stutter during the 1+ minute run. I chose this activity as exhaustion no longer applies in hangars, is reasonably fast paced showing the stutter well while being easily reproduced. Note that in more frantic or intricate situations, e.g. mining, or in settlement or multi ship combat the effect is magnified further.

High res/framerate version here
Source: https://www.youtube.com/watch?v=pwz3kNrfn_U

You will notice scopes attached to my shoulders, a bug I logged too! lol

Systems Specs​

A mid-range rig circa 2020/21. I normally get a very steady 75fps (locked to widescreen monitor max refresh rate) as shown in the video, with maxed graphics settings, no upscaling. Only Frontline "high" conflicts can sometimes drop to 65 fps - if you have specs less that this I suspect your stutter during these times will be even worse, and vomit inducing in VR:

  • CPU: AMD Ryzen 7 5800 X3D (NB. this 2022 upgrade was a huge fps stability improvement) on a midrange X570 mobo
  • RAM: 32.0 GB @ 3600
  • GPU: AMD Radeon RX 6800 (not XT) with 16GB VRAM - latest drivers are good
  • STORAGE: Corsair Force MP600 Gen4 NVMe M.2 SSD
  • DISPLAY: Low cost freesync 75hz monitor @ 2560 x 1080, with Tobii5 head/eye tracking. No VR.
 
Last edited:
I get the same graphics performance on minimum graphics as on maximum graphics. Plus activating subsampljng what what doesn't help either.

The flickering and stutters returning makes me wonder if the issue is mayhapse... the data and components of trailblazers and so on were being worked on in a DIFFERENT folder in fdev's programming section. And the fix for shadows was put in a different version.

I also noticed over the many years I played this game the game gets worse every time you update, to the point I now uninstall and do a fresh install when a major patch happens. Still doesn't help some issues... and the big issue seem to be always returning with a big update.
Making one again wonder "did they forget to copy the right batch file?"
 
Also getting lots of stutter and lag is horrible when entering and exiting supercruise. Not sure if it might be worse due to the fact I'm in a system with a trailblazer megaship.
 
It seems to be happening more often and feels worse of late. It's becoming a VERY large problem to me as I'm on foot often and it becomes impossible to correctly aim and interact when it starts.
 
A single observation that is probably NOT a surprise to anyone:
After having been in a power conflict zone for a few hours a day for the last three days; the stutters still happen at semi regular intervals but grow FAR more frequent and worse when another Cmdr is in instance with me for a length of time.
 
These stutters are horrid. They get worse as the day progresses and make combat a horrible experience. They were bad enough when PP 2.0 dropped, but got much worse after Trailblazers released. How Fdev managed to kill the CPU render pipeline with some simple network traffic from servers to the client beggars belief. I do love Elite but this bug is killing the immersion.
 
Maybe - what I don't understand though is why anything network related like that needs to screw up rendering frames and listening to control inputs. I thought multithreading was a thing in 2025. My CPU probably has more physical cores than the number of threads this game can use.
Yeah, the fact that server updates are blocking rendering means either the network code has been intertwined a long time and it was so light that nobody really felt it till now or that some poor soul ended up tying it into there with PP2 / TB. Better hope it's the latter. The former will be really bad news.
 
It has now been acknowledged

That's great news!

what I don't understand though is why anything network related like that needs to screw up rendering frames and listening to control inputs. I thought multithreading was a thing in 2025

There's probably double figures or more of scenarios that could be behind this issue; only those with access to the code could really determine what the actual cause is. My current best guess is that some work initiated over the network is tying up the CPU in the thread that calculates the position and orientation of the POV camera, so the frames might take a dip but the viewport gets stuck much harder than the reduced framerate would imply. When it happens to me my frames go from 60 to 30s, but the screen appears to get locked for 1/3 of a second or more at worst. It is very much a guess though.

Regards 2025 I think ED was architected when multicore wasn't such a thing. From what I understand it runs essentially 2 threads, no more. Just having the GPSS tasks yielding more instead of striving to complete themselves in such a hurry might be an easier fix than adding more threads, but since we don't really know what they're doing.. ... ... 🤷‍♂️
 
Depending on what you mean by "essentially", and "no more", no, in my experience, the game will use all cores, though yes two are higher than the others. This is me doing bounty hunting last Saturday. No cores are near 0 while I'm fighting. 7800X3D+9070XT.

1744831665925.png
 
Yes this is happening, have been observing it myself.
Another factor adding to this (but separate) is Nvidia's current glitchy driver situation regarding they're latest drivers. So I'm using driver version 366.66. For best stability, see vid below, it may help someone.




Flimley
I have an nVidia card myself. It might be that newer drivers may have an effect, but I am using older drivers with which I NEVER had this problem -- until the latest updates.

I am not ruling out that glitchy drivers might have a deleterious effect (I've always wanted to use "deleterious" ;) ), but the update itself seems to have borked something.

I just hope they fix it -- it is REALLY annoying when trying to clean up pirates nice and easy...
 
the viewport gets stuck much harder than the reduced framerate would imply. When it happens to me my frames go from 60 to 30s, but the screen appears to get locked for 1/3 of a second or more at worst.
I think that's just a consequence of how fps figures are calculated. For example, when I'm playing on 120 fps, then even if the game freezes for half a second, that's still 60 frames rendered during that second. If the displayed fps value gets averaged (for example) every 2 seconds, that will give 120 + 60 = 180 frames during a 2 second long interval, so the game will temporarily display a dip to 90 from 120 fps despite having been displaying literally no frames for 500 milliseconds.

Regards 2025 I think ED was architected when multicore wasn't such a thing. From what I understand it runs essentially 2 threads, no more.
I'm pretty sure I was using a 4 cores / 8 threads CPU in 2015 which absolutely wasn't a high-end one at the time. But even if you are designing a 2-thread game, you will definitely never want your rendering thread to wait for any kind of a network-related operation that can occasionally take upwards of a second (unless it was a slideshow application you were working on).
 
in my experience, the game will use all cores

I spent a little time looking at this using htop, which allows to determine exactly what processes are pegging which cores. Unless things have changed (since a few months back) there's two significantly busy cores running ED and a bunch of minor transient use of other cores by ED at any snapshot I've taken. Of course there's a whole bunch of other kernel/network, Steam/proton, browser, terminal, etc. processes running and it's hard to be definitive.
 
Status
Thread Closed: Not open for further replies.
Back
Top Bottom