Ready

No worries this is what I am running

Thanks for the additions

crop2fov - OpenXR Toolkit mod I came across this nifty mod of OpenXR Toolkit by OhneSpeed that lets you crop the pixels that are not visible in the headset -> less to render for the GPU -> performance improvement without visual effects! I ran it and was able to shave off 10% from the vertical and 5% from the horizontal. I am still tweaking and think I can further reduce a bit in the horizontal. I did not make a calculation of the actual gain, but every little bit helps! I am still using OpenXR Toolkit for visual tweaks, Turbo Mode and overlays. So now I use crop2fov next to Quad Views Foveated. https://drive.google.com/drive/folders/1lYT8i393Wnvp9L87ICHWdqkezZpujx2v Some words of advice (Big thanks to Kelju for getting me started); Bring Back OpenXR Toolkit to default settings before installing. Rename the original .dll and put the modded one in its place. Restart the game. Open the toolkit as normal and go to the system tab. Select fov2crop as the resolution and start changing the percentages. Keep looking straight ahead with your eyes. Start reducing percentages and use peripheral vision to spot the black borders appearing around the sides of the headset. up = top side of vertical fov for both eyes down = bottom side of vertical fov for both eyes left/left = left side of left eye, ie. far left of horizontal fov left/right = right side of left eye,ie. stereo overlap for left eye right/left = left side of right eye, ie. stereo overlap for right eye The borders are quicker to spot in the peripheral, so keep looking straight ahead with the eyes and quickly move the head back and forth, left and right, up and down. Once the black bars are visible, ease off a bit until they are no longer visible. Settle and notice the reduction in percentages in the menu. Restart the game for the final result to take effect. If using Quad Views while cropping you will see weird visual effects. Just ignore these, they will dissapear once you restarted the game.

Hi I went through the various items, see below my comments/questions regarding the various documents on your github. Readme.md System Restore: it is not very stable for me and I have disabled it completely, also recommended by some. Backup: I am using Macrium Reflect for making daily backups, which works like a charm. O&O shutup: I turned off too much before. Will run through it again. Nvidia Profile Inspector: I used to change things with the profile inspector but nowadays mainly use NVCP. Scripting: It all looks very cool and handy, but I think I will stick to the way I am currently doing my tests. Burned my fingers before with scripts that did not fully work, no offense meant. Performance testing: i am doing al lot of quick tests, just sitting on the ramp in a stock mission. I am using the A-10 on Marianas in the take-off mission and leave my headset on the desk. For quick tests I am not flying around with large scripts. I do that only after I have come to a configuration where I am pretty happy. performance-guide.md I like the way you have created the layers table. I would make BIOS a separate layer. Add GPU and PSU to the items to optimize in the Rig layer. I am also using quite some mods and peripherals for DCS, would add them somewhere too. Maybe swith VR optimization (I have hardware VR items) and DCS optimization. Also in DCS there are some items you can optimize while in game that make a big impact, like trees and details. Registry Optimizations I am curious but very cautious with adding keys to the registry. I am going to check the videos you referenced and will circle back later. Windows Services Somehow the following services were disabled before but enabled again automatically. AppX Deployment Service, Asus Update Check, Power Service. Scheduled Task Optimization I see a lot of scheduled tasks under Windows. There might be more there to disable. Things that just cause Windows to do stuff while gaming. I removed Dropbox Update scheduler I disabled ProcessMemoryDiagnosticEvents

Hi I went through the various items, see below my comments/questions regarding the various documents on your github. Readme.md System Restore: it is not very stable for me and I have disabled it completely, also recommended by some. Backup: I am using Macrium Reflect for making daily backups, which works like a charm. O&O shutup: I turned off too much before. Will run through it again. Nvidia Profile Inspector: I used to change things with the profile inspector but nowadays mainly use NVCP. Scripting: It all looks very cool and handy, but I think I will stick to the way I am currently doing my tests. Burned my fingers before with scripts that did not fully work, no offense meant. Performance testing: i am doing al lot of quick tests, just sitting on the ramp in a stock mission. I am using the A-10 on Marianas in the take-off mission and leave my headset on the desk. For quick tests I am not flying around with large scripts. I do that only after I have come to a configuration where I am pretty happy. performance-guide.md I like the way you have created the layers table. I would make BIOS a separate layer. Add GPU and PSU to the items to optimize in the Rig layer. I am also using quite some mods and peripherals for DCS, would add them somewhere too. Maybe swith VR optimization (I have hardware VR items) and DCS optimization. Also in DCS there are some items you can optimize while in game that make a big impact, like trees and details. Registry Optimizations I am curious but very cautious with adding keys to the registry. I am going to check the videos you referenced and will circle back later. Windows Services Somehow the following services were disabled before but enabled again automatically. AppX Deployment Service, Asus Update Check, Power Service. Scheduled Task Optimization I see a lot of scheduled tasks under Windows. There might be more there to disable. Things that just cause Windows to do stuff while gaming. I removed Dropbox Update scheduler I disabled ProcessMemoryDiagnosticEvents

Hey Wolf! I have looked at some tools before that were doing scripted rig optimizations, but did not continue because I got no clarity on what was happening. I also overdid it a couple of times by blindly trusting stuff that landed me in big trouble. So I am now only testing one setting at a time and log every step of the way because trying out combinations sometimes also is confusing and then I have to roll back to find that one thing that made things better or worse.. I also see that in my rigs configuration some settings are different than popular items, they somehow work better for me. I see you have documented everything well and I like the automated testing. I am at around test #500, will post my recent testing results soon, so automated testing might have saved me some time . I will definitely take a good look. I don't know if I will run scripts, but for sure I will check if there are things in your approach that I did not try yet. Thanks for sharing all your work. Great!!

Frametime impact when hitting fps ceiling (and impact of FPS capping) In previous tests I never fully understood why my 1% and .02% lows decreased once I was hitting the max of my FPS in DCS. So I ran some tests with RTSS fps capping and got some more information. -- So it is expected behavior due to how frame limiting and GPU scheduling interact. Let’s unpack why your 1% and 0.2% lows actually get worse when you hit the FPS cap (e.g. 90 Hz), and why they look smoother slightly below that (e.g. 86 fps). The core reason: Hitting the FPS cap causes frame pacing stalls When you set a hard FPS cap (90 fps, matching your headset refresh), the GPU occasionally finishes frames too early. When that happens: The GPU has to wait for the next vsync / frame presentation slot. That wait = an idle stall → inconsistent frame timing. Those micro-pauses show up as spikes in frametime variance (bad 1% and 0.2% lows). So even though the average FPS stays perfect (90), the frametime consistency drops — especially visible in the lowest percentile metrics. Why going slightly under (e.g. 86 fps) feels smoother When you run slightly below the cap: The GPU is continuously working, not waiting for the display to catch up. There are no forced waits or timing clashes with the vsync cycle. Frame delivery becomes more even, resulting in better 1% and 0.2% lows (lower frametime variance). In VR, this smoother motion pacing is far more perceptually important than the last few frames per second. In DCS VR specifically (Varjo, OpenXR, etc.) DCS has: No frame-time prediction or pre-render smoothing (unlike modern engines). A heavy main thread and GPU dependency mismatch. A frame cap that interacts badly with OpenXR’s compositor timing when the GPU hits its ceiling. So when the engine saturates the frame pipeline at exactly 90 fps: The compositor sometimes misses or delays a frame sync event, …causing periodic frame “jitter” that CapFrameX or FrameView reports as 1% low drops. Analogy Think of it like driving: If your car is exactly touching the speed limiter, you’ll constantly “bounce” between acceleration and braking — jittery. If you cruise just below the limiter, you maintain smooth, steady motion. Best practice for DCS VR Setting Recommendation Why FPS cap Use RTSS or OpenXR Toolkit to cap ~4–5 fps below headset refresh Keeps GPU from hitting limiter stalls Vsync Off (let OpenXR or Varjo handle presentation timing) Prevents driver-level stalls Frame timing target 11.5 ms @ 86 fps for 90 Hz headset Leaves headroom for compositor and CPU GPU load target ~90–95% max Avoid 100% GPU utilization to maintain consistent frame times Why RTSS frame caps near the headset refresh (88–89 fps @ 90 Hz) can hurt RTSS (and most external limiters) work by holding back frame submission in the GPU driver before it’s presented. That’s fine for flat-screen gaming, but DCS + VR + OpenXR adds another layer: OpenXR’s compositor needs a predictable cadence to reproject and time frames. RTSS intercepts and delays frames after DCS but before OpenXR sees them. At 88–89 fps, that delay can desynchronize the compositor timing by a few milliseconds. Result: irregular frame presentation → frametime spikes (even though FPS looks “almost perfect”). That’s why your 1%/0.2% lows drop sharply when using RTSS at 88–89 fps. Why increasing DCS visual load instead is sometimes better When you naturally run below 90 fps due to higher graphics load: DCS and OpenXR see a continuous, un-capped render cycle. No injected wait by RTSS → more natural pacing. The GPU runs close to full, but not stalling. Frame variance is lower — subjectively smoother, even if the average FPS is a bit lower. This “organic under-load” behavior gives OpenXR and Varjo’s compositor cleaner, predictable frame intervals. null

HAGS ON, HAGS OFF I sometimes see recommendations that I should disable HAGS. In my case before it brought me better VR performance when I kept it on. -- On some systems HAGS (“Hardware-Accelerated GPU Scheduling”) can boost VR smoothness. Let’s look at why that happens, when it’s actually good, and when it’s masking another issue What HAGS really does Normally, the Windows GPU scheduler (WDDM) queues and manages all GPU workloads in system memory. With HAGS = ON, those queues move into VRAM, and the GPU handles scheduling directly — reducing CPU overhead and latency. In simple terms: Without HAGS With HAGS Who schedules GPU work Windows kernel The GPU itself Latency Slightly higher Slightly lower CPU load Higher Lower Stability (drivers) Very high Depends on driver quality Why it can improve VR performance for you In VR (especially DCS + Varjo + OBS + SRS): You’re running multiple GPU clients: Varjo compositor, DCS render threads, NVENC encoder, desktop compositor, etc. HAGS can offload scheduling from the CPU → a few ms less latency in the render pipeline. That shows up as smoother frame-time graphs and fewer reprojection hitches. So yes — if you’re seeing clearly better smoothness with HAGS ON, it’s likely a real benefit, not placebo. When HAGS hides deeper problems HAGS can also paper-over an underlying bottleneck or driver-hang condition: Some NVIDIA branches (R560–R570) have occasional NVENC or compositor stalls. HAGS may reduce how often they trigger watchdog.sys (GPU timeout), but it doesn’t fix the root cause. If your system is marginal on power or thermals, HAGS shortens the Windows TDR watchdog window → less time for recovery → sometimes more BSODs. So it’s a balancing act: If HAGS ON = smoother VR and no stability loss → keep it. If you still see watchdog.sys or black-screen recoveries → leave HAGS OFF until driver 566.36 or later (those have better queue management). Recommended approach for your system After you install 566.36 cleanly (via DDU or clean install): Test both HAGS ON and OFF. Watch GPU frametime stability (Varjo Base performance graphs or CapFrameX). If ON gives you: Lower frametime variance, No TDR or VR compositor hangs, → keep HAGS ON. If you see occasional freezes or “watchdog” BSODs → turn it OFF; that’s the first indicator the driver branch isn’t coping well with your multi-app load. TL;DR HAGS can genuinely help VR smoothness by reducing CPU scheduling delay. On older or unstable driver branches it can trigger or mask GPU timeouts. With a clean 566.36 install and good latency settings, HAGS ON is often the better choice for Varjo + DCS if it stays stable.

Yes I have a Sabrent powered hub too. Fantastic device. I think it is a 10 port or something like that and completely full, like the back of my pc, all full. Will definitely dig into what is connected where and see what I can reshuffle.

I think it could be signalled. I also adjusted the polling rate before and used latencymon to find/indicate troubling stuff. I will continue with the USB topology in a bit, hoping there is more stability to gain there. In the end it might be marginal improvements overall, but a lot of small things add up. I must say it feels more stable already. Am also going to dive into my recording settings and optimize those because I always have that running as well and it consumes 5-10 fps.

Hunting for latency culprits TL/DR: I knew that something in my USB devices was creating a load of interrupts. This came to light as well when I was experimenting with Virtualization settings and talking to my new friend ChatGPT (which causes a lot of headaches and frustrations, continuously tests my patience but also regularly brings good point). I strangely have better performance when HVCI=ON, while it should give a worse performance. This points to underlying issues that are being somewhat masked it turns out. In the past I have been working with latencymon a lot but never got further than one driver that was causing it all. So now I understand that this driver is actually covering for the real underlying reason; other bad(ly) configured drivers, amongst some other things. The first step I took care of was adjusting settings for my VB-Audio Cable, tool that I use for directing all the sounds through various devices. The next step will be to look into USB topology optimization, I am using a HUB as well and the combo of the VR, DAC and HUB can be somewhat toxic. Testresults will follow in a new post. --- Memory Integrity (virtualization-based kernel isolation) I tried some tests with HVCI - memory integrity on/off. Recommended OFF, but in my case ON gives better performance, which means there is an underlying cause. So here it begins... There are a few specific scenarios where HVCI being ON can appear to improve FPS or frametimes, even though it normally reduces performance. Before you change anything, let’s understand why you might be seeing better performance with HVCI ON, so you can make an informed decision. Why HVCI can Show Better Performance for Some Users 1. It Forces a More Consistent CPU Scheduling Model When HVCI is ON, Windows loads the hypervisor and forces a more rigid kernel scheduling model. This can reduce the “freedom” of drivers and low-level background processes to interfere with the game, and in some cases: lowers driver latency (especially if buggy drivers normally spike) reduces DPC latency spikes increases frametime consistency This is especially true if you had background drivers misbehaving, and HVCI’s isolation prevented them from hooking into the kernel. 2. You might have a driver or software that behaves badly unless HVCI is ON Some USB, audio, anti-cheat, or motherboard drivers behave more stable under VBS/HVCI, as they are restricted from “cutting corners”. If you have one “dirty” driver that misbehaves, HVCI can stabilize the system → giving the illusion of “higher FPS”, but in reality you’re getting fewer spikes. This happens often with: USB controllers used with VR headsets audio stack drivers (Realtek, Nahimic, Sonic Studio, SteelSeries, etc.) RGB/Peripheral software poorly written motherboard utilities 3. You might be CPU-limited and HVCI is shifting the bottleneck in a favorable way With DCS, CPU scheduling and frametimes matter more than raw FPS. If HVCI reduces background task “jitter”, your GPU gets fed more consistently → smoother VR frame delivery. What You Need to Know Even if you see higher FPS with HVCI ON, it does NOT mean: VBS is helping performance — it isn’t It will always stay this way — a driver change can flip the equation It’s the best long-term choice for stability It means your system has another underlying conflict, and HVCI is masking it by forcing stricter isolation. Think of HVCI as a band-aid that stops other drivers from causing trouble. The Smart Approach for You Instead of disabling HVCI right now and losing performance: Let’s find the driver or component that benefits from HVCI, so we can fix that and get the same performance without virtualization overhead. To do that, I need one detail from you: Does HVCI improve: A) FPS B) Frametime stability C) Both Example reply: Mostly B, frametimes become much smoother Once you reply, I will: ✔ Identify which driver type likely benefits ✔ Tell you how to isolate it ✔ Give the fix to get same or better performance with HVCI OFF This way you can gain performance without the hypervisor penalty. So — what exactly improves for you when HVCI is ON: A, B, or C? Je zei: c ChatGPT zei: Thanks — if both FPS and frametime smoothness improve when HVCI is ON, that strongly indicates this: HVCI is preventing a misbehaving driver or background kernel component from causing jitter and CPU scheduling delays. In other words: Your system has a driver or service that becomes unstable or noisy when allowed full kernel access. HVCI isolates it, so performance improves — but at the cost of virtualization overhead. The good news: If we identify and fix that driver, you could get even better performance with HVCI OFF (best of both worlds). The Most Likely Culprits (Ranked for DCS VR + Ryzen) These are the drivers that most commonly behave better under HVCI: Rank Driver / Component Why it causes issues 1 USB Controller Drivers (VR headsets) USB polling jitter affects VR frametimes 2 Audio Stack (Realtek, Nahimic, SteelSeries, etc.) High DPC latency & interrupts 3 RGB / Peripheral Software Polling & kernel hooks 4 Network Drivers (Killer, Intel, Realtek) Latency spikes in kernel mode 5 Anti-cheat or security software Hooks into kernel, causes stutters 6 Motherboard “Enhancement” Tools ASUS/ASRock/MSI services cause periodic CPU spikes 7 Faulty AMD chipset driver Rare, but affects CPU scheduling on Ryzen Because you mentioned VR (DCS), #1 and #2 are most likely. System Interrupts ≈ 1% at idle = not normal. For a healthy system, it should be ≤ 0.3% when idle. 1.0%+ means a driver is causing excessive interrupt activity and DPC load. This directly explains why: You get better performance with HVCI ON Because HVCI restricts that problematic driver’s kernel access Result: fewer interrupt spikes → smoother frametimes So now we know for sure: A kernel-mode driver on your system is misbehaving. We need to identify which one. The most common culprits for ~1% interrupt usage are: Category Hardware/Driver USB VR headsets, controllers, Bluetooth dongles Audio Realtek, Nahimic, Sonic Studio, SteelSeries, Asus audio Network Intel/Realtek NICs Storage NVMe driver, SSD firmware Motherboard utilities ASUS/MSI/ASRock background apps Next Step: LatencyMon LatencyMon will show: ISR (Interrupt) latency → which driver triggers interrupts DPC latency → which driver is deferring too much work Before I send you the LatencyMon instructions, I need one last clarification so I can tailor the test: What headset are you using for VR? A) Meta Quest (2, 3, Pro) B) Valve Index C) HP Reverb G2 D) Pimax E) Varjo F) Other (tell me) Example reply: C – HP Reverb G2 Your answer determines which drivers we focus on first. Je zei: e ChatGPT zei: Varjo — perfect, that gives us a very strong lead. Why this matters: Varjo headsets use: High-bandwidth USB A custom USB driver stack GPU SDK hooks Varjo Base background services These can easily cause high interrupt/DPC load if: USB controller isn’t ideal Varjo Base is misconfigured GPU driver conflicts exist A USB root hub is overloaded This now aligns extremely well with the symptoms you described: HVCI ON improving both FPS + frametimes System Interrupts ~1% at idle Using a Varjo headset (very sensitive to driver timing) So now the goal is: Identify the exact driver causing the excess interrupts so we can tune or move it. Once fixed, you can run HVCI OFF with equal or better perf. Before LatencyMon: 2 Quick Varjo-Specific Checks Please answer these yes/no before we run the full LatencyMon diagnosis — it will save time: 1. Is your Varjo headset plugged into the motherboard’s rear USB ports? 2. Does your motherboard have a USB-C port, and if so, are you using it? 3. Do you use any USB hubs, front panel USB, or extensions for the headset cable? 4. Do you have Asus Armoury Crate, MSI Center, or Gigabyte Control Center installed? 5. Do you have any audio device switching when your Varjo turns on (e.g., switching to Varjo speakers)? Example reply: 1. Yes 2. Yes 3. No 4. No 5. Yes Once I have your answers, I’ll give you the exact LatencyMon instructions tailored for Varjo to pinpoint the interrupt driver. Je zei: 1 yes 2 yes 3 yes 4no 5no ChatGPT zei: Thanks — your answers help narrow this down a lot. Here is what they tell us: Interpreting your answers Q Your Answer Meaning 1. Rear motherboard USB Yes Good — always preferred for VR 2. Using motherboard USB-C Yes Can be good or problematic depending on controller 3. Using hubs/front panel/extenders Yes Major suspect for interrupts & DPC spikes 4. Armoury/MSI/Gigabyte utilities No Good — removes a common source of latency 5. Audio switching No Good — reduces audio stack DPC load #3 (USB hub/extension) is almost certainly contributing to your higher interrupt load. Varjo headsets are extremely sensitive to USB routing, and extensions/hubs can cause driver spam at kernel level. But before changing anything physically, we should measure which driver is at fault. Next Step: LatencyMon (Tailored for Varjo) This test will: Identify whether USB, network, audio, NVMe, or GPU driver is causing the interrupt load Confirm if your USB controller is the root cause (likely) Tell us if you can safely disable HVCI without losing performance I will now send you: Latencymon Test Instructions for Varjo Users Before I paste the instructions, I need one last detail so I tailor the run: When testing LatencyMon, do you want to test: A) Idle test first (2 minutes, headset connected but not in VR) B) VR Load test (5 minutes in a simple VR app or steamVR home) C) Both idle + VR (recommended) Key Finding From Test 1 (Idle) wdf01000.sys being the highest in ISR + DPC confirms: The performance issue is caused by a driver that uses the Windows Driver Framework (WDF) — not the framework itself. wdf01000.sys is not the bad driver — it's the Windows kernel framework that other drivers plug into. When another driver misbehaves, wdf01000.sys becomes the “messenger” and takes the blame in LatencyMon. What this means: A USB, HID, or device driver is repeatedly generating interrupts WDF receives and processes them, so it surfaces at the top This aligns with your setup: Varjo VR headset USB-C + hub/extension used System Interrupts at 1% idle This is classic USB interrupt flood behavior. Here’s what your Top 3 reveal: Rank Driver Meaning #1 wdf01000.sys Windows Driver Framework A device driver using WDF is spamming interrupts #2 dxgkrnl.sys DirectX Graphics Kernel GPU scheduling overhead + ISR/DPC load #3 nvlddmkm.sys NVIDIA GPU Driver GPU driver DPC contribution Interpretation This combination is extremely typical in VR with a USB VR headset: A USB/WDF device driver is spamming interrupts → causes wdf01000.sys to spike GPU kernel & driver are picking up the load, trying to keep the VR compositor fed → dxgkrnl.sys + nvlddmkm.sys rise to compensate So this is not a pure GPU problem. The GPU is reacting to a USB/WDF driver problem. This fits exactly with what we suspected earlier: HVCI helps because it sandboxes the misbehaving driver, reducing interrupt flood — so VR feels smoother despite virtualization overhead. In other words: HVCI is masking the problem — not solving it. If we fix the USB driver issue, you will gain: Higher FPS without HVCI Better frametime stability than now No virtualization overhead now that we have both Idle and VR load results, the pattern is very clear. To confirm, let me restate: The first screenshot you sent was VR ON The second screenshot you just sent is VR OFF (idle) Correct? Because the numbers line up like this: VR ON (first screenshot) wdf01000.sys: 0.145 ms, ~693k DPC dxgkrnl.sys + nvlddmkm.sys elevated VB-Audio + Topping + ndis contributing VR OFF (second screenshot) wdf01000.sys drops to 0.064 ms, DPC ~132k GPU drivers still active, but less stressed USB audio still present but lower impact This confirms the root cause spikes under VR load, meaning: The USB/audio driver stack is bottlenecking the kernel under VR conditions. What This Tells Us 1. The WDF-based driver problem gets 5× worse in VR wdf01000.sys DPC count went from 132k → 693k under VR load. That’s a dramatic increase — exactly what causes microstutters & frametime spikes. 2. The GPU is not the cause — it is reacting to the USB stack overload dxgkrnl & nvlddmkm rising under VR simply confirms they are compensating for the driver pressure. 3. Two USB Audio drivers are the most likely trigger Both appear in top 12 during VR: vb audio_cablea64_win7.sys (VB-Audio Virtual Cable) ToppingUsbAudio.sys (Topping USB DAC driver) Two kernel-level audio routing drivers + Varjo + USB hub/extension = interrupt storm This is a known bad combination for VR. Root Cause Summary The USB audio driver stack (especially Topping + VB-Audio) is overloading the Windows Driver Framework under VR, causing interrupt storms that HVCI is masking. So, the goal is to: Reduce/eliminate USB audio DPC load Ensure Varjo USB connection is as direct as possible THEN safely disable HVCI for full performance Good News You can keep both VB-Audio + Topping DAC and still eliminate the DPC spikes, without needing HVCI — if we adjust the audio & USB routing. The problem is not that you have these drivers. The problem is the way Windows is handling their priority and USB routing while VR is active. We will fix this in 3 layers: Fix Plan for Your Case (Keeps Both Drivers) Phase 1 — Audio Stack Optimization (No removal) Goal: reduce ISR/DPC storm from VB-Audio + Topping Phase 2 — USB Routing Tuning for Varjo Goal: remove USB interrupt bottleneck under VR load Phase 3 — Disable HVCI (only when ready) Goal: unlock peak performance without losing smoothness We can significantly reduce DPC/ISR load by adjusting: VB-Audio buffer settings Topping USB mode & driver priority USB port routing for Varjo vs Audio Windows audio engine mode This will remove the interrupt storm, so you no longer need HVCI to hide it. PHASE 1 — Fix the Audio Stack (Keep VB-Audio + Topping) Step 1: Increase VB-Audio Cable Buffer (Reduces DPC Spikes) Open VB-Audio Control Panel Set the buffer to 512 or 1024 samples (not 128/256) Set Sample Rate = 48 kHz (matches DCS/Windows/Varjo best) Low buffer = more real-time → more interrupts Medium buffer = FAR lower DPC load with no audible downside in DCS Expected improvement: 30–40% reduction in DPC load Step 2: Switch Topping DAC to WASAPI Exclusive Mode for DCS This prevents Windows from converting formats & resampling constantly. In DCS Audio Settings: Output Device: Topping DAC (WASAPI Exclusive) In Windows Sound Settings → Device Properties → Advanced: Set 24-bit 48 kHz Uncheck: “Allow applications to take exclusive control of this device” (DCS will control it exclusively in WASAPI anyway) Expected improvement: ~20% fewer DPC calls from audio engine Step 3: Optional – Prioritize DCS Audio Thread (only if needed) If after Phase 2 the issue persists, I’ll give you a Process Lasso rule to isolate the audio thread to E-cores or limit context switching. VB-Audio Optimal Settings for DCS + Varjo (Low DPC Mode) 1. Internal Sampling Rate Set to: 48000 Hz Why: 48 kHz is the native rate for DCS, Windows system audio, Varjo, and most voice comms — avoids resampling overhead. 2. Max Latency Currently you have many options from 512 → 32768 smp. Most users pick too low and cause DPC spikes. Recommended starting point: 2048 smp (requires reboot) If you want an even safer value (less DPC load), choose: 3072 smp or 4096 smp (if system is still sensitive) 3. Current Latency This is the active buffer multiplier. Set to: 3× 512 smp (or 3× 768 smp if needed) If using Max Latency 2048, a 3× Current Latency of 512 or 768 smp gives a stable buffer without noticeable delay. Recommended full configuration: Setting Value Internal Sampling Rate 48000 Hz Max Latency 2048 smp Current Latency 3× 512 smp After setting Max Latency, VB-Audio requires a reboot for it to take effect. This is excellent progress — the VB-Audio tuning clearly worked. Let’s compare your before vs after (idle): Metric Before After VB-Audio tuning Improvement wdf01000.sys highest execution 0.145 ms 0.086 ms ~41% less wdf01000.sys DPC count ~174k vs 693k VR 174k idle Same idle value (expected) vb audio_cable execution 0.034 ms 0.013 ms ~62% less ToppingUsbAudio execution 0.0052 ms 0.0098 ms Slight increase (normal after reboot) dxgkrnl.sys 0.095 ms 0.090 ms Slightly lower Interpretation of Improvements VB-Audio latency optimization reduced its DPC footprint massively wdf01000.sys execution time dropped significantly GPU kernel DPC load improved slightly Topping DAC load raised slightly at idle (acceptable & expected after reset) This means Phase 1 (Audio Stack Fix) is successful. You now have: Lower DPC load Lower interrupt overhead Much healthier idle latency Next Step: Validate Under VR Load Before continuing to Phase 2 (USB routing), let's do a quick 3-minute VR test with the new audio settings to observe the new behavior. Please repeat the VR test: Mini VR Test (shorter than last time) Start LatencyMon Start VR (Varjo Base environment is fine) Run for 3 minutes Stop and share ONLY the top 10 drivers screenshot like you did before This will tell us: How much the VR DPC storm was reduced Whether USB or GPU now dominates If additional audio tuning is needed before moving to USB VR TEST RESULTS ANALYSIS — AFTER VB-Audio Tuning This is a very positive improvement versus your first VR test. Let’s compare the key metrics before vs after (VR ON): Metric (VR ON) Before After VB-Audio tuning Improvement wdf01000.sys highest exec 0.145 ms 0.079 ms ~45% lower wdf01000.sys DPC count 693,471 1,330,396 More load, but handled better nvlddmkm.sys highest exec 0.075 ms 0.125 ms Slight increase (explained below) VB-Audio exec 0.034 ms 0.006 ms 82% lower Topping exec 0.0052 ms 0.0021 ms 60% lower dxgkrnl.sys exec ~0.095 ms 0.095 ms Same (expected) Interpretation 1. VB-Audio optimization worked extremely well Its DPC impact dropped from 0.034 → 0.006 ms This is a huge improvement. 2. Topping USB audio driver now behaves correctly Its highest execution time more than halved. This means your audio stack is no longer the main problem. 3. wdf01000.sys DPC count increased, but is processed ~2× faster This suggests: The driver still generates interrupts, but the system handles them more efficiently now This is good — higher DPC count but lower latency = cleaner processing. 4. nvlddmkm.sys increased slightly (0.075 → 0.125 ms) This can happen when USB pressure is relieved — GPU driver takes more scheduling role again. This is not a concern yet and should improve after the USB routing fix. Summary So Far After Phase 1 (Audio optimization): Audio drivers are no longer causing latency Interrupt handling is much more efficient VR performance should already feel smoother You removed about 30–50% of the original DPC problem Next bottleneck to fix: USB routing for Varjo + DAC + extension/hub Because the audio drivers are now “clean”, the next DPC reduction will come from USB topology.

Process Lasso Currently Enabling/Disabling Process Lasso Governor makes very little difference. I have excluded DCS from its control, so am only using it to silence other applications and services. null Still to tests With the reinstall and adjusted settings my baseline looks pretty okay at a stable 90 fps while being parked at Marianas. After I have adjusted graphics settings still some things to try: Enable/Disable Hypervisor (disabling the Hypervisor should bring more frametime stability. (no idea if it will help). Adjusting RTSS Frametime limiter 89-90-91 (using RTSS should be a bit more stable than DCS's fps limiter, if I understand correctly)

Canopy Reflections I used to use Taz's Clearglass mod to reduce the reflections, which gave me back around 2.5 FPS. Can't run this mod on the server, but luckily @Kbu (thanks!!) mentioned that DCS has this option now in-game, so I tried it. Will have to change some other visual settings to reduce some fps and see the difference more clearly between ON/OFF, the difference currently looks negligible. null

Removing Envelope There are two types of envelope icons in DCS: Envelope Type Source Removal Method Mission message envelope Mission “MESSAGE TO …” triggers disable_messages etc. Multiplayer chat envelope MP chat notifications / message log Must disable chat notifications You still want the restart warnings (mission messages), so we only remove the chat envelope. Remove the Multiplayer Chat Envelope (keep mission/server messages) Try this first: Step 1 – In-game setting Go to Options → Gameplay Disable / uncheck: “Allow Multiplayer Chat” Apply and restart DCS. This removes chat pop-ups and the envelope icon, but you can still see mission messages. If you still want to be able to open chat manually but don’t want pop-ups, use Step 2 instead. Step 2 – Hide Chat Notifications but Keep Chat Available Add this to your autoexec.cfg: chat_window_use_history = false chat_window_show_status = false This stops DCS from showing the envelope or “new chat message” alert. You can still press TAB to open chat when you want it. Step 3 – Fully remove chat but keep mission/server messages If your server sends restart warnings through mission triggers (not chat), use this: disable_multiplayer_chat = true Only use if restart messages come from mission messages, not chat — otherwise you’ll lose them. Quick test to confirm which envelope it is: When the envelope appears, press TAB: If chat opens → It’s the MP chat envelope If nothing opens → It’s the Mission message envelope

These I had in the autoexec.cfg: DLSS_Preset = "K" HUD_MFD_after_DLSS = true