Frame Drops because of Smoke

[RoboHackfeld]

Dear Pilots,

 

now I got a 5080 and I am pretty happy with this card until it comes to burning units or smoke in general.

For benchmarkI use the A10 CII Mission (Armored Convoy).

It runs all the way smooth until a couple of Units (4 or more) begin to burn and the smoke kicks in. Than if I look into the direction of that units my framerate drops constantly from 72 to 68 to 62 to 58 to 55 up again to 72 to 67 to 60 to 56 to 72 and so on.

My Frametime jumps constantly into the other direction from like 8 to 10 to 12 to 15 to 18 to 8 to 11 to 13 to 16  and so on. 

 

 

I think that is because of my CPU is limiting but is there any possibility to make smoke hit less performance?

I tried every setting, I even lowered every setting to the absolut minimum and nothing helped.

 

My Latency in VD is always between 40 and 60 and Networking around 8 - 12 ms but the same happens if I use the link cable and Meta-Link

 

In my video if you look at the FPS Counter in the Top. Sorry for the bad quality. 

System:

Quest 2 with Virtual Desktop (5G) (Ultra) H.264+ VDXR 400bit (Same  Problem with Quest Link)

7 5800x3D

NVidia 5080

64 GB (4*16GB) 3200MHz

M2 SSD

 

Swapped the DLSS File to DLSS 4, Preset K via NVPI

 

Below are my DCS Settings

 

 

And my Nvidia Settings via NVPI

 

 

Best regards and thanks in advance

Robo

Edited April 9 by RoboHackfeld

[Qcumber]

19 minutes ago, RoboHackfeld said:

My Latency in VD is always between 40 and 60 and Networking around 8 - 12 ms but the same happens if I use the link cable and Meta-Link

What do the rest of your VD latencies look like? Can you do a screen shot of the in game overlay? I suspect you are trying to run too high a bitrate. Anything over 200mbps for me at h264+ causes big networking and deciding latencies. You could try reducing this to 200. I gave also found that HEVC at 150 is more stable. 

Have you looked at your CPU latencies look like? Is the load spread over all CPU cores or maxing out on one? 

Edited April 9 by Qcumber

[RoboHackfeld]

Thanks for ur reply,

I will provide those screenshots tomorrow and will check the CPU load. 

I also tried the other codecs and lower bitrates without any success. And like written above, same Problem with Meta-Link.
 

Now after 2h of testing its bedtime. 

 

[RoboHackfeld]

 @Qcumber here are the screenshots/photos.

I think it all looks pretty good and like normal behaviour.

 

I just ran also some more tests:

Test 1: Caucasus, Airfield full of static Smoke

Result: No problem. Frametime raised to 10 maybe 11 but was constant and smooth.

 

Test 2: Same Airfield, Static units (10 vs 10) shooting at each other. Waited till some Tanks begin to smoke

Result: No problem

 

Test 3: Syria, two groups of Tanks (10 vs10) driving at each other and when in range firing at each other. Waited till some Tanks begin to smoke

Result: No Problem

 

Test 4: Syria, two groups of Tanks (25 vs 25) driving at each other and when in range firing at each other. 

Result: Almost completely stable, at the first run I had the same problem with my tests yesterday (Armored Convoy Mission) but the two tests after I could not reproduce that.

 

Test 5: Armored Convoy Mission.

Resut: same result like yesterday.

 

Now I really dont think it is the smoke. I think this mission is just very heavy with lots of different AI Units, moving, shooting, exploding, smoke, me and my wingman. I think this is just too much for my 5800x3D

 

Maybe if I find the time I will run a dedicated Server on my rig to see if that could take some Load from my CPU.

Edited April 10 by RoboHackfeld

[Qcumber]

11 minutes ago, RoboHackfeld said:

 @Qcumber here are the screenshots/photos.

I think it all looks pretty good and like normal behaviour.

 

I just ran also some more tests:

Test 1: Caucasus, Airfield full of static Smoke

Result: No problem. Frametime raised to 10 maybe 11 but was constant and smooth.

 

Test 2: Same Airfield, Static units (10 vs 10) shooting at each other. Waited till some Tanks begin to smoke

Result: No problem

 

Test 3: Syria, two groups of Tanks (10 vs10) driving at each other and when in range firing at each other. Waited till some Tanks begin to smoke

Result: No Problem

 

Test 4: Syria, two groups of Tanks (25 vs 25) driving at each other and when in range firing at each other. 

Result: Almost completely stable, at the first run I had the same problem with my tests yesterday (Armored Convoy Mission) but the two tests after I could not reproduce that.

 

Test 5: Armored Convoy Mission.

Resut: same result like yesterday.

 

Now I really dont think it is the smoke. I think this mission is just very heavy with lots of different AI Units, moving, shooting, exploding, smoke, me and my wingman. I think this is just too much for my 5800x3D

 

Maybe if I find the time I will run a dedicated Server on my rig to see if that could take some Load from my CPU.

In the VD overlay the network latency is quite high and your router speed is 866. Mine is usually stable at 1200 and the network latency is 2-4 ms. Try reducing the bitrate to 200 Mbps.

It would be useful to see your CPU and GPU latencies in game too as your CPU looks like it might be a bit overloaded. 

It would also be worth uploading your DCS log to the discord log analyser to see if there are other issues at play. 

[RoboHackfeld]

 

vor 14 Minuten schrieb Qcumber:

It would be useful to see your CPU and GPU latencies in game too as your CPU looks like it might be a bit overloaded. 

I will provide the GPU Load as well but I noticed that my gpu is just bored in those situations. But can not tell you the exact Load of the gpu.

And yeah I also think my cpu is overloaded. Its just those situation where the CPU Load (AI Units all over the place, moving, shooting, exploding, triggers, SAMS, Radar......) just moves past the GPU Load so I am cpu bound and my CPU just is not able to push more. If I turn my head away or just move away from those situations everything is smooth and I am GPU Bound with 72fps and theoretical Frames over 100 up to 140.

vor 16 Minuten schrieb Qcumber:

In the VD overlay the network latency is quite high and your router speed is 866. Mine is usually stable at 1200 and the network latency is 2-4 ms. Try reducing the bitrate to 200 Mbps.

My Router, I think it can not provide more than 866. I also tried 150 Bitrate with another codec but that also did not help. The router is directly next to me, just one arm lenth. Dew to the fact, I have the same problem with Oculus Link via cable I dont think it is bitrate related. 

 

vor 17 Minuten schrieb Qcumber:

It would also be worth uploading your DCS log to the discord log analyser to see if there are other issues at play. 

It just tells me to turn OFF GameBar which I already have and HAGS which is also worth a try. Will try that one next. 

[Qcumber]

53 minutes ago, RoboHackfeld said:

And yeah I also think my cpu is overloaded

It would be worth measuring the CPU render time. If you have OXRTK you can enable an in game overlay and even export the results (as long as Turbo mode is disabled). If your CPU is overloaded you will see either a high render time or a rapidly fluctuating render time. 

[RoboHackfeld]

You are talking about the overlay which shows FPS, CPU and GPU [ms] in yellow? But how to export that?

 

[Qcumber]

1 minute ago, RoboHackfeld said:

You are talking about the overlay which shows FPS, CPU and GPU [ms] in yellow? But how to export that?

 

Yes. The advanced overlay. In the first tab of OXRTK there is a function at the bottom that allows you to record. This is the saved as a CSV file that you can then open in excel or Google sheets. Just run it through an episode where you get the problems and another when it is more stable and then we can see what is happening to the render times. 

[RoboHackfeld]

Okidoki, have a meeting this morning after that I will do some testing. Thanks!

[sleighzy]

What's the gold shield in that VD overlay beside the bitrate? Do you have like secure encrypted network connections enabled (I can't remember the specific VD setting). Turn that off, or whatever you have enabled that is causing that shield to be displayed.

[RoboHackfeld]

@sleighzy I think, it just means that the bitrate is locked to that rate. It is not variable. 

 

So here the csv files. I made one with and one without HAGs. Turning HAGS Off just made it worse (dropped under 50) but could also be a different situation where maybe the situation on the ground was just a little differen. 

stats_20250411_154112 NO HAGS Begin Row 197.csvstats_20250411_152947 HAGS Begin Row 216.csv

[Qcumber]

1 hour ago, RoboHackfeld said:

@sleighzy I think, it just means that the bitrate is locked to that rate. It is not variable. 

 

So here the csv files. I made one with and one without HAGs. Turning HAGS Off just made it worse (dropped under 50) but could also be a different situation where maybe the situation on the ground was just a little differen. 

stats_20250411_154112 NO HAGS Begin Row 197.csv 21.29 kB · 1 download stats_20250411_152947 HAGS Begin Row 216.csv 24.72 kB · 1 download

Something isn't right with those render times. The AppCPU should be very low, but it showing as about about 7-12 ms and sometimes a lot higher. The render CPU and render GPU should be in the 7-14 ms range but they are showing as about 15-200 microseconds. Did you run these without turbo mode enabled? Have you got any other mods enabled? 

[RoboHackfeld]

vor 22 Stunden schrieb Qcumber:

... (as long as Turbo mode is disabled).....

Turbo mode was Off yes no mods except of the Empty Hangar Mod.

Should I activate/oben OXR Toolkit befor starting the game? 

 

I run 64GB of DDR 4 3200 dont know if that could be something?

 

Edited April 11 by RoboHackfeld

[Qcumber]

3 minutes ago, RoboHackfeld said:

Turbo mode was Off yes.

I'm not sure what the issue is but something is messing with the render time measurements. 

[RoboHackfeld]

Could you show me how it looks at your side? Do you have a log like that?

 

Just to understand that correctly,

 

If there is 

2025-04-11 15:45:27 +0200, 72,0.13823,283,163,5319,35

Time: 2025-04-11 15:45:27 +0200

FPS: 72 

appCPU: 0.13823 - 13,823ms

renderCPU: 283 - 283us = 0,283ms

renderGPU: 163 - 163us = 0,163ms

Vram: 5319 - 5.316GB

Vram%: 35 - 35%

 

Is that correct? So the two render points are too high?

 

AppCPU is the frametime I guess? Yes this one is arround 1-6ms if I am up in the air unless there is a lot going on and I am close to the ground. Than it raises and I think at 14 and above or something like that the frames go below 72fps. 

 

What do you think about the values at the beginning of my CSV Files? There it looks better and of course that is always the point where I am up in the air, gpu bound with 72fps and theoretical fps of about 100+.

For example:

2025-04-11 15:42:09 +0200,72.0,8100,186,17,6519,43

appCPU: 0.8100 - 8,1ms

renderCPU: 186 - 186us = 0,186ms

renderGPU: 17 - 17us = 0,017ms

Vram: 6519 - 6.519GB

Vram%: 43 - 43%

 

Edited April 11 by RoboHackfeld

[sleighzy]

Could you drop your log file here as well. Do you run Quad Views (this has turbo mode enabled by default in case this is messing with the measurements that Qcumber is mentioning)? This would show up in the DCS log file to.

EDIT: I see in your VR settings screenshot that Quad Views is toggled on, and that there is an exclamation mark beside it. The exclamation mark is fine, but indicates you have OpenXR API layers installed. So possibly you have Quad Views installed, will wait for your confirmation. You can use the Tallymouse companion app to turn off turbo mode vs. manually in the QVF config settings file https://github.com/TallyMouse/QuadViewsCompanion. That screenshot also shows you have Bloom Effect enabled, turn that off if using Quad Views. A lot of the Quad Views functionality replaces OpenXR Toolkit so you could remove OXRTK vs. running them both together.

Possibly unrelated but there are known performance issues with later versions of the Nvidia driver and 5000 cards. A number of people have been dropping back to the 566.36 version so could try that as well (could use DDU on the drivers prior to installing 566.36 to ensure clean).

Edited April 11 by sleighzy

[Qcumber]

29 minutes ago, sleighzy said:

Could you drop your log file here as well. Do you run Quad Views (this has turbo mode enabled by default in case this is messing with the measurements that Qcumber is mentioning)? This would show up in the DCS log file to.

EDIT: I see in your VR settings screenshot that Quad Views is toggled on, and that there is an exclamation mark beside it. The exclamation mark is fine, but indicates you have OpenXR API layers installed. So possibly you have Quad Views installed, will wait for your confirmation. You can use the Tallymouse companion app to turn off turbo mode vs. manually in the QVF config settings file https://github.com/TallyMouse/QuadViewsCompanion. That screenshot also shows you have Bloom Effect enabled, turn that off if using Quad Views. A lot of the Quad Views functionality replaces OpenXR Toolkit so you could remove OXRTK vs. running them both together.

Possibly unrelated but there are known performance issues with later versions of the Nvidia driver and 5000 cards. A number of people have been dropping back to the 566.36 version so could try that as well (could use DDU on the drivers prior to installing 566.36 to ensure clean).

Yes. Good point regarding QVFR. This could have Turbo enabled which would mess with OXRTK stats. 

I am using the latest NVIDIA driver with the 5080 with no issues. From what I have read, most issues with 50xx GPUs  are related to early versions of the 572 driver. Or using 40xx or 30xx GPUs. 

[sleighzy]

1 hour ago, Qcumber said:

most issues with 50xx GPUs  are related to early versions of the 572 driver.

Sweet, yeah they're on the latest 572.83 version which had 5000 series fixes. Will check the recent Discord channel references on specific versions. Was just a side note, likely unrelated.

[RoboHackfeld]

Thanks @sleighzy and thanks @Qcumber for your help. 

 

Yes I have QVFR installed and only the size of the focus area adjusted in the config file. So I will run the tests again without the Turbo Mode of QVFR.

 

I never noticed I have enabled bloom effects. I will disable that too. 

 

vor 9 Stunden schrieb sleighzy:

so you could remove OXRTK vs. running them both together.

But than I can not record the statistics right?

dcs.log

Logfile is attached.

 

[Qcumber]

5 minutes ago, RoboHackfeld said:

Thanks @sleighzy and thanks @Qcumber for your help. 

 

Yes I have QVFR installed and only the size of the focus area adjusted in the config file. So I will run the tests again without the Turbo Mode of QVFR.

 

I never noticed I have enabled bloom effects. I will disable that too. 

 

But than I can not record the statistics right?

dcs.log 148.41 kB · 1 download

Logfile is attached.

 

Just try disabling Turbo in QVFR and OXRTK for now. You can still then record the stats. 

[RoboHackfeld]

stats_20250412_104858.csv

Here is the CSV without QVFR Turbo Mode. Performance wise didnt change much and I think those stats are quite similar? Butmaybe now there is more load on the gpu  or am I wrong?

 

 

Edit: 

QVFR: Turbo Mode = 0 - No success

Disabled OXRTK - No Success

Exited some programs like Steam, Tobii experience. - No success; maybe I will try more of that and disable programms like Afterburner, NZXT Cam, HWInfo etc. 

 

Here is what I described very early in this thread, that the frametime rises frequently and than - boom- back down.. rise, rise , rise ,rise - boom down. 

And thats why I think there is something going on with the rendering/animation of the smoke. In that video I have active pause mode turned ON and I am looking directly at that problematic situation while the smoke is moving. So I think there are different stages of the smoke-rendering-animation-thingy where the load raises and than when the smoke animation resets itseve (visually not noticable and just my theory) the frametime goes down. Dont know what happening there in the background.

 

Could it not just be, that my CPU is just too week in this particular situation? 

Idk if you know this mission. It comes with the A10 Modul. Syria, Armored Convoy. 

For my benchmarking, I star tthe mission activate Autopilot and fly in circles untill T=500 (so the action begins) than I fly to the convoy. The first units apearing, some artillery, some trucks, when they are shot down and burning and I look into their direction I got the problem.

If I fly past them there are alot more units and also more units burning I dont have this problem. My Frametime raises to like 10 but not more and my frames stay stable. I think this one is a combination of my "weak" cpu and the mission. 

 

Edited April 12 by RoboHackfeld

[Qcumber]

Thanks. I have had a look at this. These are plots of your frame times and FPS. Firstly your GPU performance. The mean latency is 10.8 ms which is well below what you need to maintain 72 fps. However there is a demanding part of the track which pushes the latencies higher than 13.88 ms resulting in about 10% missed frames (everything right of the black dotted line). This may not be noticeable in average FPS count but can be seen as stutters. 

 

Next the CPU frametimes. As I said earlier App CPU is normally very low. Below are plots from both App CPU and Render CPU times and the total CPU time. The App CPU time is consistently grouping around 13ms. The render CPU time is all over the place between 5 and 16 ms. Combined this gives a mean CPU time of 21 ms which is very high.

 

Finally a chart showing the latencies and FPS over the whole track. I have edited out the start and end as these artifacts presumably as you started and stopped the recording. 

The GPU render times are good for the first 20s or so (around 10-11 ms so well below the magic 13.88 needed to maintain 72 FPS (horizontal black dashed line)). App CPU time is around 13 ms. As I said above this is normally low (1-3 ms). It is the time needed for DCS to process the information before it can be rendered and sent to the GPU. The middle of the track appears to be very heavy on both your GPU and CPU as there are periodic spikes in both GPU and CPU frametimes and corresponding drops in framerates. This suggests to me that your hardware cannot handle the DCS settings. 

 

So what next? I would suggest reducing DCS settings to as basic as possible and run a track with a simple module over a non populated part of Caucasus above 10000 feet. Keep clouds to a minimum. This should then show if it is a limitation of your hardware or if is something else. 

 

 

Edited April 12 by Qcumber

[RoboHackfeld]

At first, thanks for this very on point analysis and for providing those charts.

 

When you say the times are okay for the first Seconds, could it be, that spooling time (strg + y) could mess up those frame times? Sorry I did not mention this earlier because I did not think this could be a problem but when you say it is okay at the beginning it is always when I run the mission, I turn off symbols, set my cockpit position activate auto pilot and than hit several times strg+Y so I can skip time until action on the ground begins, where my problems start.

 

The middle of the tracks, where the heavy spikes appear, yes thats what I am talking about and I already tried to lower settings, I lowered everything to potato really the lowest settings of the low but in this situation I guess my CPU can just not handle all the AI Units, what they are doing and the smoke effects. 

 

I will prepare an empty mission and will have a look at those log files.

 

Thanks

Robo

[Qcumber]

19 minutes ago, RoboHackfeld said:

When you say the times are okay for the first Seconds, could it be, that spooling time (strg + y) could mess up those frame times?

I'm not sure. It could be. Try running a track without it.