M17x-DPC/ISR tracing

Since I (recently) swapped from NVidia to ATI cards, I wanted to check if there are any remaining issues concerning the DPC latency with the ATI GPUs. The following step by step guide can not only be applied to either M17x R1 or R2 but also to other laptops or desktops as well.

Background information: Why drop-outs occur
Processing of streaming data in real-time is a very challenging task for Windows based applications and device drivers. This is because by design Windows is not a real-time operating system. There is no guarantee that certain (periodic) actions can be executed in a timely manner.
Audio or video data streams transferred from or to an external device are typically handled by a kernel-mode device driver. Data processing in such device drivers is interrupt-driven. Typically, the external hardware periodically issues interrupts to request the driver to transfer the next block of data. In Windows NT based systems (Windows 2000 and better) there is a specific interrupt handling mechanism. A device driver cannot process data immediately in its interrupt routine. It has to schedule a Deferred Procedure Call (DPC) which basically is a callback routine that will be called by the operating system as soon as possible. Any data transfer performed by the device driver takes place in the context of this callback routine, named DPC for short.
The operating system maintains DPCs scheduled by device drivers in a queue. There is one DPC queue per CPU available in the system. At certain points the kernel checks the DPC queue and if no interrupt is to be processed and no DPC is currently running the first DPC will be un-queued and executed. DPC queue processing happens before the dispatcher selects a thread and assigns the CPU to it. So, a Deferred Procedure Call has a higher priority than any thread in the system.
Note that the Deferred Procedure Call concept exists in kernel mode only. Any user-mode code (Windows applications) runs in the context of a thread. Threads are managed and scheduled for execution by the dispatcher.
While there is a pre-emptive multitasking for threads, DPCs are executed sequentially according to the first in, first out nature of a DPC queue. Thus, a sort of cooperative multitasking scheme exists for Deferred Procedure Calls. If any DPC runs for an excessive amount of time then other DPCs will be delayed by that amount of time. Consequently, the latency of a particular DPC is defined as the sum of the execution time of all DPCs queued in front of that DPC. In order to achieve reasonable DPC latencies, in the Windows Device Driver Kit (DDK) documentation Microsoft recommends to return from a DPC routine as quick as possible. Any lengthy operation and specifically loops that wait for a hardware state change (polling) are strongly discouraged.
Unfortunately, many existing device drivers do not conform to this advice. Such drivers spend an excessive amount of time in their DPC routines, causing an exceptional large latency for any other driver’s DPCs. For a device driver that handles data streams in real-time it is crucial that a DPC scheduled from its interrupt routine is executed before the hardware issues the next interrupt. If the DPC is delayed and runs after the next interrupt occurred, typically a hardware buffer overrun occurs and the flow of data is interrupted. A drop-out occurs.
http://www.thesycon.de/dpclat/dpclat.pdf
(It's part of the documentation of Thesycon's DPC latency checker that I found recently, it's the program we all use to monitor the latency)


A few info from Microsoft:
For good system performance, a Windows kernel-mode driver should minimize the time it spends in its deferred procedure calls (DPCs) and interrupt service routines (ISRs).

A driver that spends too much time in its DPCs and ISRs prevents the system from servicing threads, which degrades overall system performance. A driver should spend no more than 25 microseconds in an ISR and no more than 100 microseconds in a DPC.

Tools to measure the latency:
Except from the DPC latency checker, you can measure the time that Windows kernel-mode drivers spend in DPCs and ISRs by using a new feature of Tracelog, a command-line tool provided with the Windows Driver Kit (WDK) that manages software tracing sessions. The DPC/ISR feature of Tracelog captures the activity of all drivers running in the kernel during the trace, even drivers that are not instrumented for tracing.


Step by Step Installation and Testing:

Step1
Download the ISO and burn it into a CD or mount it using DAEMON tools lite.
http://www.microsoft.com/downloads/...FamilyID=36a2630f-5d56-43b5-b996-7633f2ec14ff

Step2
Install the Tools (I installed it on my external USB Hard Disk. My advice is to install it on your C: drive because external devices introduce more latency to the system)


this is where I installed it


[you can skip Step 3 as well as the Pretesting and Testing Phase (only download the PDF file from the pretesting phase ) if you use the script(check at the end of the post )]

Step3
Open a command prompt as administrator
(Start-->Accessories-->Command Prompt-->right click-->run as Administrator)
Browse into the folder you have installed Tools

(for me the disk was E:\ so I type e: and enter. For you the disk letter probably will differ)


(this shows how to go to the folder with the tracelog.exe)

Pretest phase
Save this PDF file to your desktop, from here: http://developer.download.nvidia.com/presentations/2009/GDC/GDC09_PlatformIndepShaderDev.pdf

Open two instances of your web browser. Not two tabs but two different windows. (I use Mozilla Firefox, using any other browser may produce different results)
On the one window browse to: http://www.youtube.com/watch?v=p5HUlqXjvsU
Do not start any of the videos yet but have in mind to select 1080p when you are about to begin playback and then right click inside the video --> show video info
(IMPORTANT NOTE: I use the Adobe Flash Player 10.1 beta2 to support GPU acceleration for flash, it can be found here. Also note that it is still a beta version...)

on the other window browse to: http://www.youtube.com/watch?v=Ou6_MkIvKOo&NR=1&feature=fvwp
Same here, do not start the playback (don't right click on the video, it does not offer statistics)

If you want have an mp3 file ready to play with visualizations on (preferably).

Testing Phase
1)Open DPC latency checker to monitor the latency in real time
2)Start the mp3 playback to listen for audio stuttering.
3)On the already opened command prompt that we run as an administrator (see step 3) type:
tracelog -start -f test01.etl -dpcisr -UsePerfCounter -b 128
4)Now keep the two browsers side by side and press the button for them to start playback. (remember to select the 1080p and to scale them properly)
5)Open the PDF file and press CTRL-L (or View --> full screen mode) and start scrolling using your mouse's wheel UP and DOWN as fast as you can for about 20-30 seconds. (Do it as instructed, otherwise it will show on the analysis that CPU wasn't occupied enough by that procedure)
6)Exit fullscreen mode and check the DPC latency checker to see if you created any red spikes
but do not close the PDF file.
7)With the videos having stopped playing in the background (close the browsers), start the mp3 playback again, but this time without visualizations.
(This step is mostly intended for owners with the Nvidia GPUs rather than the ATIs)
8)open a new browser window and go here: http://forum.notebookreview.com/forumdisplay.php?f=1018
It always used to cause stutter and red spikes when I had the NVidia GPUs, because the graphics forced the GPU clocks to maximum frequencies.(Note: stuttering occurs after downclocking ,not during upclocking)
Start scrolling up and down or click to go to another link but remember to press back to come to the original page.After that click somewhere else on the desktop, outside the browser (very important) and wait for 15 seconds so that the GPU clocks will eventually downclock (those Nvidia owners that have problem should see a red spike 50K+ at the DPC latency checker and the audio to stutter).

9)Lastly press the eject button from the touch strip. There you will definitely see a big red spike that causes audio stuttering and I would rather say it is due to a driver but it is not the driver alone (see below on my report)

10)Now go back to the command prompt and type:
tracelog -stop (and press enter)
tracerpt test01.etl -report dpcisr.html -f HTML (and press enter)

In the same folder you will see the dpcisr.html
Double click it and review your results
Go to the bottom of the page and you will see something like an index. Use it to go directly to the DPC and ISR results

It would be grate if you posted your results in order to make comparisons (R1 and R2 owners)
Please attach a screenshot of the DPC latency checker too if possible.

Results:
Since many users that had their Nvidia cards replaced with ATIs complain about red spikes while browsing the Internet, scrolling PDF files, watching videos on Youtube and cause audio stuttering when they press the eject button from the touch strip, I tried to reproduce the red spikes by subjecting the machine into common but stressful at the same time tasks, while I was using tracelog to record the latency and the modules responsible for that latency. I was also monitoring at the same time the DPC latency checker in order to double check the results in real time.

The numbers presented here are in microseconds (1000μs == 1ms)
A detailed analysis can be found within the attached zip file.

DPC execution times
Module_____lower Bound - Upper Bound
----------------------------------------
dxgkrnl.sys______1000-2500
unknown________1000-2500 (I couldn't find what driver is that)
acpi.sys_________2500-5000


I personally do not experience any audio stuttering anymore, but, there are remaining "spikes" during PDF scrolling and browsing through pages with Flash. I want to present the facts as they are. I hope for Dell to take a look at this post too so they can give a solution to those who experience problems. Remember that Microsoft considers anything more than 100μs as a problem, even though I doubt any computer will be able to stay below this threshold under any kind of stress or use.


CAUTION
Keep in mind that tampering with the vbios on either ATI or NVidia cards is highly possible to result into video stuttering and should not be confused with the latency.
Revert back to default settings and then run the test.
External devices or 3rd party applications may introduce additional latency to the system.
Not all device drivers comply with Microsoft's recommendations

Those with ATI cards that suffer from stuttering during the test should remove all external devices and use the respawn partition or DVD that came with the laptop in order to
restore the system to its initial condition. Install all the updated drivers from the Dell website and run the test again with nothing else plugged in. Then submit the new data.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Side Notes by Microsoft:
Distribution of DriverName (ISRAddress) ISR to DriverName (DPCRoutineAddress) DPC latencies for the whole trace.
Displays the distribution of delay intervals between the end of an ISR and the beginning of the associated DPC

In general, DPC routines lasting more than 100 microseconds are discouraged.

example of M17x-R1 DPC latency while idle with ATI cards and A03 BIOS
(disabling the Microsoft ACPI-Compliant Control Method Battery will eliminate the 784μs spikes seen on the screenshot)
------------------------------------------------------------------------------------------------------------------

ADDITIONAL TOOLS FOR DEBUGGING AND MONITORING
Thanks to Dell-Bill_B
http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
Thanks to BatBoy
http://processhacker.sourceforge.net/

SCRIPT
You can use the script from the attachments below
dpc_script_v1.zip if you have WinDDK 7600.16385.0
dpc_script_v2.zip if you have WinDDK 7600.16385. 1

All you have to do is to install WinDDK (follow the STEP 1 and STEP 2), download the PDF file and run the script as administrator.

 

So we are basically exceeding the safety limits by 50 times (according to Microsoft)?!

 

According to the standards of Microsoft... yes
Basically if more people could post their results here it could provide solid data for Dell, no excuses for anyone after that.

 

I would but lost my W7 partition and absolutely don't have time to re-install it again.

 

Great info Stamatisx, thanks for posting!

 

Thank you Dellerious.

Later today or tomorrow I will write a step by step guide on how to install, run and generate the HTML report of the tracelog. I just realized that people are not that familiar with this procedure and making a step by step guide to follow will produce more accurate results.

One other thing I would really like to see is people with the M17x -R2 testing their machines for latency.

 

The step by step guide is updated with a few screenshots

 

+ rep

Thanks for breaking this down for us. Very impressive.

 

Thank you lewdvig, someone needed to make the procedure more transparent so the rest of us will have an idea about what is causing the stuttering

 

"Need to spread some reputation around before...."
My rep is on the way 2
Thanks again, m8!

 

No prob Aikimox, I have the same problem too
Glad to help and give it a shot whenever you can.

 

I'd help, but I am afraid of losing my problem free setup.

I am going to sit this out. But I wish you all the best, I would certainly prefer to be running Win7.

 

I understand your concern. What this program does though is to record in detail the latency of the drivers and it is as harmful as the DPC latency checker .

 

I have added the guide as a PDF file so you can have it without checking the thread all the time

 

I know, I just don't want to install Win7 again.

But if you think Vista readings will help I am happy to oblige.

 

Already mentioned via PM, but thanks again for working this up - I'll take a closer look tonight under Windows 7. This is an excellent resource tool for this issue (and many others). Nice job Stamatisx!

Also, for those interested in this side of the research, I mentioned a couple months ago in the DPC thread, a blog which Mark Russinovich maintains. He had an article titled " The Case of the Slooooow System" which caught my eye. A very interesting read. His articles not only help understand the workings of the OS but also can provide some ideas on troubleshooting steps and different methods which can be used. Check it out if you are interested in this type of stuff.

http://blogs.technet.com/markrussinovich/

 

It will definitely help since we will collect data from a wider range of OSes

 

I need to thank you for this Info BatBoy. Thanx

 

OK - I'll run the test tonight. My system seems superficially to be trouble free. Maybe we'll discover something new.

 

Your welcome sir! As I mentioned in my PM, the eject button is an interesting topic. I am on the fence with this one. I believe it should trigger a latency spike. It is in fact a hardware interrupt and as such should have some impact on the OS. Does the 70k+ spike it produces in Vista (sure W7 is roughtly the same) cause an audio interrupt to occur? Yes. Should the audio interrupt? I'm going to say no. So, its a bit of a catch 22 - while I can see it as normal, it also produces an abnormal behavior in the form of audio popping/stuttering.

So, the i8042prt.sys may be normal - its the side effect which I believe is not. Something else is at work here.

The dxgkrnl.sys is tied to Windows Desktop Manager.

 

Something else I wanted to mention is that you will never find a computer that is 100% free of software bugs. It is against the nature of programming. The only perfect code is the non existing code.
The only computer I found that has not kernel conflicts and latency is my pocket calculator and that's because it has no kernel or drivers.

We are the ones who define what we consider as a problem.
Microsoft set the threshold at 100μs for the driver's DPC state .
Others could set it even lower.
For me and the tasks I have to perform on this machine, latency as it is right now is not a problem since it does not affect my work any more.
Everybody is entitled to her/his opinion and will have to check for her/himself and see if the results satisfies her/his needs.

 

Sure, i'll test. Downloading the iso now...

Edit: Just finished downloading, I'll run the test tomorrow.

 

The i8042prt.sys as a driver is not the main reason for the kernel conflict. It is the same driver used by the mouse and the keyboard as well without causing any trouble. It is the way the controller from the touch strip that requests from this driver to eject the cd that causes the conflict within the kernel.
You can eject the CD by right clicking the DVD icon and "eject" using the mouse without any stuttering. The result is the same, what differs here is the procedure towards this result.

 

My results. Seems like this confirms that I have good luck atm.

 

Excellent observation. This also needs to be looked at by Dell. Although it is not the main issue, it certainly is a factor in this whole mess. IMO, it’s always best to squash them all rather than leave the little insignificant ones for a later day.

 

Indeed you have interesting results. I assume you pressed the eject button only once right? (at the ISR section there is a delay between 50.000 to 100.000 of the i8042prt.sys) and it did cause audio stuttering I guess. (tell me if I am wrong)
I also see that you had two spikes between 50.000 - 100.000 due to nvlddmkm.sys and my mind goes to the powermizer issue of Nvidia but according to what I read from other forums it could be triggered by other drivers or devices as well (there are reports of BSOD due to that driver). Did you hear any audio stuttering during those two spikes?

 

If you feel that the testing procedure does not provide enough stress to the system able to produce kernel conflicts, or if you found another method to introduce latency please let me know so I can add it to the testing phase

 

+ rep, and thank you much. Now hopefully this will finally get the Dell reps to believe that I've got a problem when I get back to the States in a few months, seeing as how I doubt it will be fixed even by then.

 

No audio stutters except the eject button.

Sometimes I see the red spikes when starting a game, but just once or twice and that's it.

It was quite a handful to perform this test. I don't think I could pull off a more stressful test.

My son watched the whole thing and he could not believe how this machine could run everything smoothly.

 

Your results confirm what BatBoy said: http://forum.notebookreview.com/showthread.php?p=5899534#post5899534

 

UPDATE
I changed the last command so it can generate the HTML report file automatically. I removed the last step, no need to open the TXT file and save it as HTML anymore.

 

I posted this as well over in the DPC thread explaining the ACPI factor and what BIOS A03 did to fix it:

http://forum.notebookreview.com/showpost.php?p=5899945&postcount=1522

 

BatBoy I ganna need your help with this. We need at least one R2 owner to try this test so we can make comparisons. It would really help to see how it would perform under the same load. Especially with the eject button issue.

 

I dont have an R2 however I will see if I can track someone down. I also did not have time to work on your process but I will get to it this week. Sorry for the delay.

 

No problem BatBoy there is no rush. I am sure Dell does not depend on us for this matter.

 

If I get the R2 fast enough, will be your guinea pig. Hopefully they can ship it this week.

 

I was going to suggest you! But I knew you would find this thread quick enough. LOL

 

UPDATE
I changed the testing phase mostly to facilitate those with Nvidia cards to determine whether or not they experience stuttering and why, and secondly because I use a second monitor to extend my desktop and I was able to run all the tests simultaneously.
People though without an external monitor would have a difficult time keeping two instances of youtube videos that occupy the whole screen, a full screen PDF to scroll, playing an mp3 file and watching the visualizations while monitoring the DPC latency at the same time.
I will update the PDF file soon.

 

i attach my results.

1)constant 4000 -5500 μs red spikes when scrolling pdf files .
2) 41000 μs red spikes when pressing eject button.
3) no red spike during playing video files but 4000 μs red spike when switching from windowed to fullscreen or switching between apps.
4) all way green bars during idle.

http://go.notebookreview.com/?id=525X832&url=http://i47.tinypic.com/27zjcd4.jpg

AUDIO STUTTERING-> NEVER!

my problem are the no audio stuttering causing red spikes reproduced under certain occasions. I know i dont have so serious issues as others and thats why i wont request a replacement or refund as i dont want to lose more of my personal time dealing with Dell noobs. However i really believe those spikes are not shown red for no reason and it affects working with audio.

Finally audio stuttering is solved but NOT DPC LATENCY!

 

Aristotelh, I reviewed your results and isolated those modules that appear on the DPC latency checker as red spikes as well as a few interrupts (ISRs).

General DPC statistics
Lower Bound - Upper Bound | Number_Of_conflicts
1000 - 2500 | 6
2500 - 5000 | 4

DPC Latency
Module | Lower Bound - Upper Bound | Count
usbport.sys | 1000 - 2500 | 3x times
usbport.sys | 2500 - 5000 | 1x time
dxgkrnl.sys | 1000 - 2500 | 3x times
acpi.sys | 2500 - 5000 | 1x time

ISR Latency
Module | Lower Bound - Upper Bound | Count
hal.dll | 2500 - 5000 1x time
i8042prt.sys | 25000 - 50000 | 1x time

Distribution of ISR to DPC latencies
ISR Module | ISR Address | DPC Module | DPC Address Module | Lower Bound - Upper Bound | Count
usbport.sys | FFFFF88004084254 | usbport.sys | FFFFF880040842FC | 10000 - 25000 | 1x time
hdaudbus.sys | FFFFF880040C1F20 | hdaudbus.sys | FFFFF880040CD480 | 5000 - 10000 | 1x time
ndis.sys | FFFFF88001536610 | ndis.sys | FFFFF880014A7C50 | 5000 - 10000 | 1x time

As you can see usbport.sys is causing you troubles. It seems that an external device (usb mouse??? external HDD or something that you have plugged in is causing conflicts within the kernel)
I would suggest to unplug all the external devices and run the test again to see if this will resolve this issue. Possibly a driver is not very compatible with the OS.

The dxgkrnl.sys also is responsible for a couple of spikes. Another driver issue tied with windows. BatBoy can confirm this too

At the ISR section, hal.dll caused conflict and combined with the usbport.sys I would blame the external device or a device connected via usb that uses this driver.

From WIKI:
Hal.dll is the core of Windows' Hardware Abstraction Layer, which allows applications to access devices in the system without knowledge of the specific protocol used by any one device.
Although drivers for most hardware are contained in external files, core drivers (which are required to support the kernel) are compiled into Hal.dll. Different sets of drivers may be selected depending on whether the system uses multiple processors, the presence of an ACPI-compatible BIOS or an Advanced Programmable Interrupt Controller (APIC), etc.


As you can see everything is very closely related to each other. (BIOS, ACPI, APIC,drivers...)

One more thing that will not make you happy is the ndis.sys which is related to the NIC (Network Interface Card) or the wifi. (That's why Dell persists so much with the wifi and ethernet drivers) Another driver issue here.

Last but not least, i8042prt.sys causes a conflict every time you press the eject button.

I could go further making a more in dept analysis but it's 5:00 am in the morning and I have a couple of hours left to sleep.

I hope this made things a little bit more clear about the red spikes you see on the DPC latency checker on your rig. (sorry for the format of the results, I know they are hard to read)

 

These are very interesting results to say the least. His spamming the scroll wheel on the mouse in the .pdf he had open is probably the cause of the usb result. Very interesting...

I'm loving this report you generated stam... nice job!

 

very good analysis.

i run the test from a usb stick so this maybe the reason for the usbport.sys issues as well?

however. even using the up and down buttons of keyboard (after removed all usb devices and their drivers-thus cleaning registry) for scrolling pdf file pages on fullscreen causes the same constant red spikes. even exact the same range. even more interesting scrolling webpages with the mouse doesnt cause red spikes even with the mouse scroll.

as for the ndis.sys i have done a new format yesterday just to install the drivers with the right sequence including their fix . so i installed the Dell recommended driver for the wifi. So their driver doesnt work for me only or its still a crap? it works ok for you?


i believe this dxgkrnl.sys is a component of directx right? i am of the opinion that this is the cause of everything really as switching between windows or from windowed to fullscreen, even scrolling large pdf files is related to the win7 enviroment... and if this is the case why it works ok with you whereas we have the same os?

Finally any other solutions? what about this i8042prt.sys? can it be fixed somehow? red spikes are the same and under same occasions with all the usb devices uninstalled (including their drivers).and i can see that the acpi.sys caused an issue only once so no big deal ..

i will re-run the test and post my results again. i think it will be more interesting this time.

 

ok here are my results after removing all usb devices including their drivers. test was run from the ssd.

please analyze this stamatis if you want.

 

I am attaching 2 sets of results:
1st setup:
Ran as outlined on page 1 with the following setup:
1) Win7 fresh install with MS default drivers for storage and Broadcom wireless
2) iTunes was the media player with the library on a FlashDrive
3) Chrome was used as my browser

2nd setup:
Same conditions as 1st setup but I started the logging process at the pretest phase and included opening 2 instances of GPUz to track clocks and temps.
The reason I did this is because I still see DPC issues when opening programs/resizing windows and moving windows and wanted to be able to show that. I have also included a screen cap of my DCP. This was taken yesterday but looks very similar to what I observed during this test today for the 2nd setup.

 

the situation changed here. now due to unknown reason touch buttons produce 42600μs spikes and CAUSE AUDIO STUTTERING! DAMN DELL!

 

Well isnt the touch strip considered the same as a usb device? i know when I use my g13 game pad and its under heavy use when gaming, i can reproduce many stutters when pressing buttons...

If i get time this week, i will try to do your posted process and see what I come up with..

Thanks!!! + rep once i spread some around lol

 

Running this test from a usb stick will make a difference and yes the usbport.sys didn't cause any trouble this time

Removing external devices made the difference this time and keeping your system with less drivers helped a lot judging from your new results.

this is from Adobe Acrobat Reader 9.3
As you can see it performs rendering to smooth the result you see on your screen. Doing that involves the display drivers.
http://img46.imageshack.us/img46/8711/pdfrendering.png

this is for 3D rendering
http://img32.imageshack.us/img32/439/pdf3d.png
as you can see it uses DirectX 9 to render 3D

To be honest I haven't tampered with the settings of the Acrobat Reader in order to compare the results.

That's good news. Personally I don't have any problem with that either.

The driver works fine for me.
For you it caused a spike between 25000 - 50000 μs
This does not neccessarily mean that the driver has a problem, it could also mean that another driver conflicted with this one and caused a delay. Most of the time it is the combination of drivers that causes trouble and not a driver by itself.

dxgkrnl.sys caused you 4 spikes that range from 500 - 1000 μs like in my case, but I don't consider it as problem since it does not affect me or the applications that I am running. If you find an application that this driver causes you trouble directly (like blue screens or error messages) or indirectly then it is a problem.

Yes there will be a solution for this as well, as long as Dell is aware of this and the engineers put some effort on this issue too.
Not all the USB devices are uninstalled. Go to
Control Panel --> Device Manager and take a look under the Human Interface Devices/Universal Serial Bus Controllers


Briefly the results of your new run:
DPC latency:
acpi.sys | 2500 - 5000 1x time

ISR latency:
i8042prt.sys | 25000 - 50000 1x time

Distribution of ISR to DPC latencies
hdaudbus.sys FFFFF88002DA0F20 hdaudbus.sys FFFFF88002DAC480
2500 - 5000 1x time

i8042prt.sys FFFFF88003F6AA70 i8042prt.sys FFFFF88003F69390
5000 - 10000 1x time
50000 - 100000 1x time
100000 - 250000 1x time
5000000 - 10000000 1x time
(how many times did you press the eject button?)

ndis.sys FFFFF880014F8610 ndis.sys FFFFF88001469C50
25000 50000 1x time


*EDIT*
One last thing that I forgot to mention:
If you want open a command prompt as administrator and run:
sfc /SCANNOW

It will check for integrity violations of protected system files and will repair them if possible
It took me quite a while to finish (2 min approximately)

otherwise run
sfc /VERIFYONLY (most advisable if you don't want any changes)

Most likely it won't find any errors. it's more of a precautionary measure and not necessary to run. Choose wisely though as I don't want to be responsible for any changes to your system.

 

thanks again. one question only. did you change any of those adobe reader settings?

as for the usb devices as i said regardless of the tests results the dpc latency checker shows red spikes of the same range as with them installed and under the same occasions.

 

Chrome put some stress on the CPU here

Results for the first run:
General statistics for DPC:
1000 - 2500 | 25x times
2500 - 5000 | 7x times
5000 - 10000 | 6x times

MODULES:
usbport.sys
1000 - 2500 | 6x times
2500 - 5000 | 1x time

dxgkrnl.sys
1000 - 2500 | 19x times
2500 - 5000 | 6x times
5000 - 10000 | 5x times

acpi.sys
5000 - 10000 | 1x time


General statistics for ISR:
25000 - 50000 | 1x time

MODULES:
i8042prt.sys | 25000 - 50000 | 1x time

Distribution of ISR to DPC latencies
usbport.sys FFFFF88003A2D254 usbport.sys FFFFF88003A2D2FC
1000 - 2500 | 1x time
25000 - 50000 | 1x time

ndis.sys FFFFF88001694610 ndis.sys FFFFF88001605C50
1000 - 2500 | 1x time
25000 - 50000 | 1x time

hdaudbus.sys FFFFF88002DCEF20 hdaudbus.sys FFFFF88002DDA480
1000 - 2500 | 2x times

wdf01000.sys FFFFF88000F337F0 wdf01000.sys FFFFF88000F33818
5000 - 10000 | 1x time

(do you have any logitech device installed?)

usbport.sys FFFFF88003B5ADB0
1000 - 2500 | 32x times
2500 - 5000 | 4x times

dxgkrnl.sys
1000 - 2500 | 78x times
2500 - 5000 | 3x times
5000 - 10000 | 3x times

dpclat_driver.sys
1000 - 2500 | 18x times
2500 - 5000 | 2x times
25000 - 50000 | 1x times

ndis.sys
2500 - 5000 | 1x time

storport.sys
1000 - 2500 | 12x times
2500 - 5000 | 6x times

usbport.sys FFFFF88003B852FC
1000 - 2500 | 5x times

dxgkrnl.sys
1000 - 2500 | 78x times
2500 - 5000 | 3x times
5000 - 10000 | 3x times

dpclat_driver.sys
2500 - 5000 | 2x times
25000 - 50000 | 1x times
(to me it seems that a delay to thi driver was caused by something similar to a chain reaction here, a driver caused all the other drivers delay including this one, reminds me of domino ,interesting)

storport.sys FFFFF88001129880
1000 - 2500 | 12x times
2500 - 5000 | 6x times

usbport.sys FFFFF88003B852FC
1000 -2500 | 5x times

ntoskrnl.exe FFFFF80002DC07F0
1000 - 2500 | 2x times

This is indicative of the conflicts that occur to your system

NOTE FROM WIKI:
ntoskrnl.exe (and ntkrnlpa.exe on systems with Physical Address Extension support) is the kernel image for the family of Microsoft Windows NT operating systems. It provides the Kernel and Executive layers of the Windows NT kernel space, and is responsible for various system services such as hardware virtualization, process and memory management, etc., thus making it a fundamental part of the system. It contains the Cache Manager, the Executive, the Kernel, the Security Reference Monitor, the Memory Manager, and the Scheduler, among other things.

(one question, does this appear on your windows task manager? I am kinda paranoid here but if yes could you scan your computer for viruses? because this should normally not be visible)

hdaudbus.sys FFFFF88003BCE480
1000 - 2500 | 1x time

nvstor.sys FFFFF880011123CC
1000 - 2500 | 3x times
2500 - 5000 | 3x times

ntoskrnl.exe FFFFF80002CC3CBC
1000 - 2500 | 2x times

nvm62x64.sys FFFFF88003E0CB00
2500 - 5000 | 1x time

ndis.sys FFFFF880014980C0
1000 - 2500 | 1x time

Distribution of ISR execution times
general IRS distribution time statistics
2500 - 5000 | 14x times
25000 -50000 | 3x times

ndis.sys FFFFF880014E6610
1000 - 2500 | 5x times

storport.sys FFFFF88001135080
2500 - 5000 | 14x times

usbport.sys FFFFF88003B85254
1000 - 2500 | 3x times

i8042prt.sys FFFFF88003AC0A04
25000 - 50000 | 3x times
(this has to be the eject button right?)



You have a few more but I run out of time here, sorry

There is clearly something wrong with the drivers here and it compromises the latency of the whole system. I suspect it's something you connect externally that mostly affects you(usb mouse, usb stick that you store music???)

Try to eliminate those two factors and see if it helps with the latency.

 

No Aristotelh, I didn't.