Qcumber

I'll update it later so that it has up to 50 ms then set all the charts to the max value. Then it will be standardized for reprojection frametimes too. I probably won't get chance until this evening UK time though.

You could send me a recorded track then I can try running it on my PC. See if I get the same issues.

I wonder what the 5060ti 16Gb will look like in DCS. Might be a consideration instead of the 5070.

Yes. Just go into the chart and increase the data range for that sample. I think I have included up to 50ms. If no then I can always update the blank spreadsheet and repost it.

The GPU frame times are longer than 20 ms so they were not showing. I have extended the chart to 30ms. I've updated the SS for you. What DCS settings are you using and what is the module/map/track? ColdViPer benchmark.xlsx

What is the module and map? If you send me the track I can try running it and see if I get the same issues.

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

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.

Are you using link cable? If so then the max bitrate is 960 mbps. Try increasing to this and see if it works OK on your system. I think setting to 0 is default but I can't remember what that is. I presume that you mean Open XR Toolkit? Open XR is the API through which DCS and the Meta app communicate.

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

I really hope they do. With a possible extension across the Netherlands to the east of England. That would make long range missions to Berlin possible.

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.

You need to get a direct download. Here is the thread I started with Fred on GitHub. Hopefully that link will work ok. Just use this version for the log conversion not the capture. https://github.com/fredemmott/XRFrameTools/issues/34#issuecomment-2737326559 XRFrameTools is still in "alpha" but hopefully there will be an update soon so that this issue is fixed.

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

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?

An alternative method for capturing the data is to use the OXRTK "Record statistics" function. This is at the bottom of the first tab. Enable "High Rate Statistics". The log file is created here: %LocalAppData%\OpenXR-Toolkit\stats This is an easier method but only gives you an average of about 7-8 frames at 72Hz. The spreadsheet will need adjusting accordingly using this method. Overall I prefer the XRFrameTools method as it captures every frame.

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.

So far I have just done a simple overclock of the 9800x3d using Ryzen Master. And the MSI afterburner overclock I mentioned above. Nothing at BIOS level yet. I am testing an MSI curve overclock at +415 with a cap at 1000mV/3200Mhz. So far it is stable and still gives me a decent performance boost. If it helps I can post my results from 3d mark.

I am starting to get some very good results with the 9800x3d and 5080. 72Hz is overall probably the best option but I have been getting some surprising results at 90Hz. I need to do more testing then I will post.

I have made a new post with my methods and spreadsheet.

I have just posted my spreadsheet and workings here. I am very happy to collaborate. Try to find some way of standardising the benchmarking in VR. Any suggestions on developing and streamlining the workflow would be very much appreciated.

For those of you who have not seen this yet (and at the request of a couple of forum users) here is a method I have been using to benchmark VR.* Please note that you will need to have some experience with using spreadsheets before trying this. I do plan on making the workflow a bit more automated if I can but have not yet got round to this. I have attached my blank spreadsheet below. Latest version: XRFrametools Benchmark blank (V4b) - Forum Copy.zip For this you will need to download the software XRFrametools by Fred Emmott. Release v0.2.0: bugfixes · fredemmott/XRFrameTools · GitHub. This will allow you to capture individual frame measurements within DCS. The ones we are interested in primarily are CPU render time, GPU render time, VRAM use frame interval and FPS. Please let me know if this is useful as I would like to see how it compares with other setups. Steps: Open DCS in VR and load a mission that you want to use as a test. I would advise recording a 60s track for reproducibility. Get everything ready then hit pause and Alt-tab out of DCS. Make sure that Turbo mode is disabled in OXRTK or QVFR if you are using it. Run XRFrameTools and navigate to the "Perfromance Logging" tab. Select "Enable for>1 minute". Then Alt-tab back to DCS and un-pause. Let the track run for 60s then exit. Open "Performance log>convert log to CSV" then adjust the setting for "1 frame per CSV row". Click save. Open the CSV file and then copy the contents into one of the test pages in the attached spreadsheet (T1, T2 etc.). These should be copied into columns V onwards. Please note that the number of rows can vary a little so check at the bottom of columns E:H and delete any rows with "0" if you want correct mean, min, max etc. You can then view the charts in the first tab of the spreadsheet along with mean data in the table. Parameters measured FPS displayed as both time and frequency of occurrence (% of total)#. Frame Interval displayed as frequency of occurrence (% of total)# Smoothness is derived from the coefficient of variation of the latency or fps. The percentage variation away from the mean. This gives you more information than just looking at % lows. This is useful if the average FPS counter shows that you have 72 FPS but you still may have some stutters. You may be getting more variation in Frame Interval that may not be obvious with average FPS. CPU latency, displayed both as time and frequency of occurrence (% of total)#, and the mean. GPU render time, displayed both as time and frequency of occurrence (% of total)#, and the mean. # Frequency of occurrence is a measure the number of events which fall within bins of either 0.1 ms (latency) or 0.5 fps (frames per second). Example This example compares without (blue, T2) and with (green, T6) QVFR. The data here is a plot of the frequency at which CPU latency and GPU render times occur (as a percentage). In this case GPU render times are slightly better with QVFR enabled, CPU latency is slightly longer (about 1ms) and FPS is smooth at 72 fps. null UPDATE 9 June 2025 (v4b) Error with formula corrected. UPDATE 8 June 2025 (v4) The spreadsheet has been updated as follows: Updated CPU latency to include both app and render time. Default latency setting on charts set to 30 ms Added FPS by occurrence and Frame Interval. Added new feature called "smoothness" which calculates the variation of FPS and Frame Interval from the mean. This is useful if the average FPS counter shows that you have 72 FPS but you still may have some stutters. UPDATE 28 April 2025 (v3) The spreadsheet has been updated as follows: Fixed some errors with formulas. Added VRAM chart. Reduced maximum chart latency to 30 ms (if anyone wants to extend this then you can just change this in the chart data). UPDATE 13 April 2025 (v2) The spreadsheet has been updated as follows: Maximum latency now 50 ms for CPU and GPU charts FPS count CPU render and GPU render over time added. Vertical lines added to represent 90, 72, 45 and 36 FPS respectively (the last 2 relate to reprojection at 90Hz and 72Hz). *This is based on the method used in this YouTube channel "Benchmark Odyssey". So thanks for the ideas an inspiration From <https://forum.dcs.world/topic/371802-vr-benchmarking-methods/?do=edit>

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.

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.

Good point. I'll create a new post and then add the link here and in my other threads for consistency.