Qcumber

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.

I'll post my blank spreadsheet later then you can have a go. I'll also try to explain my workflow. Once you get used to it it's quite quick and easy.

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?

In DCS for the standard scaling. In DLSSTweaks or NVPI for the bespoke scaling.

You can still change the scaling and you can see the difference between performance (0.5) and quality (0.66). You can also set bespoke scaling. I have tried up to 0.9 and this gives you great quality but with better performance than DLAA.

I've got +420 and +2000 stable in DCS..I can manage higher in synthetic benchmarks but it does not carry through to DCS. It might be because I use DLSS.

I did a quick test comparing DLSS K using DLSSTweaks and NVPI Resolution set to 4900x5000 in OXRTK Quest pro with Meta cable link at 72Hz smoothen_focus_view_edges=0.1 sharpen_focus_view=0.2 horizontal_focus_section=0.28 vertical_focus_section=0.28 peripheral_multiplier=0.28 focus_multiplier=1.0 All DCS settings were the same. Driver 572.82 This is a recorded track of an F-16 flying over Syria map (F-16 instant action free flight) for 1 minute. DLSS 3.10.2 quality (set using either DLSSTweaks (T1, blue) or NVPI (T2, purple) [I ran the one with NVPI before installing DLSSTweaks]. As you can see there is no difference with a 5080, although there were slightly fewer dropped frames using NVPI (0.2% vs 2.8%). Another test comparing preset K (T1, blue) with preset C (T3, green). Both are using DLSSTweaks. In this case, as expected, "C" has a shorter GPU latency than "K" (8.65 ms vs 10.04 ms) but was a noticeably softer image. I was unable to properly compare ghosting in this track. CPU latencies for the same runs.

Thanks for the heads-up. I might give it a go and see if it makes a difference for me. What does ghosting look like for you with these settings?

OXRTK still has some relevance but it's not a magic bullet. Turbo mode can help but it can also make things worse in some cases. It very much depends on your setup. If it works for you now that's great but it's not something that should be automatically enabled by everyone in VR.

Try OTT

This is the encode resolution. It is different to the rendering resolution. This is set through supersampling. The native resolution of the Quest Pro is about 1900 x 1800. Super sampling of 2 would give you 3700 x 3600. It would be worth mentioning that super sampling can be set in several places so it can become confusing. It's best practice to use a single place for SS. For example set the resolution slider in the Meta app to x1 and pixel density in DCS to 1. Then use OTT or ODT to SS to at least 1.5 native resolution. It might be worth posting some starting settings which match different CPU/GPUs. It might be worth having some starter settings here and expectations. Especially regarding presets. DLSS 4 is very good but you need to SuperSample very high to get rid of ghosting. I use a QVFR foveated SS of equivalent to 5000 pixels and then about 1500 for the periphery. This gives very good results with DLSS quality preset K. Equivalent to DLAA with a much lower impact on performance. Thanks for putting this together. I think it will be very useful for VR newbies.

You will need to restart DCS after each change. Another option is Oculus Tray Tool. It accesses all the same settings as ODT but you can use it from your desktop so its a bit easier. https://www.guru3d.com/download/oculus-traytool-download/

Being CPU limited in the DCS monitor does not necessarily mean that what you might think. It's best to look at your CPU and GPU render times in OXRTK or XRFrametools (or similar). This will give you a much better idea if how much load is on your CPU and GPU. Also look at individual core performance of your CPU to see if a single core is maxed out. OXRTK is an add on tool. It does not replace ODT. Although it is no longer officially supported it still has some useful tools.

It sounds like Asynchronous Space Warp us kicking in. Try disabling this in Oculus Debug Tool. You can also change these on the fly with these keybinds CTRL+KP1 - Disable ASW and USE ATW CTRL+KP2 - Force apps to 45hz, DISABLE ASW CTRL+KP3 - Force apps to 45hz, ENABLE ASW CTRL+KP4 - Enable ASW to operate automatically I would advise looking at your CPU and GPU latencies in the DCS FPS game overlay or better still using OXRTK. This will let you know how close you are to maintaining 72 FPS. The magic number for you GPU is 13.88ms. Having recently had chance to try the 5070ti you should be able to maintain 72 fps in most situations. Don't forget that VR is like running two 4k monitors so it is very demanding.