Stutter after upgrade to NV 970 from AMD HD 5830, even on low settings at 200FPS+
- Thread starter Maiakaat
- Start date
Posted initially in the wrong forum
I may have found some options that make it playable on my machine
First the known ones
Manage general supercruise stutter
1. vsync on with a FPS limit
System settings of Unknown use
2. PCIe Link state power management off in the OS (not sure if this helps at all but CPU use is so low that power saving automation may be an issue)
3. No power management in drivers (nvidia control panel option)
4. Debug services stopped (for developers)
5. Minimum CPU speed at 100% to stop power management on the CPU
ED Thread adjustment in AppConfig.xml in the ED product subfolder
With regard to the near planet (or line of sight planetary stuttering) it doesn't completely fix the problems, and seems somewhat random and strongly CPU and thread related, but it does make it manageable, especially if your just travelling.
It seems to increase CPU contribution generally which seems enough to stop the worst of it, though there is still some serious issues with how threading performs (and the lack of available CPU resources being used or managed properly) with what seems like CPU thread issues that are severe on certain systems.
The cost seems to be marginally more memory used (100 to 200M) and possible less efficient use of the CPU's (but when its only using 5% and stutters at 8% when loading planets like it does on mine - the extra few percent by default is not an issue)
Most of the threads on default settings spent their time disabled or waiting after doing an application (like 99% of their time) before these settings, and probably still do, stuttering became worse where some threads show waiting "executive" in the trace.
Depending on what exactly the queue does it could technically impede performance in other situations, but low settings on the job sizes specifically seem to see SC pausing on a regular interval, so larger seemed better.
Below a certain size relative to worker threads count the app didn't even successfully boot so they are probably related. The default ration is about 2000 per core, the render and kernel/worker settings seem to need to match
The bottom three settings seemed to consistently screw things up so I turned them all off
Trying to get consistent performing settings was still somewhat difficult, with 8 threads performing well at times.
(this setting below is for a 16 core 32 thread workstation with a lot of ram)
NEW SETTINGS
<Threads
RenderThreadStackSize="33554432"
WorkerThreadStackSize="33554432"
NumWorkerThreads="16"
RenderJobQueueSize="65536"
KernelJobQueueSize="65536"
MinSpareCores="0"
OptimiseForPerformance="0"
UseThreadPriorities="0"
PerformanceScaling="0"
/>
OLD CONFIG FOR RECORDS OF WHAT HAS CHANGED
<Threads
RenderThreadStackSize="1024768"
WorkerThreadStackSize="1024768"
NumWorkerThreads="6"
RenderJobQueueSize="12240"
KernelJobQueueSize="12240"
MinSpareCores="0"
OptimiseForPerformance=?
UseThreadPriorities=?"
PerformanceScaling="1"
/>
INDIVIDUAL SETTINGS CAUSING EXTREME STUTTERING (AMPLIFICATION)
RenderJobQueueSize="<8096"
KernelJobQueueSize="<8096"
OptimiseForPerformance="1"
UseThreadPriorities="1"
PerformanceScaling="1"
Backup your file first
POST EDIT: TURN EFFECTS OFF AS THIS SEEMS TO CAUSE ISSUES WITH BUSY SYSTEMS
I may have found some options that make it playable on my machine
First the known ones
Manage general supercruise stutter
1. vsync on with a FPS limit
System settings of Unknown use
2. PCIe Link state power management off in the OS (not sure if this helps at all but CPU use is so low that power saving automation may be an issue)
3. No power management in drivers (nvidia control panel option)
4. Debug services stopped (for developers)
5. Minimum CPU speed at 100% to stop power management on the CPU
ED Thread adjustment in AppConfig.xml in the ED product subfolder
With regard to the near planet (or line of sight planetary stuttering) it doesn't completely fix the problems, and seems somewhat random and strongly CPU and thread related, but it does make it manageable, especially if your just travelling.
It seems to increase CPU contribution generally which seems enough to stop the worst of it, though there is still some serious issues with how threading performs (and the lack of available CPU resources being used or managed properly) with what seems like CPU thread issues that are severe on certain systems.
The cost seems to be marginally more memory used (100 to 200M) and possible less efficient use of the CPU's (but when its only using 5% and stutters at 8% when loading planets like it does on mine - the extra few percent by default is not an issue)
Most of the threads on default settings spent their time disabled or waiting after doing an application (like 99% of their time) before these settings, and probably still do, stuttering became worse where some threads show waiting "executive" in the trace.
Depending on what exactly the queue does it could technically impede performance in other situations, but low settings on the job sizes specifically seem to see SC pausing on a regular interval, so larger seemed better.
Below a certain size relative to worker threads count the app didn't even successfully boot so they are probably related. The default ration is about 2000 per core, the render and kernel/worker settings seem to need to match
The bottom three settings seemed to consistently screw things up so I turned them all off
Trying to get consistent performing settings was still somewhat difficult, with 8 threads performing well at times.
(this setting below is for a 16 core 32 thread workstation with a lot of ram)
NEW SETTINGS
<Threads
RenderThreadStackSize="33554432"
WorkerThreadStackSize="33554432"
NumWorkerThreads="16"
RenderJobQueueSize="65536"
KernelJobQueueSize="65536"
MinSpareCores="0"
OptimiseForPerformance="0"
UseThreadPriorities="0"
PerformanceScaling="0"
/>
OLD CONFIG FOR RECORDS OF WHAT HAS CHANGED
<Threads
RenderThreadStackSize="1024768"
WorkerThreadStackSize="1024768"
NumWorkerThreads="6"
RenderJobQueueSize="12240"
KernelJobQueueSize="12240"
MinSpareCores="0"
OptimiseForPerformance=?
UseThreadPriorities=?"
PerformanceScaling="1"
/>
INDIVIDUAL SETTINGS CAUSING EXTREME STUTTERING (AMPLIFICATION)
RenderJobQueueSize="<8096"
KernelJobQueueSize="<8096"
OptimiseForPerformance="1"
UseThreadPriorities="1"
PerformanceScaling="1"
Backup your file first
POST EDIT: TURN EFFECTS OFF AS THIS SEEMS TO CAUSE ISSUES WITH BUSY SYSTEMS
Last edited:
The issue is not frame-rate directly on the card it is CPU threading, these are full 1-2 second pauses at times as per the thread, the game is not effectively making use of CPU resources or managing threads, frame-rate dips are a result of these issues in most cases, though the effects shaders have a problem on some hardware. Please read the thread.
- - - - - Additional Content Posted / Auto Merge - - - - -
Please read the thread
UPDATE ON STAGE TWO OF FIX
https://forums.frontier.co.uk/showthread.php?t=18573
If you see massive stuttering as soon as other ships appear NPC or otherwise, and turning off effects stops this, it may be firewall and upnp settings are causing issues - though it makes no sense as there is virtually no network traffic.
After re-adding and enabling the firewall for ED32 - as they had been disabled - possibly by windows, this alone seemed to add about 30% to the overall frame-rate, which means nothing but seems to add a little more stability overall.
Next I found uPNP wasn't working according to the logs - though it never seemed to be an issue.
On this, now ED are saying any instructions with uPNP are out of date on forum posts, everything has always worked, and other uPNP programs work for me,but I've applied the old settings anyway - so I have manually let a port through, even though it has probably made no difference.
The next result is that bar planet stuttering at a much more acceptable rate, I can now use 1200p with high settings on everything but effects which are on low, with 1.5x FXAA, and meet the 60FPS sync most of the time in SC and regular flight - for an experience that is as smooth as the game will run generally, with a dip to about 45-50 fps in stations.
Planets still stutter occasionally, but this is a universal issue according to a forum poll, you can now use supercruise and have basic effects - I expect the effects stutter is one more unique issue on some hardware.
I haven't yet tried these settings in a very busy system, and performance is variable, but it is certainly much better than before.
Anyway I hope I will be able to play ED again now, and maybe these notes could help somebody else until Frontier sort the threading model out and stop the underlying issues which effectively limit available CPU performance to negligible levels.
- - - - - Additional Content Posted / Auto Merge - - - - -
Hyperthreading is there because threads can spend most of their time fetching data, allowing another execution path to perform a hardware thread while waiting, so I'm not willing to turn this off. A well written procedural system could actually take advantage of this.
Second no game should require bios tweaks such as shutting down services on the mainboard. everything that can be switched off is off though, the PCIe power management may have been a big issue triggered because of the CPU threading issue not providing work to the GPU consistently, or using at least one core a closer to maximum speed - keeping the system in a busy state.
https://forums.frontier.co.uk/showthread.php?t=18573
If you see massive stuttering as soon as other ships appear NPC or otherwise, and turning off effects stops this, it may be firewall and upnp settings are causing issues - though it makes no sense as there is virtually no network traffic.
After re-adding and enabling the firewall for ED32 - as they had been disabled - possibly by windows, this alone seemed to add about 30% to the overall frame-rate, which means nothing but seems to add a little more stability overall.
Next I found uPNP wasn't working according to the logs - though it never seemed to be an issue.
On this, now ED are saying any instructions with uPNP are out of date on forum posts, everything has always worked, and other uPNP programs work for me,but I've applied the old settings anyway - so I have manually let a port through, even though it has probably made no difference.
The next result is that bar planet stuttering at a much more acceptable rate, I can now use 1200p with high settings on everything but effects which are on low, with 1.5x FXAA, and meet the 60FPS sync most of the time in SC and regular flight - for an experience that is as smooth as the game will run generally, with a dip to about 45-50 fps in stations.
Planets still stutter occasionally, but this is a universal issue according to a forum poll, you can now use supercruise and have basic effects - I expect the effects stutter is one more unique issue on some hardware.
I haven't yet tried these settings in a very busy system, and performance is variable, but it is certainly much better than before.
Anyway I hope I will be able to play ED again now, and maybe these notes could help somebody else until Frontier sort the threading model out and stop the underlying issues which effectively limit available CPU performance to negligible levels.
- - - - - Additional Content Posted / Auto Merge - - - - -
Hyperthreading is there because threads can spend most of their time fetching data, allowing another execution path to perform a hardware thread while waiting, so I'm not willing to turn this off. A well written procedural system could actually take advantage of this.
Second no game should require bios tweaks such as shutting down services on the mainboard. everything that can be switched off is off though, the PCIe power management may have been a big issue triggered because of the CPU threading issue not providing work to the GPU consistently, or using at least one core a closer to maximum speed - keeping the system in a busy state.
Last edited: