Patch 7 stutters and 0 FPS

U7 is a mess. For now I am willing to believe Arf that the 'core code team' has been working on significant improvements which will start coming with U8, and for now my EDO recommendation is 'not yet'. If u8 does not bring serious improvements it's going to be a simple 'no' and negative review on Steam.
then you're the type of person who performers love to have cos they can go "look over there!" and you do, so they can switcheroo stuff...and then you will adamantly deny that anything untoward has happened and it was real magic.

if patch 8 fixes everything that arf has alluded to without breaking other things, I will bare my rosy bottom in the window of marks and sparks!
 
Last edited:
then you're the type of person who performers love to have cos they can go "look over there!" and you do, so they can switcheroo stuff...and then you will adamantly deny that anything untoward has happened and it was real magic.
You seem to be the type that struggles with basic reading comprehension. I never indicated the odds of anything happen.

He indicated u7 would have minimal performance improvements, and u8 significant improvements. I am willing to see if that is true or not. That's all.
 
You seem to be the type that struggles with basic reading comprehension. I never indicated the odds of anything happen.

He indicated u7 would have minimal performance improvements, and u8 significant improvements. I am willing to see if that is true or not. That's all.
I was talking about patch 8, not 7..no reading difficulties here.. said the bonobo to the gorilla.
 
Nothing to do with CPU load - see my screenie above - CPU at 20% yet it's still dropping frames....
We see only total CPU load on your screen. We don't see how it is splitted between cores. One or two cores may be bottlenecked which would still lead to a freeze. Also, when the freeze in a effect, monitoring stops or lags as well, and all we see is outdated info.
However! After more testing I can agree that the picture is not so simple as I thought.
Anyway, after a 7.01, CZs are somehow more stable for me. They freeze only once upon entering now. But sometimes the freeze ends in a CTD or Mauve Adder lol. If I come successfully through it, the game continues as before. FPS is the same as in Update 6 there (about 20 fps on a GT 1050 and with low settings).
 
We see only total CPU load on your screen. We don't see how it is splitted between cores. One or two cores may be bottlenecked which would still lead to a freeze. Also, when the freeze in a effect, monitoring stops or lags as well, and all we see is outdated info.
However! After more testing I can agree that the picture is not so simple as I thought.
Anyway, after a 7.01, CZs are somehow more stable for me. They freeze only once upon entering now. But sometimes the freeze ends in a CTD or Mauve Adder lol. If I come successfully through it, the game continues as before. FPS is the same as in Update 6 there (about 20 fps on a GT 1050 and with low settings).
Fair enough, good explanation - makes sense!
So, in effect, unless the game knows how to use them, more cores doesn't really make any difference? (4 cores at 5ghz would be better than 8 cores at 3ghz?)

Update 6 I was getting a CTD almost every time I left a Planet (certain Planets in certain Systems, it seems). After 7/7.01, it slows down more, but seems to be better at recovering from it (fewer CTD's).

Anyway, thanks for the explanation (y)
 
Not sure what the issues are, but performance is also much worse with update 7 for me. Lots of stutters and low FPS around settlements now (5800x/3090). Was actually really enjoying it before, but now I'm not sure I can play the Odyssey content.
 
Well I thought I had a big problem, deep large stutter every minute.
I have managed to find the cause.

I thought it was elite, I really did. But then I noticed my device manager devices would refresh.

Yeah, each refresh coincided with a freeze deeper stutter in game.

I managed to work out, it was my HP printer drivers. While printer is on, every so often it would refresh device list. Extra devices appear when printer on..... turn printer off they disappear

Device manager not refreshing stays still. Therefore no deep stutter.

In fact turning some window cpu stuff off, and tweaking the appconfig.xml file means odyssey is running sweet at 4k.

In space butter smooth
In stations complex smooth, using fsr 1.0 gpu uses all of power
On planets 60fsp smooth
On planet settlements, nearly perfect using all of gpu after appconfig.xml tweak.

60fps 4k,

I increased the number of threads, queue size and amount per stack for both work and rendering
 
Dude, you are making all us primates look bad. You managed to misread both posts.

It's okay, not going to go explain it further.

See, that's the good thing of being an ostrich. I just went and put my head under the sand a good 20k ly away from any settlement and their 1 fps dips. Life is good* , frames are aplenty** , I have nice screenshots***.

* actually not, if only real life was half as working as Odyssey

** actually not, add two tussocks and here comes the slideshow

*** actually yes, not at every corner, but plenty of good corners
 
I will show my changes only 5 numbers changed, it made my gpu use all of the power.
Using defaults, gpu was using 50 percent while fps was about 25 to 30

Changes made it use more

Problem using half of gpu only happened when using fsr. Normal mode used all of gpu fine, but fsr seemed to not use it all.
 
Seems a bit odd that every time it polls for data, the CPU is at 15-30%, yet when it's not polling for usage data, usage is topping out...

We see only total CPU load on your screen. We don't see how it is splitted between cores. One or two cores may be bottlenecked which would still lead to a freeze.

Generally speaking, resource polling isn't an instantaneous snapshot, it's an average. You poll once per second (1000ms) and you get a count of how many cycles were non-idle in that that polling period. If a thread was stalled for 500ms before it finished it's task and could submit a frame, then idle for the other 500ms, you'll see 50% utilization on that logical core, if the load was scheduled to that core the whole time. If the app or OS scheduler moved the load to another logical core, you could see even lower per-core utilization over the same polling period, despite being completely CPU limited.

Most tools that report CPU load poll once per second, this is useless for identifying the sort of herky-jerky transient loads that EDO is producing. Some easy to use tools can go down to 100ms, but since a single frame at 60fps is only 16.67ms in duration, you can still have a very poor and largely CPU limited experience that won't be particularly clear in most reporting software, even polling ten times per second.

Fancier stuff like Xperf (which has more direct access to Windows' event tracers) can do 1ms or better polling intervals, with minimal overhead. Looking at 1ms polling periods will show a significant CPU limitation essentially any and every time reported GPU usage falls below the upper 90s of percent. Sometimes this is an I/O or asset management thing (loading pauses), but most of it seems to be part of the renderer itself...the GPU burns through the render queue faster than the CPU can fill it and then goes idle while waiting for the CPU to finish whatever it needs to do to kick frames out to the GPU. The lower the GPU usage, the more often this happens, but it's happening if you aren't pegged very near 100% GPU load over any given polling interval.
 
Last edited:
RenderThreadStackSize="2097152"
WorkerThreadStackSize="2097152"
NumWorkerThreads="18"
RenderJobQueueSize="20480"
KernelJobQueueSize="20480"
MinSpareCores="0"
OptimiseForPerformance="0"
UseThreadPriorities="0"
PerformanceScaling="0"


Thats what I'm using, I even had 4194304 and 32 threads at one point.
29097152 seems enough

I can also OC my 14 cores to 4.6hgz as well.
Without OC it still uses all of gpu for me
 
I rejigged the graphics setup, and found patch 7 to come with a slight frame rate drop on planetary surfaces, and more texture popping.

:D S
 
I rejigged the graphics setup, and found patch 7 to come with a slight frame rate drop on planetary surfaces, and more texture popping.

:D S
I agree, I was pegged at 99% GPU on the surface. It relaxed a bit when I went in to buildings, running around 60-70 fps in the station.. On the transition to the surface after coming out of glide the fps takes a poop, then evens out. There are good days and bad days, in my experience. Today seems to be ok..
 
RenderThreadStackSize="2097152"
WorkerThreadStackSize="2097152"
NumWorkerThreads="18"
RenderJobQueueSize="20480"
KernelJobQueueSize="20480"
MinSpareCores="0"
OptimiseForPerformance="0"
UseThreadPriorities="0"
PerformanceScaling="0"


Thats what I'm using, I even had 4194304 and 32 threads at one point.
29097152 seems enough

I can also OC my 14 cores to 4.6hgz as well.
Without OC it still uses all of gpu for me

I've tried between as few as four workers, with half of stock stack and queue sizes, and as much as quadruple stock settings, with negligible effects, in Odyssey. If anything, it's less meaningful than it is in Horizons. Only increasing MinSpareCores to keep the game from scheduling to the same physical core on SMT systems has been measurable, in my experience. Neither the renderer nor the game's I/O seem particularly well threaded, so spawning tons of extra workers doesn't seem to do much anywhere I've tested.

At 4k, almost setup will be completely GPU limited and higher-end CPUs won't be CPU limited at a fixed 60 fps much of anywhere at any resolution, except for the occasional loading pause.
 
Back
Top Bottom