Observation: DCS MT is less CPU intensive after a forced restart

[cow_art]

TLDR: After launching DCS MT  (in VR) my CPU load is high in the menus and in the game. Any graphics settings change that triggers  an enforced DCS restart fixes this. I usually just toggle the full screen checkbox on or off (it does not matter in which direction - the only thing that matters is that it is a change that makes DCS restart)

The same observation has already been documented here by @durp

but the reporter there could not find anything different in their logs. I can find something different in my logs, so here it goes:

First Run (bad)

I start DCS MT via Steam. DCS loads into the main menu and then I load an Mi8 InstantAction mission and fly around a bit. My CPU load is ridiculously high:

The DCS log shows this during startup:

 

Quote

2023-12-01 17:22:23.637 INFO    EDCORE (Main): common cores: {4, 5, 6, 7, 12, 13, 14, 15}
2023-12-01 17:22:23.637 INFO    EDCORE (Main): render cores: {8, 9, 10, 11, 0, 1, 2, 3}
2023-12-01 17:22:23.637 INFO    EDCORE (Main): IO cores: {16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31}

 

 

I go back to the main menu. I go into graphics settings.  I toggle the Fullscreen checkbox (as mentioned above, it does not matter what setting I toggle and which value it is set to. The only thing that matters is that it triggers a DCS restart).

Second Run (after restart, good)

DCS restarts. I load the same mission again and again fly around for a bit. My CPU load is significantly lower now:

 

The DCS log now looks like this:

 

Quote

2023-12-01 17:30:05.606 INFO    EDCORE (Main): common cores: {4, 5, 6, 7, 12, 13, 14, 15}
2023-12-01 17:30:05.606 INFO    EDCORE (Main): render cores: {8, 9, 10, 11, 0, 1, 2, 3}
2023-12-01 17:30:05.606 INFO    EDCORE (Main): IO cores: {}

 

See the difference? After the restart DCS assigns no IO cores. During the first start it assigned ALL my E-Cores as IO cores. 

 

I'm not sure if this is the root of the problem, but I can consistently reproduce that behaviour.

My current workaround is this: Every time I start DCS I go into settings and toggle the full-screen checkbox. Afterwards my game runs much smoother.

 

Details about my system:

• Intel i9-14900K
• NVIDIA 4090
• Windows 11 (fresh install, about a week old)
• DCS  (Steam Version, fresh install, no mods but I installed the mt.lua from https://forum.dcs.world/topic/337829-intel-hybrid-cpu-getting-stutter-please-try-this-in-multithreading-dcs/ )
• Varjo Aero (varjo-foveated installed)

 

DCS Logs attached.  If I can provide any additional information or run some tests, feel free to ask!

 

badrun_dcs.log goodrun_dcs.log

Edited December 2, 2023 by cow_art
typos

[jeventy26]

THIS!!! I always restart DCS and my CPU usage goes WAY down on second time.  ED really needs to look at this.  I never went all scientific (glad you did) and I just restarted but its nice to see this is an issue with others.

[Hammer3246]

I checked and have the same issue, makes a big difference in game play.

I'm running pretty much the same system as you cow_art

Edited December 2, 2023 by Hammer3246

[durp]

I am on AMD, the IO cores are the same between the runs for me, the standard deviation on pause10 is higher.

good run:

INFO    EDCORE (Main): common cores: {40, 41, 42, 43, 44, 45, 46, 47, 16, 17, 18, 19, 20, 21, 22, 23, 48, 49, 50, 51, 52, 53, 54, 55}
INFO    EDCORE (Main): render cores: {32, 33, 34, 35, 36, 37, 38, 39, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15}
INFO    EDCORE (Main): IO cores: {24, 25, 26, 27, 28, 29, 30, 31, 56, 57, 58, 59, 60, 61, 62, 63}
INFO    EDCORE (Main): pause10: 0.016777 us (std dev: 0.005829)
INFO    EDCORE (Main): pause10: 583 cycles (std dev: 429.7)

bad run:

INFO    EDCORE (Main): common cores: {40, 41, 42, 43, 44, 45, 46, 47, 16, 17, 18, 19, 20, 21, 22, 23, 48, 49, 50, 51, 52, 53, 54, 55}
INFO    EDCORE (Main): render cores: {32, 33, 34, 35, 36, 37, 38, 39, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15}
INFO    EDCORE (Main): IO cores: {24, 25, 26, 27, 28, 29, 30, 31, 56, 57, 58, 59, 60, 61, 62, 63}
INFO    EDCORE (Main): pause10: 0.016800 us (std dev: 0.014967)
INFO    EDCORE (Main): pause10: 583 cycles (std dev: 410.2)

--------------------------------------------------------------------------

Did compare if there are different DLLs loaded between the sessions (goodrun vs badrun)

badrun loads following DLL extra:

0x00000000e0370000  0x98000   C:\Windows\SYSTEM32\webio.dll

goodrun does not load webio.dll but loads following ones (not present in the badrun):

0x00000000ec330000  0x11000   C:\Windows\system32\wbem\wbemprox.dll
0x00000000ec2a0000  0x90000   C:\Windows\SYSTEM32\wbemcomn.dll
0x00000000e7c90000  0x14000   C:\Windows\system32\wbem\wbemsvc.dll
0x00000000e7ce0000  0x10b000  C:\Windows\system32\wbem\fastprox.dll

(don't mind the different memory addresses)
The filelocations seem to be consistent, was hoping to find a DLL file being loaded from... wherever, like an old openxr runtime. 
 

badrun means, starting DCS regularly, from steam (or via shortcut, same thing), CPU frametimes in the mainmenu are ~9.8-10.6ms, in-game not playable

goodrun means, after starting DCS and change ANY setting that requires a forced DCS restart, after that frametimes on the mainmenu are 1.6-1.8ms and in-game is acceptable performance

..and as for now... this is always the case that the regular DCS launch results in bad performance, and after changing ANY setting that requires a DCS restart, the performance goes back to acceptable levels. Closing DCS and reopening it (via Steam) results in a unplayable badrun again.

 

 

Edited December 2, 2023 by durp

[Rapierarch]

On 12/2/2023 at 10:21 AM, durp said:

I am on AMD, the IO cores are the same between the runs for me, the standard deviation on pause10 is higher.

good run:

INFO    EDCORE (Main): common cores: {40, 41, 42, 43, 44, 45, 46, 47, 16, 17, 18, 19, 20, 21, 22, 23, 48, 49, 50, 51, 52, 53, 54, 55}
INFO    EDCORE (Main): render cores: {32, 33, 34, 35, 36, 37, 38, 39, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15}
INFO    EDCORE (Main): IO cores: {24, 25, 26, 27, 28, 29, 30, 31, 56, 57, 58, 59, 60, 61, 62, 63}
INFO    EDCORE (Main): pause10: 0.016777 us (std dev: 0.005829)
INFO    EDCORE (Main): pause10: 583 cycles (std dev: 429.7)

bad run:

INFO    EDCORE (Main): common cores: {40, 41, 42, 43, 44, 45, 46, 47, 16, 17, 18, 19, 20, 21, 22, 23, 48, 49, 50, 51, 52, 53, 54, 55}
INFO    EDCORE (Main): render cores: {32, 33, 34, 35, 36, 37, 38, 39, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15}
INFO    EDCORE (Main): IO cores: {24, 25, 26, 27, 28, 29, 30, 31, 56, 57, 58, 59, 60, 61, 62, 63}
INFO    EDCORE (Main): pause10: 0.016800 us (std dev: 0.014967)
INFO    EDCORE (Main): pause10: 583 cycles (std dev: 410.2)

--------------------------------------------------------------------------

Did compare if there are different DLLs loaded between the sessions (goodrun vs badrun)

badrun loads following DLL extra:

0x00000000e0370000  0x98000   C:\Windows\SYSTEM32\webio.dll

goodrun does not load webio.dll but loads following ones (not present in the badrun):

0x00000000ec330000  0x11000   C:\Windows\system32\wbem\wbemprox.dll
0x00000000ec2a0000  0x90000   C:\Windows\SYSTEM32\wbemcomn.dll
0x00000000e7c90000  0x14000   C:\Windows\system32\wbem\wbemsvc.dll
0x00000000e7ce0000  0x10b000  C:\Windows\system32\wbem\fastprox.dll

(don't mind the different memory addresses)
The filelocations seem to be consistent, was hoping to find a DLL file being loaded from... wherever, like an old openxr runtime. 
 

badrun means, starting DCS regularly, from steam (or via shortcut, same thing), CPU frametimes in the mainmenu are ~9.8-10.6ms, in-game not playable

goodrun means, after starting DCS and change ANY setting that requires a forced DCS restart, after that frametimes on the mainmenu are 1.6-1.8ms and in-game is acceptable performance

..and as for now... this is always the case that the regular DCS launch results in bad performance, and after changing ANY setting that requires a DCS restart, the performance goes back to acceptable levels. Closing DCS and reopening it (via Steam) results in a unplayable badrun again.

 

 

 

My god it affects all the way to the threadripper. I wonder what DCS skips causing it to run better in forced restart.

I didn't try it myself but was thinking that might be an intel thing. But if it runs same on the dripper we may call this proven to be replicable at all systems.  

 

Edit: It has no impact on my system. I have a modded graphics lua for example precaching is disabled mainly. Tried it various times. No impact at all. 

3950x 96GB 3200Mhz 4090 Quest2 72hz 4800x4800 per eye via quest rift link. 

Edited December 3, 2023 by Rapierarch
Additional info: see edit after testing

[jackd]

I am still a little confused ... should one use MT when you always play as single? 

[cow_art]

1 hour ago, jackd said:

I am still a little confused ... should one use MT when you always play as single? 

I think you are mixing up two very different things.

MP = Multiplayer means playing with other (human) players over the internet.

MT = Multithreading means DCS is using more of your CPU cores to calculate stuff.  Modern CPUs usually have a lot of cores and unless you run the MT version of DCS, most of these CPU resources are unused. In theory using MT should thus give better game performance (more FPS, smoother gameplay) and it allows you to use some cool new graphics features such as DLSS and DLAA. In practice, the DCS MT implementation still has some problems. The thing we are talking about in this thread is one such problem.

Edited December 4, 2023 by cow_art

[jackd]

Was MT, and i tried it once to get DLSS etc working, but did not notice any better performance with my 3080ti RTX ..

[durp]

Before the update today hits the shelves.. a small update.

There was a Steam (VR?) update 3 days ago, and it seems the 10x performance drop on initial launch is no longer the case. 
Menu launches into a 1.6ish ms frametime now without the need to force a DCS restart and in-game performance is okayish (neglecting the other issues with 2.9)

It was also the only update (steamvr) that did change (15th Dec), nothing else. 
(can't exclude quiet updates as with the F15E model 'fix' on accidental release)

So far the last few DCS starts went alright, can't say much about it, it is literally just 3 launches of DCS so far. 

Just wanted to toss that in before the update comes out.

 

 

 

Edited December 18, 2023 by durp

[Brainfreeze]

I have the same system as you @cow_art and exactly the same issue and same fix (I toggle visib range on my side ).  
Only difference is I use DCS Standalone, not Steam.

 

[cow_art]

21 hours ago, Brainfreeze said:

I have the same system as you @cow_art and exactly the same issue and same fix (I toggle visib range on my side ).  
Only difference is I use DCS Standalone, not Steam.

 

Thanks for the feedback! That's very valuable information! So far I suspected this could somehow be related to the Steam Version of DCS, but it seems that's not it. Must be something else (because it's obviously not happening for everyone).

@BIGNEWY What additional info can we provide to help you track this down? Thanks!

 

Edited February 12 by cow_art

[Brainfreeze]

I have experimented with process lasso and found something that seems to work.  Went to I/O priorities and matched DCS with low priority.  Seems to force DCS to not assign I/O E-cores. Relaunched DCS after a reboot a couple times and I have not experienced the spikes and the log show no I/O cores assigned.   Not sure if this is affecting anything else though as I do not really know what I'm doing here    Anyway, worth a try!

[cow_art]

13 hours ago, Brainfreeze said:

I have experimented with process lasso and found something that seems to work.  Went to I/O priorities and matched DCS with low priority.  Seems to force DCS to not assign I/O E-cores. Relaunched DCS after a reboot a couple times and I have not experienced the spikes and the log show no I/O cores assigned.   Not sure if this is affecting anything else though as I do not really know what I'm doing here    Anyway, worth a try!

Interesting, thanks!  After I read your post I also tried some things with process lasso.  My findings so far:

Unfortunately I can't reproduce the exact fix you describe. Changing the I/O Priority has no effect on the used E-cores on my system.

But I can use process lasso to just forbid DCS to use any E-Cores (set dcs.exe CPU affinity to P-Cores only). And this has the desired effect for me: DCS assigns all  P-Cores to common/rendering and does not assign any IO cores.  And then the game runs much better right from the start (without forcing a restart via a settings change).

This leads me to think this problem really has to do with DCS using all the E-Cores for I/O. At least on my system (Intel 14900k) that just drives up the CPU load without any benefit for FPS or perceived smoothness.

Edited February 13 by cow_art

[Brainfreeze]

45 minutes ago, cow_art said:

Interesting, thanks!  After I read your post I also tried some things with process lasso.  My findings so far:

Unfortunately I can't reproduce the exact fix you describe. Changing the I/O Priority has no effect on the used E-cores on my system.

But I can use process lasso to just forbid DCS to use any E-Cores (set dcs.exe CPU affinity to P-Cores only). And this has the desired effect for me: DCS assigns all  P-Cores to common/rendering and does not assign any IO cores.  And then the game runs much better right from the start (without forcing a restart via a settings change).

This leads me to think this problem really has to do with DCS using all the E-Cores for I/O. At least on my system (Intel 14900k) that just drives up the CPU load without any benefit for FPS or perceived smoothness.

 

I'll check that... think i also did restrict DCS affinity to P cores as well so that may be the fix rather than the I/O priority 

 

[LOW_Hitman]

I agree! Today i played in VR - not playable with F14 single Mission (southern watch 1998) 5-10 fps, stutters. After a game restart - bang - no stutters 60-70 fps!! Please ED fix this. Also the issue that we all have to restart f14 missions to make the VDI work.