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.

Nowski

Nowski
galahad2069 said:
If the displayed fps value gets averaged (for example) every 2 seconds,
Click to expand...
I don't think it does though. If I have "normal" stutter induced by the presence of Osseus & their rocks, when I leave graphics settings cranked up, the dip is visible nigh-on instantly.
 

galahad2069

G
Nowski said:
I don't think it does though. If I have "normal" stutter induced by the presence of Osseus & their rocks, when I leave graphics settings cranked up, the dip is visible nigh-on instantly.
Click to expand...
I did not mean it was only computed once every 2 seconds. It can be computed once every 10 ms (hence responding very quickly) but computing the fps figure from the number of frames rendered during the last 2 seconds (thus never displaying a dip to 0 fps as long as the freeze is less than 2 seconds long).

(Obviously these are just made up numbers as an example.)
 

Flimley

Flimley
[VR] DDM_Reaper20 said:
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...
Click to expand...
It is most definitely the update! And the update alone. I did roll back my drivers though as the 572.xx were less than stellar.

Flimley
 

Nowski

Nowski
galahad2069 said:
I did not mean it was only computed once every 2 seconds
Click to expand...

Right, but then I'd expect to see a gradual drop over a 2 second period (in the Osseus case I mean) whereas my impression is it drops instantly.

Admittedly things are complicated by the fact that the frame number updates only when there's a new frame :)

I just looked again at my video of the problem (posted in the other thread) which is at 30 fps. At around 0:24 there's a 20 frame pause and the framerate drops from (capped) 60 to 36, so your 2 second average could be on the money if that's how it does work,
 

the100thmonkey

the100thmonkey
Nowski said:
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.
Click to expand...
This is what I noticed when inspecting the Afterburner logs from a session earlier. What's interesting in the logs is that before the stutter, when the game is performing normally, I notice the game using two hardware threads and the two logical threads associated with them. The active cores and threads seem to swap every 5 seconds or so. When the stutter starts, this pattern seems to break down. I set the Afterburner update frequency to 100ms rather than 1000.

1744837405310.png
 

GraphicEqualizer

GraphicEqualizer
the100thmonkey said:
This is what I noticed when inspecting the Afterburner logs from a session earlier. What's interesting in the logs is that before the stutter, when the game is performing normally, I notice the game using two hardware threads and the two logical threads associated with them. The active cores and threads seem to swap every 5 seconds or so. When the stutter starts, this pattern seems to break down. I set the Afterburner update frequency to 100ms rather than 1000.
Click to expand...
and during this period of CPU spikiness the GPU load drops because it aint getting enough work to do.
 

Neilski

Neilski
The cores/threads thing for games regularly causes confusion. Part of this is because threads can and do hop from core to core unless you lock them down with the affinity (aka "pinning") settings. So a system with a single maxed-out thread might look like it had one busy core and the rest sitting idle, or more likely would look like all cores were only slightly busy. This is still useful information but it's not possible to infer how many threads are truly working from just that info.

I generally use Process Explorer (now kinda ancient, and I think better options exist but I'm lazy) from Sysinternals (aka MS, nowadays) to check out the threads within any given process. The screenshow below shows what I was experiencing on my 7700K last night while tinkering with the graphics quality settings. NB: on this 4-core/8-thread CPU, a maxed-out thread shows up as 12.5% of CPU time.
2 threads are working hard at around 10% (i.e. uncomfortably close to maxed out) and another 8 are working at 2 - 4% (4% means a thread is consuming almost a third of a single execution unit). This was in Open, which my CPU struggles with (at least in busy instances), but I don't have a similar example from Solo to hand right now.

1744838565790.png
 

Thauma

Thauma
If this is helpful, I observed the stuttering myself with the whole colonization. What I noticed is when I use geforce now for either remote play or for my alt, the stuttering is missing, just some abnormal moments here and there. I chose the servers to be eu northwest, which should be as close as possible to the servers of the game. As for my normal playing, on my pc, the stuttering is present in most of the present reported times, with the 05 being the most consistent one. What I noticed with this one is, when I hold the button for selecting how much cargo I want to buy/sell, while its happening, if I let go the button, the amount will keep moving, despite me no longer pressing. And the amount will change in the same manner, in portions, the way the stuttering happens, as if there is gigantic lag.
 

gbjbaanb

gbjbaanb
There is gigantic lag that affects the UI - I had the stutter whilst FSS scannoing a system. The tuning slider simply stopped working, jumping huge steps instead of smoothly scrolling up and down the line.
 

Nowski

Nowski
Thauma said:
if I let go the button, the amount will keep moving, despite me no longer pressing.
Click to expand...

gbjbaanb said:
The tuning slider simply stopped working, jumping huge steps instead of smoothly scrolling
Click to expand...

Yeah, for the stutter in question the UI stops updating and the game can stop handling input like keypresses. If you get in the habit of checking the game time when you experience it, you can verify this is the same "x5 minutes and some seconds past the hour" stutter being discussed.
 

JR250

J
I love this game and consider myself an FDev supporter. But there's no way an issue like this, reaching top of "stability" ranks in Issue Tracker, needs to be detailed by users to this level before FDev even marks it "acknowledged". It affects all of us. It is detailed to excruciating levels by hundreds of players. A start of event date is given. Videos evidence of it recorded. Statistics showing the issue posted.

What else does the community need to do before a CM/Dev pops in and let us know they're working on it and will be fixed by x date? Can't really enjoy the snazzy new ships and upcoming features when the game is so chock full of bugs. Please, we need one or two stability releases asap, prioritized over adding content.

/Rant off.
 
Status
Thread Closed: Not open for further replies.
Back
Top Bottom