My New System Configuration:

OMARK · ‎03-05-2025

Premise, I rebuilt the new pc a month ago and for a month while waiting for the new cards I continued to use my old Gigabyte GTX 970 on the new pc and everything was going perfectly.

My New System Configuration:

CPU: AMD Ryzen 9800X3D
RAM: CORSAIR VENGEANCE DDR5 32GB (2x16GB) 6000MHz CL30 EXPO
SSD: Samsung 990 Pro 2TB (M.2)
PSU: Corsair RM850x (2024)
Motherboard: ROG STRIX B850-A GAMING WIFI (Firmware 0825)
WIn 11 24H2

One week ago my MSI RTX 5070 Ti Ventus 3x OC arrived.
The GPU is correctly recognized by the system, and GPU-Z shows no apparent issues.
PCIE 5, all rops ecc...

However, I am experiencing strange micro stuttering/frametime issues while navigating in Windows 11
Windows UI exhibits micro-stuttering and like some sort of inconsistent frametime.
This is especially noticeable when scrolling through browsers (Firefox, Chrome, Edge).

Important note: The mouse cursor remains perfectly smooth, and CPU/GPU usage is normal.
Windows itself is not slow; apps open quickly, and everything responds well.

Tests Performed:

Driver and Installation Tests:
- Used DDU to completely uninstall and reinstall GPU drivers, but the problem persists.
Other Tests:
- Disabled and re-enabled Resizable BAR, G-Sync, VRR, and GPU hardware acceleration, but no improvement.
- I tried various settings from the control panel between vertical synchronization, low latency mode, etc...
- My motherboard supports PCIe Gen 5, so I manually forced PCIe Gen 5, 4, and 3 instead of "Auto," but this had no effect.
- Tried resetting the bios settings and disabling the expo profile.
Benchmarks & Gaming Tests:
- The GPU performs normally under high load in games and benchmarks.
- Cyberpunk 2077 (max settings), 3DMark Time Spy, Port Royal, Speedway stress test—no crashes, no FPS drops, everything runs smoothly, temperatures are fine.

I tried powering the video card with both the new 12V-2X6 cable included with the Corsair RM850x power supply (2024) and the adapter included in the MSI package. No difference.

I am struggling to determine whether this is a driver issue, some kind of incompatibility, Motherboard BIOS not handling it properly, driver chipset or something else entirely.

After days I've noticed something interesting in GPU-Z.

On my RTX 5070 Ti, the "Bus Interface Load" sensor is constantly active. Even when I'm doing nothing on the PC, it stays at 20%, and if I open monitoring programs like HWInfo or Task Manager, it jumps between 20% and 40%.
At the same time, "PerfCap Reason" is constantly showing Power and VRel.

To make a comparison, on my OLD GTX 970 "Bus Interface Load" stays at 0%, whether idle or when opening monitoring programs.
Additionally, "PerfCap Reason" remains in the Idle state.

I'm sure that's why on 5070 it takes only a little load and the navigability in windows is no longer very smooth.

Why is this happening? Could it be a driver/bios problem that mismanages the PCIe bus?

I noticed the following changes after setting "Prefer Maximum Performance" in the NVIDIA power management settings:
- The Bus Interface Load dropped from 20-40% (with monitoring programs running) to 1% when idle and 1-5% when opening programs like HWInfo and Task Manager.

- The PerfCap Reason, which was previously at 90% in PWR and 10% in vrel, is now at 100% in vrel.

- This way, the microstuttering is resolved or improves by 99%, even with various monitoring programs open, but the power consumption increases."

On my ASUS ROG Strix B850-A motherboard GPU-Z correctly detects my GPU as "PCIe x16 5.0".
I've already tried forcing PCIe 4.0 and 3.0 from the BIOS, but the issue remains the same.

My motherboard's BIOS version is 0825, which dates back to mid-December 2024.
Just six days ago, a new stable version (1006) was released after two months in beta.

I'm considering whether to try updating or not to see if anything changes, but I'm always a bit hesitant when it comes to BIOS updates.

I wanted to wait first to see if a new GPU driver or at least the new AMD chipset driver for the B850 series would be released.

On AMD's website, there is a new chipset driver from February 25 (7.02.13.148), but it is available for all motherboards except the B850 series, which is still not listed at all.

I don't know if this is just an error due to the B850 series being relatively new, having been on the market for only 45 days.
Some say that the driver is the same for all AM5 chipsets, but I don’t want to take any risks and prefer to wait until it is officially listed on ASUS's website.

I preferred to try that first before risking a BIOS update, which always gives me five minutes of pure terror, hoping everything goes smoothly.

Any opinion from Asus on whether my issue could be related to the motherboard BIOS and chipset?
Just to clarify, my graphics card doesn’t seem to have any performance issues, but there’s something odd in the way the PCIe bus is being managed.

BabyWakanda · ‎03-05-2025

Hey @OMARK, looks like I'm having the same issues, and I suspect it to be some kind of incompatibility between the new RTX 5070 Ti and the BIOS or chipset. I'd try upgrading to BIOS 1006 or else waiting for a chipset official driver update for the B850 series, and it might solve the PCIe bus management issue because the workaround here called "Prefer Maximum Performance"-doesn't cut it for a long-term solution.

OMARK · ‎03-05-2025

Hi, yeah I’ve also read about a few others experiencing similar issues. I wanted to keep the BIOS update as a last resort or, since these GPUs just launched, at least wait for the next update to increase the chances that ASUS identifies and fixes any potential software issues related to PCIe bus management in idle.

I was hoping to try at least another GPU driver update or an AMD chipset driver before resorting to a BIOS update.

Let’s make sure to keep each other informed if anyone discovers the cause and a possible solution.

Silent_Scone · ‎03-05-2025

Hi @OMARK

I've seen a few reports of high DCP latency on AMD on 5000 series GPUs. I would check this with Latencymon to see if it's the same issue.

9800X3D / 6400 CAS 28 / ROG X870 Crosshair / TUF RTX 4090

OMARK · ‎03-05-2025

Hi, i've run the test with LatencyMon.

Here are the results after six minutes with both "Normal" and "Prefer Maximum Performance" settings in the NVIDIA power management options.

What can be inferred from these results?

Nvidia power management: Normal
Full Stats

CONCLUSION
_________________________________________________________________________________________________________
Your system seems to be having difficulty handling real-time audio and other tasks. You may experience drop outs, clicks or pops due to buffer underruns. One or more DPC routines that belong to a driver running in your system appear to be executing for
too long. One problem may be related to power management, disable CPU throttling settings in Control Panel and BIOS setup. Check for BIOS updates.
LatencyMon has been analyzing your system for 0:06:39 (h:mm:ss) on all processors.

_________________________________________________________________________________________________________
SYSTEM INFORMATION
_________________________________________________________________________________________________________

OS version: Windows 11, 10.0, version 2009, build: 26100 (x64)
Hardware: System Product Name, ASUS
BIOS: 0825
CPU: AuthenticAMD AMD Ryzen 7 9800X3D 8-Core Processor
Logical processors: 16
Processor groups: 1
Processor group size: 16
RAM: 32419 MB total

_________________________________________________________________________________________________________
CPU SPEED
_________________________________________________________________________________________________________
Reported CPU speed (WMI): 470 MHz
Reported CPU speed (registry): 470 MHz

Note: reported execution times may be calculated based on a fixed reported CPU speed. Disable variable speed settings like Intel Speed Step and AMD Cool N Quiet in the BIOS setup for more accurate results.

_________________________________________________________________________________________________________
MEASURED INTERRUPT TO USER PROCESS LATENCIES
_________________________________________________________________________________________________________
The interrupt to process latency reflects the measured interval that a usermode process needed to respond to a hardware request from the moment the interrupt service routine started execution. This includes the scheduling and execution of a DPC routine,
the signaling of an event and the waking up of a usermode thread from an idle wait state in response to that event.

Highest measured interrupt to process latency (µs): 735,40
Average measured interrupt to process latency (µs): 21,716158

Highest measured interrupt to DPC latency (µs): 483,90
Average measured interrupt to DPC latency (µs): 8,251599

_________________________________________________________________________________________________________
REPORTED ISRs
_________________________________________________________________________________________________________
Interrupt service routines are routines installed by the OS and device drivers that execute in response to a hardware interrupt signal.

Highest ISR routine execution time (µs): 24,630
Driver with highest ISR routine execution time: Wdf01000.sys - Runtime framework driver modalità kernel, Microsoft Corporation

Highest reported total ISR routine time (%): 0,000077
Driver with highest ISR total time: Wdf01000.sys - Runtime framework driver modalità kernel, Microsoft Corporation

Total time spent in ISRs (%) 0,000077

ISR count (execution time <250 µs): 9224
ISR count (execution time 250-500 µs): 0
ISR count (execution time 500-1000 µs): 0
ISR count (execution time 1000-2000 µs): 0
ISR count (execution time 2000-4000 µs): 0
ISR count (execution time >=4000 µs): 0

_________________________________________________________________________________________________________
REPORTED DPCs
_________________________________________________________________________________________________________
DPC routines are part of the interrupt servicing dispatch mechanism and disable the possibility for a process to utilize the CPU while it is interrupted until the DPC has finished execution.

Highest DPC routine execution time (µs): 1817,490
Driver with highest DPC routine execution time: ntoskrnl.exe - NT Kernel & System, Microsoft Corporation

Highest reported total DPC routine time (%): 0,101966
Driver with highest DPC total execution time: nvlddmkm.sys - NVIDIA Windows Kernel Mode Driver, Version 572.65 , NVIDIA Corporation

Total time spent in DPCs (%) 0,122814

DPC count (execution time <250 µs): 416711
DPC count (execution time 250-500 µs): 0
DPC count (execution time 500-10000 µs): 4732
DPC count (execution time 1000-2000 µs): 136
DPC count (execution time 2000-4000 µs): 0
DPC count (execution time >=4000 µs): 0

_________________________________________________________________________________________________________
REPORTED HARD PAGEFAULTS
_________________________________________________________________________________________________________
Hard pagefaults are events that get triggered by making use of virtual memory that is not resident in RAM but backed by a memory mapped file on disk. The process of resolving the hard pagefault requires reading in the memory from disk while the process
is interrupted and blocked from execution.

NOTE: some processes were hit by hard pagefaults. If these were programs producing audio, they are likely to interrupt the audio stream resulting in dropouts, clicks and pops. Check the Processes tab to see which programs were hit.

Process with highest pagefault count: msmpeng.exe

Total number of hard pagefaults 769
Hard pagefault count of hardest hit process: 494
Number of processes hit: 6

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

Nvidia power management: Prefer Maximum Performance

Full Stats

CONCLUSION
_________________________________________________________________________________________________________
Your system appears to be suitable for handling real-time audio and other tasks without dropouts.
LatencyMon has been analyzing your system for 0:06:39 (h:mm:ss) on all processors.
_________________________________________________________________________________________________________
SYSTEM INFORMATION
_________________________________________________________________________________________________________

OS version: Windows 11, 10.0, version 2009, build: 26100 (x64)
Hardware: System Product Name, ASUS
BIOS: 0825
CPU: AuthenticAMD AMD Ryzen 7 9800X3D 8-Core Processor
Logical processors: 16
Processor groups: 1
Processor group size: 16
RAM: 32419 MB total
_________________________________________________________________________________________________________
CPU SPEED
_________________________________________________________________________________________________________
Reported CPU speed (WMI): 470 MHz
Reported CPU speed (registry): 470 MHz

Note: reported execution times may be calculated based on a fixed reported CPU speed. Disable variable speed settings like Intel Speed Step and AMD Cool N Quiet in the BIOS setup for more accurate results.
_________________________________________________________________________________________________________
MEASURED INTERRUPT TO USER PROCESS LATENCIES
_________________________________________________________________________________________________________
The interrupt to process latency reflects the measured interval that a usermode process needed to respond to a hardware request from the moment the interrupt service routine started execution. This includes the scheduling and execution of a DPC routine, the signaling of an event and the waking up of a usermode thread from an idle wait state in response to that event.

Highest measured interrupt to process latency (µs): 281,30
Average measured interrupt to process latency (µs): 18,253461

Highest measured interrupt to DPC latency (µs): 271,30
Average measured interrupt to DPC latency (µs): 2,190818
_________________________________________________________________________________________________________
REPORTED ISRs
_________________________________________________________________________________________________________
Interrupt service routines are routines installed by the OS and device drivers that execute in response to a hardware interrupt signal.

Highest ISR routine execution time (µs): 8,360
Driver with highest ISR routine execution time: Wdf01000.sys - Runtime framework driver modalità kernel, Microsoft Corporation

Highest reported total ISR routine time (%): 0,000025
Driver with highest ISR total time: Wdf01000.sys - Runtime framework driver modalità kernel, Microsoft Corporation

Total time spent in ISRs (%) 0,000025

ISR count (execution time <250 µs): 2247
ISR count (execution time 250-500 µs): 0
ISR count (execution time 500-1000 µs): 0
ISR count (execution time 1000-2000 µs): 0
ISR count (execution time 2000-4000 µs): 0
ISR count (execution time >=4000 µs): 0
_________________________________________________________________________________________________________
REPORTED DPCs
_________________________________________________________________________________________________________
DPC routines are part of the interrupt servicing dispatch mechanism and disable the possibility for a process to utilize the CPU while it is interrupted until the DPC has finished execution.

Highest DPC routine execution time (µs): 818,030
Driver with highest DPC routine execution time: dxgkrnl.sys - DirectX Graphics Kernel, Microsoft Corporation

Highest reported total DPC routine time (%): 0,025099
Driver with highest DPC total execution time: nvlddmkm.sys - NVIDIA Windows Kernel Mode Driver, Version 572.65 , NVIDIA Corporation

Total time spent in DPCs (%) 0,037513

DPC count (execution time <250 µs): 212310
DPC count (execution time 250-500 µs): 0
DPC count (execution time 500-10000 µs): 10
DPC count (execution time 1000-2000 µs): 0
DPC count (execution time 2000-4000 µs): 0
DPC count (execution time >=4000 µs): 0
_________________________________________________________________________________________________________
REPORTED HARD PAGEFAULTS
_________________________________________________________________________________________________________
Hard pagefaults are events that get triggered by making use of virtual memory that is not resident in RAM but backed by a memory mapped file on disk. The process of resolving the hard pagefault requires reading in the memory from disk while the process is interrupted and blocked from execution.

NOTE: some processes were hit by hard pagefaults. If these were programs producing audio, they are likely to interrupt the audio stream resulting in dropouts, clicks and pops. Check the Processes tab to see which programs were hit.

Process with highest pagefault count: systemsettings.exe

Total number of hard pagefaults 2256
Hard pagefault count of hardest hit process: 848
Number of processes hit: 36

OMARK · ‎03-05-2025

Hi, 15 minutes ago I had posted the LatencyMon results, but they got deleted? Why? What should I do then?

I'll try again:

I've run the test with LatencyMon.

Here are the results with both "Normal" and "Prefer Maximum Performance" settings in the NVIDIA power management options.

What can be inferred from these results?

NVIDIA power management: Normal