M8H storport.sys causing high latency

[Jagdseelen]

Using Latency Mon I have discovered the storport.sys is causing high latency.

storport.sys 2.008436

Does anyone have a solution for this?

Latency Mon Stats

CONCLUSION
_________________________________________________________________________________________________________
Your system appears to be having trouble handling real-time audio and other tasks. You are likely to experience buffer underruns appearing as drop outs, clicks or pops. 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:00:50 (h:mm:ss) on all processors.


_________________________________________________________________________________________________________
SYSTEM INFORMATION
_________________________________________________________________________________________________________
Computer name: DAD
OS version: Windows 10 , 10.0, build: 14393 (x64)
Hardware: ASUSTeK COMPUTER INC., MAXIMUS VIII HERO
CPU: GenuineIntel Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz
Logical processors: 8
Processor groups: 1
RAM: 14550 MB total


_________________________________________________________________________________________________________
CPU SPEED
_________________________________________________________________________________________________________
Reported CPU speed: 4008 MHz
Measured CPU speed: 1 MHz (approx.)

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.

WARNING: the CPU speed that was measured is only a fraction of the CPU speed reported. Your CPUs may be throttled back due to variable speed settings and thermal issues. It is suggested that you run a utility which reports your actual CPU frequency and temperature.



_________________________________________________________________________________________________________
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): 2016.833689
Average measured interrupt to process latency (µs): 7.638099

Highest measured interrupt to DPC latency (µs): 2008.402537
Average measured interrupt to DPC latency (µs): 1.953614


_________________________________________________________________________________________________________
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): 122.871008
Driver with highest ISR routine execution time: dxgkrnl.sys - DirectX Graphics Kernel, Microsoft Corporation

Highest reported total ISR routine time (%): 0.054327
Driver with highest ISR total time: dxgkrnl.sys - DirectX Graphics Kernel, Microsoft Corporation

Total time spent in ISRs (%) 0.067326

ISR count (execution time <250 µs): 39040
ISR count (execution time 250-500 µs): 0
ISR count (execution time 500-999 µs): 0
ISR count (execution time 1000-1999 µs): 0
ISR count (execution time 2000-3999 µ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): 2010.878992
Driver with highest DPC routine execution time: storport.sys - Microsoft Storage Port Driver, Microsoft Corporation

Highest reported total DPC routine time (%): 0.072034
Driver with highest DPC total execution time: ndis.sys - Network Driver Interface Specification (NDIS), Microsoft Corporation

Total time spent in DPCs (%) 0.158325

DPC count (execution time <250 µs): 129552
DPC count (execution time 250-500 µs): 0
DPC count (execution time 500-999 µs): 0
DPC count (execution time 1000-1999 µs): 0
DPC count (execution time 2000-3999 µs): 13
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.


Process with highest pagefault count: corsairlink4.service.exe

Total number of hard pagefaults 155
Hard pagefault count of hardest hit process: 95
Highest hard pagefault resolution time (µs): 154.975050
Total time spent in hard pagefaults (%): 0.001511
Number of processes hit: 2


_________________________________________________________________________________________________________
PER CPU DATA
_________________________________________________________________________________________________________
CPU 0 Interrupt cycle time (s): 1.010277
CPU 0 ISR highest execution time (µs): 122.871008
CPU 0 ISR total execution time (s): 0.266399
CPU 0 ISR count: 38555
CPU 0 DPC highest execution time (µs): 2010.878992
CPU 0 DPC total execution time (s): 0.600039
CPU 0 DPC count: 115575
_________________________________________________________________________________________________________
CPU 1 Interrupt cycle time (s): 0.054558
CPU 1 ISR highest execution time (µs): 58.205339
CPU 1 ISR total execution time (s): 0.003579
CPU 1 ISR count: 485
CPU 1 DPC highest execution time (µs): 180.887226
CPU 1 DPC total execution time (s): 0.009071
CPU 1 DPC count: 2546
_________________________________________________________________________________________________________
CPU 2 Interrupt cycle time (s): 0.112751
CPU 2 ISR highest execution time (µs): 0.0
CPU 2 ISR total execution time (s): 0.0
CPU 2 ISR count: 0
CPU 2 DPC highest execution time (µs): 39.273204
CPU 2 DPC total execution time (s): 0.005683
CPU 2 DPC count: 2739
_________________________________________________________________________________________________________
CPU 3 Interrupt cycle time (s): 0.043708
CPU 3 ISR highest execution time (µs): 0.0
CPU 3 ISR total execution time (s): 0.0
CPU 3 ISR count: 0
CPU 3 DPC highest execution time (µs): 47.145459
CPU 3 DPC total execution time (s): 0.005142
CPU 3 DPC count: 2174
_________________________________________________________________________________________________________
CPU 4 Interrupt cycle time (s): 0.104963
CPU 4 ISR highest execution time (µs): 0.0
CPU 4 ISR total execution time (s): 0.0
CPU 4 ISR count: 0
CPU 4 DPC highest execution time (µs): 48.146956
CPU 4 DPC total execution time (s): 0.004219
CPU 4 DPC count: 1846
_________________________________________________________________________________________________________
CPU 5 Interrupt cycle time (s): 0.046343
CPU 5 ISR highest execution time (µs): 0.0
CPU 5 ISR total execution time (s): 0.0
CPU 5 ISR count: 0
CPU 5 DPC highest execution time (µs): 23.913174
CPU 5 DPC total execution time (s): 0.002627
CPU 5 DPC count: 1272
_________________________________________________________________________________________________________
CPU 6 Interrupt cycle time (s): 0.051691
CPU 6 ISR highest execution time (µs): 0.0
CPU 6 ISR total execution time (s): 0.0
CPU 6 ISR count: 0
CPU 6 DPC highest execution time (µs): 35.120509
CPU 6 DPC total execution time (s): 0.003891
CPU 6 DPC count: 1785
_________________________________________________________________________________________________________
CPU 7 Interrupt cycle time (s): 0.139418
CPU 7 ISR highest execution time (µs): 0.0
CPU 7 ISR total execution time (s): 0.0
CPU 7 ISR count: 0
CPU 7 DPC highest execution time (µs): 47.384731
CPU 7 DPC total execution time (s): 0.004212
CPU 7 DPC count: 1628
_________________________________________________________________________________________________________

[andrelau]

Hi.
After reinstalling w10 on my Maximus IX hero, Latencymon reported pb with storport.sys

I unsinstalled Intel ME and everything's fine now ! (it was failing after 3 or 4 min before)

[Llewen]

I wanted to add this to this thread, in case anyone else has the same questions and issues, specifically with the storport.sys driver. Everytime I've run LatencyMon it has shown extremely high interrupt to process latency with storport.sys being the culprit. Finally a few days ago I decided to try and get to the bottom of it. I did a ton of reading, I tried rolling back my RAID drivers and had to recover from Windows failing to boot in the process. I tried everything I could think of, from disabling services and shutting down processes to disabling power saving features and tweaking my bios.

After a couple of days of this, today I ran an xperf trace. It told me everything was peachy. No sign of abnormal latencies, or any other issues. I run two sets of identical ssd's in raid 0, and I read up on that, and from what I read, raid 0 does not cause latency issues.

Now I had already noted that when I am running LatencyMon, it leads the charts in disc reads. So I checked system explorer (yes I did try turning that off as well), and to my surprise the default setting for LatencyMon is realtime priority, on the middle four of my eight cores. Those just happen to be the four cores I run all my high priority system processes on. The little light started flickering on. I ran another xperf trace, this time longer, and what I had done was use YouTube videos, because when I was running LatencyMon, I was getting the huge latency spikes in YouTube videos, along with the occasional drop.

Again, the xperf trace showed no problems, and more importantly, I had 0 drops. So I ran LatencyMon again, only this time I assigned affinity to the cores I typically use for monitoring software, and I dropped the priority from realtime to high. Bingo, the storport.sys latencies dropped significantly.

So for anyone running LatencyMon and getting abnormally high interrupt to process latencies where storport.sys is the culprit. There is a very good chance that LatencyMon itself is what is causing the problem.

I don't regret the time I spent on this. I learned a ton, and I my Xonar Essence STX along with it's driver was causing some serious dpc latency issues, and as a result I've got my audio configured so my latencies are significantly lower and I am getting better performance in games, which was the entire point in the first place, but the most valuable lesson I learned was that sometimes monitoring software itself can cause abnormal readings. I kinda already knew that, but this experience drove that point home.