M17x-DPC/ISR tracing

i ve seen that now. i pressed it just once...!

 

I just ran sfc /SCANNOW and it reported I had corrupted files that it was unable to repair. Is that anything to worry about?

It stored the report in a log file but I can't open it, Access denied.

 

You have to run command prompt with admin rights first.. if you use search and type in cmd.. then when it is displayed right click on it and select run as admin.. then try it again.. it should work

 

That's exactly what I did boss, it ran and it reported the corrupted files. It won't run at all without admin rights.

 

Did you try the /Scanboot option to do it at boot up. I dont know if its trying to fix stuff that is in use.

will have to use the /revert to turn off the scanboot option once done.

 

To read the log you can do the following. Dunno if your on vista/win7

1. Open a elevated command prompt.
2. In the elevated command prompt, type findstr /c:"[SR]" %windir%\logs\cbs\cbs.log >%userprofile%\Desktop\sfcdetails.txt and press Enter.
3. Close the elevated command prompt.
4. Click on the sfcdetails.txt file that was just placed on your desktop to see the SFC scan details (ones with the [SR] tags) in the CBS.LOG.
5. You can safely delete the sfcdetails.txt file afterwards if you like

.

 

Okay Kilthro I appreciate your help but I fear you may be wasting your time! I'm not PC savvy enough for this stuff. I tried your string (replacing the relevant parts with my info) but it just said path not found. What is an elevated command prompt? The same as an administrator command prompt?
I googled the /scanboot option but it seems to refer mostly to virus checkers and stuff.

I'm scared!!!

 

If you are afraid here is the Microsoft page that references all commands. Dont be affraid..

http://support.microsoft.com/kb/310747

yes the elevated command prompt is the same as doing the search for cmd right clicking and saying run as admin.

Just copy that log file to your desktop. If I remember correctly u can use a word/notepad to access it.. you should have access to it if you copy it to your desktop.
You will have alot of info in there. You will have to search for the [SR] lines.

 

do those commands check for driver conflicts or something as well?

 

Well the answer will vary according to the programs you have installed, if you shut down your laptop normally or not, a security suit may prevent access to system files or commands that want to access system files, if you had any kind of virus that altered system files, etc,etc... Is your system stable? Do you experience any slowdowns after normal use? Weird behavior of the system should concern you.

 

Aristotelh, If you run the first command the second is unnecessary. The first will do what the second does but it will also proceed to fix the issues if any.

 

I plan on doing this tonight on my Vista x64 setup. One question, how did you have this arrainged? I am not 100% sure I am understanding how you have your screens setup. If I full screen a YouTube video, I cannot see anything else on the screen...plus, this is where the bulk of my red spikes come into play.

 

I use the laptop screen as my main desktop and I use another dell monitor I have to extend this desktop. On the main desktop (laptop screen) I opened two firefox windows. So half the screen for the one video and half the screen for the other video. On the external monitor I opened the DPC latency checker, the mp3 player and run the acrobat reader at full screen. (Don't expect to monitor the latency while on full screen with Acrobat Reader, just check when you leave full screen if you produced any red spikes and how much was the latency)
That way I could run all the tests at once. Not all people have an extended desktop, that's why I altered the procedure a little, so they can do one thing at a time while monitoring as much as possible the DPC latency checker.

 

Guys, we need an R2 owner to try it.
I only have the R1 and I depend on you for this.
It will provide really valuable data and it's only a few minutes procedure.

Thank you in advance.

 

Boy was that a complicated process! I sure hope I did it right. What do I do with the html file? attach it? I can't tell what part of it you're looking for exactly...

 

Yes Lord Zath, zip the html file first and attach it to your post so I can take a look at it

 

k here you go!

 

DPC Latency
Unknown FFFFFA8005B200F0
2500 5000 1x time
dxgkrnl.sys FFFFF88005106588
2500 5000 1x time

ISR Latency
i8042prt.sys FFFFF88003D15A04
25000 50000 2x times
(This has to be the eject button)

Distribution of ISR to DPC latencies
ndis.sys FFFFF880016E2610 ndis.sys FFFFF88001653C50
25000 50000 2x times
hdaudbus.sys FFFFF88003E7AF20 hdaudbus.sys FFFFF88003E86480
5000 10000 2x times


Your results seem pretty good and your computer should not have any kind of stuttering except from when you press the eject button and those two drivers (ndis.sys, hdaudbus.sys)

My impression for those two (if I could see a screenshot of the DPC latency checker I would be more certain) is that scrolling in fullscreen mode the PDF file and resizing windows triggers that driver:dxgkrnl.sys The kernel tries to resolve the conflict by putting the rest of the drivers required by the system like ndis.sys (for downloading from youtube) and hdaudbus.sys (for the audio) on hold, that waiting is translated into the red spikes we see. (this delay though seems to be related with the eject button also, that's why PDC latency checker helps).

My question is, did you notice any flickering on the videos or any stuttering on the audio? (both from youtube and mp3 file)

 

no flickering. Potential stuttering audio wise, but very hard to detect. The ATi's definitely seem to have solved many of my issues.

I'm considering moving back to Vista soon though to completely eliminate stuttering.

Glad you didn't notice anything with the USB driver. I've got a mouse hooked in and was worried that the Synaptics drivers are flawed.

 

According to your data it should only be detected when pressing the eject button, other than that the delay is too short to notice.
Hopefully the mouse seems to cause you no trouble and I have to admit that you run quite many services in the background.... (utorrent,antivirus,updaters, and you are at 3.5!!! GHz which could compromize your system stability)
Pretty impressive.

 

hehe yeah I suppose I do . I have never had a BSOD at these settings so here's hoping it stays that way!

 

Good job

 

UPDATE
I would request from those who run the test, to include a screenshot of the DPC latency checker along with their results.

Thank you

 

@stamatisx

Check your PM's at your earliest possible convenience, please.

 

I did run the test, unfortunately the dell techs said I would have to wipe my system and have them run some tests if I want to get a replacement. I didn't save my test data so I'll run the test again as soon as I can.

 

No problem ndudsz, let the techs do their job first and then run the test.

 

Here is mine, my DPC wasn't as bad as it normally gets. After about a half an hour of use I get 60k spikes at least every 5 seconds. This is after being idle for an hour... Also, I ran a game (warcraft 3) and closed it immediately after because that always seems to make it spike after. (Downclock im guessing?)

 

Your DPC latency is exceptional considering the fact that warcraft 3 was still in the background.

Nevertheless,

Distribution of DPC execution times
dxgkrnl.sys FFFFF88003ECF588
25000 50000 3
10000 25000 5
50000 100000 8
(this is a display driver issue from NVidia that probably caused you audio stuttering, hopefully it will be resolved soon)

Distribution of ISR to DPC latencies
usbport.sys FFFFF88003A97254 usbport.sys FFFFF88003A972FC
10000 25000 6
25000 50000 2
50000 100000 2
(One question do you have any external devices attached? Did you press the eject button at that time?)

hdaudbus.sys FFFFF88003AD4F20 hdaudbus.sys FFFFF88003AE0480
2500 5000 4
5000 10000 4
(that's a side effect from the previous two)


I have to admit that your results (excluding the above mentioned) are even better than mine considering also that war3.exe was open in the background

 

Not in the background, at the end of all of the other tests I opened it and immediately closed it at the end.

Also, had my mouse plugged in and ran the tool off my flash drive. It was already installed on there from the last time I ran the test.


EDIT: Also, as I said my DPC seems to spike more frequently and higher after some use, If you want I could use it for awhile and run another test.

 

Oh, even better, you put much more stress then

 

At least that explains the:
Distribution of ISR to DPC latencies
usbport.sys FFFFF88003A97254 usbport.sys FFFFF88003A972FC
10000 25000 6
25000 50000 2
50000 100000 2

 

So far the main factor that affects the latency is the display drivers (my opinion according to the data since it is present in every test)

The rest of the spikes you see are side effects of the main problem.

 

This is a pic yesterday while trying to watch a dvd... The tech said it wasnt that bad

 

The 50K+ spikes are bad...

(mainly caused by this)
Distribution of DPC execution times
dxgkrnl.sys FFFFF88003ECF588
25000 50000 3
10000 25000 5
50000 100000 8

As soon this will be fixed the rest of them will be vastly improved

 

so which .sys is related to it? is it this usbport.sys ? i can see i was not the only one who had it finally. The display drivers for win7 are absent i think. Also dont forget that no nvidia driver can set to 60hz on win7 which may be related as well. If you see that Dell release a good driver for the display.

 

The NVidia drivers do not work on their own but utilize other system drivers too. So far they seem to cause conflicts within the kernel introducing delay to the system. That's why Nvidia users see those big 60K+ red spikes especially on win 7.

The 59Hz that you mention I don't think that it's that of a serious problem (personal opinion) but you never know and since I can't prove it, it's not responsible for me to say anything more.

About Dell I think they will take care of that problem with the help of NVidia.

 

It does set it flawlessly for my external monitor. The built in, it never goes past 59. I think its how its detecting the built in monitor....

the xl2370 always runs at 60 in game and on the desktop..
I know the built in display has issues being detected right since if I put my computer to sleep, open the lid which wakes it, and the built in display activates first.. Then I swap it over to external, and games get a refresh rate issue as the driver gets stuck for some reason on 59 when my external need 60 which causes flickering in the game... If I reboot which makes external activate first (lid opened or closed) or enable wake from usb and wake the computer by keyboard with lid closed so the external is forced to activate first there is never an issue... So for some reason in my troubleshooting it is limited to the detection of the built in monitor and setting it to 59..

 

I agree, the 59Hz is a flaw that NVidia should take a look at.

 

its been one month since i posted this in nvidia powermizer issue thread.

 

Powermizer and this are two different issues though

 

of course. i just posted this for them to have it in their minds in case they release a new driver which i doubt.

 

I understand that Aristotelh and it was a good thing you did that. I haven't searched that issue any further but I would create a new thread at the NV forum (if there isn't one already) and post the problem there so it won't be lost within all the posts for the powermizer issue

 

Here is another trace log - both video&audio (in utub) and audio (in wmplayer) stutters.

 

Thank you for sharing your results myxcon, you stressed the machine literally on this test ( Idle 33,6% )

Distribution of DPC execution times
dxgkrnl.sys FFFFF880044C1588
50000 100000 12
25000 50000 4
10000 25000 2
100000 250000 1

acpi.sys FFFFF88000FB53D0
5000 10000 4


Distribution of ISR execution times
hal.dll FFFFF80003202808
5000 10000 1

i8042prt.sys FFFFF88003BC7A04
25000 50000 4


As you can see, it's the usual suspects that cause all these troubles.
The eject button was around 42K-45K right?

 

Yea, to be honest the eject button isn't such a pita, couse the sound of the mechanisc covers the sound of the speakers and I also owned a slot-load unit at my desktop pc so i'm used with the interupt while ejecting disks.

Btw, I use an external sound card, on usb, if that should matter for the analysis.

LE: the eject mechansm isn't THAT loud to cover the sound, is just that I listen in very low volume almost all the times.

 

The problem with the eject button and the downclocking of the GPUs are known to cause audio stuttering. An external device does not necessarily introduces extra latency to the system. It depends on the drivers it uses and on the drivers that introduce the latency to the system. I will attach bellow a part from the:

http://www.thesycon.de/dpclat/dpclat.pdf
(It's from Thesycon's DPC latency checker, the program we all use to monitor the latency)

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.


In other words, if one thing goes bad... it's going to be like a domino, whatever follows next is going to be affected too. (my comment)
I found this PDF today and I updated the first post of this guide so that everybody can read it before she/he proceeds.

 

OK, did the test.
I hope I did it right.
There is definite stutter going on (really annoying) just not sure how best to read these results.

D.

 

Thank you debaucher for sharing your results

Distribution of DPC execution times
dxgkrnl.sys FFFFF88004E1F588
50000 100000 18
25000 50000 5
10000 25000 3

storport.sys FFFFF88001132880
1000 2500 1

(do you have the nvidia storage drivers installed?)
(external devices introduced additional latency too)

acpi.sys FFFFF88000F353D0
5000 10000 2


Distribution of ISR execution times
i8042prt.sys FFFFF88003F3CA04
25000 50000 4
(that should be the eject button)


As you can see we have the usual suspects but also an extra delay due to an external device, maybe an external hard disk that you had your music stored during playback

 

Heres a report for my M17x R1 T9600 2x260GTX 6gb ram

Did install the A03 and "fix" provided by dell but still have the occasional spikes. Doesn't bother me too much while gaming though.

Side note:
Due to having the O&O defrag software the reporter xsl transformation acts funny becaue of the ampersand. So I just reported it to XML and added the stylesheet to it and removed the ampersands.
Just unzip and open the xml in internet explorer, you'll figure it out

Happy analyzing and let me know if you find something