M17x-DPC/ISR tracing

Unfortunately I don't have the internet explorer (I uninstalled it for security reasons) and firefox cannot display the results correctly.

 

try this instead. Just zip the txt and send it. I will convert it manually. You don't have to run the test again as long as you haven't deleted the test01.etl

tracerpt test01.etl -report dpcisr.txt -f HTML


Tell me if you still have problems

 

All right, since no other R2 owners have posted anything...

Here's my run:
View attachment dpcisr.zip

and the dpc latency checker screenie:


I didn't notice any stuttering, videos played back fine. There is a recurring spike every 10 seconds (ndis.sys if I'm reading the results right) that rarely exceeds 1400μs, even under load. The big red spike at the end is the eject button--seems that didn't change from R1 to R2, though 5k doesn't seem excessive compared to some of the results others have posted.

 

First of all congratulations, you are officially the first R2 owner who took the test and submitted his results.

The results:
The least I can say is: Very good results!

General Statistics about DPC distribution
500 1000 123x times
250 500 72x times
1000 2500 20x times

////////////////////////////////////////////////////////////////////////

Distribution of DPC execution times
acpi.sys FFFFF880011B93D0
500 1000 120x times

ndis.sys FFFFF880017160C0
1000 2500 20x times
500 1000 3x times

////////////////////////////////////////////////////////////////////////

Distribution of ISR to DPC latencies
hdaudbus.sys FFFFF88004A49F20 hdaudbus.sys FFFFF88004A55480
2500 5000 1x time
(the eject button delayed the audio driver a little, but not enough
to cause stuttering)
////////////////////////////////////////////////////////////////////////

Conclusion:
the major difference I see between R1 and R2
dxgkrnl.sys

managed to stay well under 500μs during the test
also the eject button didn't cause the i8042prt.sys to "explode" like the R1
causing audio stuttering. (I could say a better BIOS here???, unless there has been a change on the drivers)

Another important factor that is related to the good results, is the number of the cores of the CPU that can handle more threads simultaneously, which gives a clear advantage over the R1.

The only weakness I see according to the data is the ndis.sys which is probably related to the wireless drivers and the internet.

With spikes within the 5000 μs limit, no video stuttering no audio stuttering.
Well done DELL !!!

 

Thanks for the quick analysis and glad I could contribute.

 

Many of the R1 results show the same things. The R2 is fixed.

So is Dell going to pay this community for doing their jobs?

What is the point of paying for extended next day service if you have to wait 3 month for a fix?

Sure, Dell will send a tech to your house every day to waste your time and their money keeping you entertained with their efforts to fix it, but who has that kind of time to waste?

These units should be recalled and replaced. And it took a volunteer on NBR forums named stamatisx to figure it out.

 

I still need to collect more data in order to come to a conclusion. Right now I would rather prefer not to place myself on this matter in an attempt to keep this thread as clean as possible for the data and their analysis. When I will have enough evidence in my possession I will post a detailed report.

 

That won't work either because the reporting tool is using a similar xsl template to convert it to html, which I can't access. Ive just copy pasted the tables I think you're analyzin to word. Let me know if this works for you.

 

True, but the fact that you took the initiative to figure this out when Dell hasn't speaks volumes.

 

Svekke I appreciate your effort but the results you copy pasted on the word are only a fraction of the things I analyze from the data. I can't give you any information based solely on those as I need to see the whole picture of the test. I hope you understand.

 

Hello, I'm Brand new to these forums. I'd like to toss my info into the mix here.

I've got an m17x r1, Windows 7 Ultimate 64bit, Quad core Q9300, 8 gigs of 1333hz, 2x 280m hybrid SLI, 2x 512g RAID 0, and the Optiarc DVD +- RW AD-7640S (should have got the Blue Ray...)

Anyway, here is the dcp report. View attachment dpcisr.zip

Nice to meet all of you, and here's to hoping DELL gets their stuff together and fixes this.

 

Welcome to the forum Spectre1980 and thank you for submitting your results.
Unfortunately it is another "classic" case of Win 7 / NVidia cards.
We all hope for a fix soon.

 

are you interested in windows Vista/nvidia results?

 

Ehhhh, let me think about it....
Of course and I am interested, not only me, pretty much everybody here

 

ok i will try to follow the instructions to your test then

 

Here are the results View attachment dpcisr.zip

and thanx for your help with the command prompt...

ps: sorry for 2x post...

 

No problem, thank you for the results

I have to admit that these results differ from what I have seen so far

Distribution of DPC execution times
nvlddmkm.sys FFFFFA600346C760
50000 100000 1 (NVidia display driver as usual)

acpi.sys FFFFFA60007AA288
5000 10000 1

let me ask you something, did you press the eject button?
While you were monitoring the DPC latency checker, when that big spike occured did you notice any audio stuttering?

One more thing, what are your CPU and RAM frequencies on BIOS?

 

I didn't experience any stuttering during testing, if i really pay attention i can hear some minimal audio "cracks" when clocks of the cards under/overclock.

CPU and RAM frequencies are linked in BIOS, CPU overclocked to 2.9 using multiplicator.

I did press the eject button, it did give me a red spike under 4.000 without suttering.

I can try and replicate the results if you want.

 

They are really interesting your results especially the eject button.
I will keep the fact that you didn't experience audio stuttering during the test.

 

Well i have followed every advice given to the "7" users, i don't have OSD installed, same for the nvidia drive controller, alien fusion is disabled in the services etc. I just didn't do the registry tweaks.

Another funny thing is, going from bios A02 to 03 gave stuttering especially while watching videos. Did a fresh instal of vista and everything is fine since.
The DPC latency checker still gives spikes, but no stuttering whatsoever, just some "cracks and pops" while powermizer does its work but nothing serious, almost not audible.

So what you are saying is that even for a Vista user, my readings are unusual?

 

They are different from the previous results because you don't have the OSD installed. That makes sense.
The downclock of the GPUs indeed is causing troubles. Spikes above 43K are unfortunately noticeable.

 

My 280m SLI Vista test was clear.

I can do another test.

Pick two of these (1 and 3 are mutually exclusive):
1. 280m SLI Windows 7 test
2. 4870 XF Windows 7 test
3. 4870 XF Vista x64 test

 

I put an update on the latency thread.
http://forum.notebookreview.com/showpost.php?p=5963234&postcount=2473

 

I would like to see the test #3 since I haven't done it myself as well as #1

 

Might be old news, but if I eject a disk form windows explorer there is no corresponding DPC spike. If I use the touch panel I get a huge spike.

 

Yes it has been mentioned a couple of times in the past but thanks for reminding.

 

Here is another report (see config in the signature) after installing the BETA drivers - clean install.

 

Thanks for the new data

Your results actually are very good.

It seems that NVidia actually took care of the latency problem.

Only the eject button causes some trouble here but I believe Dell will take care of that with a new firmware update.

 

DPC checker still shows red spikes:

- up to 4-6k when loading different pages and watching movies (youtube / player) - doesnt produce audio or video stuttering
- up to 45k when i press the eject button, stealth button and fn+f12 to disable/enable t-pad.

 

come on guys we need test with the new nvidia driver..

 

Its already been done and its clean... Stamatisx will post to this when he's online. NVIDIA resolved the DPC issue with the display driver.

 

Stamatisx, would you mind having a look at the attached html report?

Things are running well with the new drivers, but every 70 seconds on idle or otherwise, I get this very harmless but inexplicable 10k spike. I just want to know why this is happening, so I setup the kit on my system and logged the spike.

Maybe you can have a look and give me some feedback.

 

I checked your results and the problem does not come from the
the NVidia drivers, they are clean, what you see is from this:

ndis.sys FFFFF880016CE0C0
5000 10000 3x times
2500 5000 1x time
10000 25000 1x time

it's the wifi drivers that caused the latency

 

I have seen similar results on my end. Whenever I work my wifi really hard, I get nothing but high latency spikes.

 

Thank you, sir!

This thread is gold.

So next question: What would you recommend? I think I forgot to get updated drivers from the Dell website. The machine's presently using the default Win7 drivers after a fresh installation of windows.

 

To be honest, trying different drivers and see how each of them behaves with your current configuration would be my recommendation. Personally I would try to optimize the settings of the wireless card first. If that doesn't make any difference try another driver and play with the settings again. Eventually you will find out what combination plays well with the rest of the drivers you have installed.
I know it's a time consuming procedure... so be patient and thorough with the changes, one at a time until you fix it.

TIP, check to see if you have allowed the computer to turn off this device to power save. Maybe the transition between active to power saving mode is causing the spikes.

Hope that helps

 

Thank you for the advice and information.

 

No problem, just let us know how it went

 

stamatisx,

Sorry, if you covered this. I'm not THE most technical person around. Have you looked at Process Explorer and thought about maybe including it in your test procedure somehow?
http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

 

Thank you Bill, I will take a look at it as soon as possible and I will try to incorporate it to the existing process

 

I was using the Process Explorer and I have to admit it provides very useful information. Especially CSwitches Delta column, which is the number of interrupts and DPCs generated per refresh interval.

http://img59.imageshack.us/img59/4126/taskhost.png

There is only one drawback though. I couldn't find a way to save all the information that I need to single file. It can only save a .txt file with the upper part of the windows and only the info from a single selected process.
For someone who knows what is looking for it is very handy, but for an average user that tries to figure out what is wrong it won't be that helpful.

What I can do in this case is to ask from the users to download this program and run it after it finishes with the tracing process in order to take a screenshot similar to mine above. The program by itself introduces much latency because of the monitoring and running it during the test will distort the results.

Thank you though because it is very useful for the post test procedure.

 

In addition to Process Explorer (that is another one of Mark's creations stamatis), take a look at Process Hacker. A bit more functional IMO.

http://processhacker.sourceforge.net/

 

Thank you BatBoy, I just installed it, I will take a look at it and report back

 

BatBoy I really liked the Network tab on this program, it's very very useful to me.
On the other hand the program that Dell-Bill_B suggested is more detailed when it comes to processes and it displays more information than necessary, thus making it more hard to use for the average user compared to the process hacker, so I agree that your program is more functional and easy to use.
Those who are interested and want to go a step further, need to have them both.
I also updated the first post in order to link those two programs

 

Do you guys still need an R2 tests? Looks like I'm getting mine in a couple of days.

 

Of course we need Aikimox, the more results, the better

 

a little bit out of topic but just for comparison here are the spikes with my ACER D150 300 dollars netbook running the large pdf file of the guide in fullscreen and with full speed scroll. search on google to see its low end specs (good for netbook though). but of course it has intel chipset....!

http://i45.tinypic.com/eber8n.jpg

SHAME on Dell-Alienware that makes me use the netbook for looking pdf files.

 

Thanks for the screenshot but it would be helpful only escorted with a report.
To add to the mystery about Intel vs NVidia chipset take a look at this screenshot while I was abusing the PDF file in Full Screen, BUT,not on the laptop screen, it was fullscreen on the externally connected monitor that I have to extend my Desktop.
I used a resolution for the external monitor of 1024x768 because I have it for reading documents from distance.
http://img52.imageshack.us/img52/6603/spaming.png
(to see the whole image slide it to the right)
As you can see here with the NVidia chipset there are not even yellow spikes.
So please keep this thread clean from chipset discussions.

 

so its like saying that the display or the connection with the display mulfuctions. i would be really interested if this occurs on vista too. but i think it does. but the mouse is not the reason for MY red spikes while scrolling pdf files.

 

Not even close. there is no mulfunction here.
If you want open a new side topic where we can discuss about the potential reasons that Acrobat Reader affects latency