Help me stop this horrible stuttering on my SLI rig.

I'll do that while SLi is enabled. Better still I already did.

#1 Remove all USB devices (external)
Done. No effect.

#2 Only on battery mode
Done. No Effect

#3 Remove the battery
I'll do that tomorrow

I have some more tests to do.

#4 Use an external audio card (I have one)

#5 Remove my internal TV card (although I don't have any drivers installed for it)

If suggestion's are more drivers I'm tired of trying almost all drivers since 169.04. I think I'll stop by now going this route. I thought it the lack of power due to USB overcharge but I tried with no USB devices connected, wireless off, and COD4 running in single player in SLito no avail.

The only way I got to stop is simply to run the game while SLi is disabled and NVIDIA settings are on Performance.

Thank you all for the help. I think if we come up with a solution it might be usefull most 8700MGT SLi users. So keep those suggestions coming.

Trance

 

bwhxeon, my system runs perfect without the battery in and plugged in . The problem is once I put the battery back in the stuttering starts again, even while plugged in. What does this mean??? How can my battery cause problems while plugged???

 

=/ well best case senario is its a bad battery, worst case is bad motherboard. Maybe other forum members can put some input on the subject of bad batteries.

 

Trance you've updated your Directx right? You've tried other video drivers? Have you played around in game with settings to see if it is just one thing? Have you canceled all other processes and just run the game bare? I'm thinking it could be caused by another program taking away priority. Just a thought. Have you tried setting the CoD4 to high priority? I play CoD4 on my 7950's at 1900x1080 (for my HDTV) and don't get spikes like you are describing. I'm still using 169.09 drivers also, fyi.

 

it's the cards.

they aren't good for SLI, and also not good period.

 

@DFTrance - you know what, I'm pretty good at cherry-picking the low fruit, but now that I've spent a little time nosing around on this problem, I find that I can't give you anything more than the not-particularly-useful starting points I've been sprinkling around here. Sorry 'bout that.

However, I'm going to try digging around and getting a better grasp on my particular little take on the cause (interrupt conflict somewheres) and if I actually find anything that's (a) interesting, (b) useful, and (c) more than just vague hand-waving, I'll come back and post it; otherwise I'll stop wasting space on your thread.

The only two other tests I would suggest, because they worked on other posts I swept up in my googling and they're relatively easy to do, are: (1) turn off the wireless, (2) turn off the bluetooth (if you have it). The bluetooth seemed to crop up as a culprit a number of times, frequently because it was polling for non-existent peers and using a time-out that was too long.

I had a similar issue with a belkin network drive hub for usb drives that plugged into my router - if the drives or the hub were turned off, the driver/manager on my system would slowly eat up resources with it's constant polling for the hub and the drives, to the point where it was using a constant 98% of all cpu time.

 

it's not the cards, it's not how many usb devices you got loaded up, it's not the hard drive slowing you down (it doesn't even access the hard drive when this crap occurs), it's not a defragment problem....it's the damn sli drivers and the entire sli concept, it sucks!

trust me, i know. i just got an alienware m9750 that i have been struggling to understand what it's 7950gtx sli is doing this past week. i have did some some research in other sli forums out there. here, let me post what i posted in the alienware fourms;

sli is great, when it works and if it works!. the two games i player right now, sli is driving me insane. turning off sli and running with one 7950gtx is simply not enough power to play eve online and supreme commander at high settings. with sli on i feel like it is the power of an 8800 gpu, easily.

although sli gives almost double the fps, the drivers are so finicky that i am considering returning the laptop. it's great that supreme commander runs smooth at max settings with a ton of units on the screen, but the speradic slowdowns that bring the system to a halt for no appearant reason, and then recovers from this sputter, is too much to bear. it almos makes the game un-playable. i have tried so many drivers out there and it's always the same damn sputtering. i don't know, is it some bloom effect or some kind of explosion that the sli driver does not agree with and decides to almost hault my gameplay while it tries to recover? i have to fight with this everytime it occurs, trying to pan the camera in hopes it becomes unstuck....

i fight with the same thing in eve online....60 fps and then all of a sudden down to 3 fps and me panning the camera frantically in hopes it recovers.

this is my first dwell into the sli world and, even though it virtually doubles my fps, it also makes it unplayable with these stutters and finicky drivers. at first i thought the system was overheating and causing the gpu's to downclock. but this is not the case, after close examination.

i want to note that the sputtering does not occur with sli disabled. only in sli. you can even see when you enable the sli meter and fraps running. sli is turning itself off and appears to almost shut down both cards while the game takes an un-playable nose-dive.

 

well said argh.

 

I've been playing EVE since I got my D901C and even after the graphics update I haven't had any drop in FPS like your describing. Again, just using 169.09 drivers and running it with most settings to extreme in EVE. A lot will depend on a games ability to use SLI, a poor implementation will show. Crysis when it first came out springs to mind.

 

whats your setup wu jen? you running sli?

with eve online, the problem is vary appearant when i am sitting at my player owned station. there should be no reason that the frame should drop below 30fps even though there are a ton of ships and crap sitting there. panning the camera will cause sli to go belly up. i have to pan the camera away from a certain point. this especially occurs if i am zoomed in on my ship and point the camera at the control tower. if i do not pan the camera away the sutter may not even recover until doing so.

edit: sitting at jita 4-4 with a ton of ships on screen the fps will not drop below 40 and the stutter never occurs. but at my own station it does. today i was killing npc in asteroid belts and i witnessed the same stutter and just had enough. i will be facing a restocking fee but it's better than dealing with an unsupported product which is sli.

 

Argh, I'm thinking it has to do with the lighting. When your sitting in the station and the spotlights are sweeping up and down on your ship. I'm at work atm but I'll boot up EVE when I get off and post when my settings are.

 

what is your system setup??????

these stutters never occur if i run in sigle card mode, only in sli. in single card mode my fps is almost halved and the slowdowns in fps are normal like you would find with any card that cannot always handle smooth framerates in today's games.

 

My system is: Proc: X6800 2.93Ghz C2D, 4GB 800Mhz Ram, 2x7950 GTX's, 3x7k200's RAID 5, 17" WUXGA

I'm still using 169.09 driver, I'll post my settings when I get off work later and I'll look at the FPS with SLI and without and post that as well.

 

have the sli meter enabling along with fraps.

i reduced the shadow detail from high to normal and it appears to have remedied the nose dive fps sputters. i cannot get it to replicate panning the camera at my player owned station. the sputters are not traced to bloom and hdr as i have those set to high.

i will try similar lighting settings in supreme commander.

 

on the 8800 i am getting 30-60 fps 1900x1200 everything maxes with sync every frame on

 

Screenshot, OCing values and maybe a video Dexgo.
This time we want real life proof.

 

in which game?

 

so my findings are this with sli. in eve online setting shadows to high is not compatible. they must be set to normal. i am ok with this, sort of. in supreme commander the fidelity setting must be set to low. everything else can be set to high. i am not ok with this as it is the setting that gives the most visual difference.

these settings cause sli to mess up to the point that i am struggling to recover from 3 frames per second and it makes the game unplayable.

i am returning this laptop and will not be purchasing sli again until it is a universally supported product by nvidia and or developers....or whatever it takes to make it work.

what a waste of my time and money.

 

Well in fact the 8800m GTX SLI also has stuttering in some games and in some games no stutters. I´ll see if XP helps.

 

in COD4 10char

 

i have heard that many times.

that's why I got the d901c atleast 1 8800 card does what 2x 7950's should do in SLI in single mode.

and I have the option to add another card. if I want. and if they get their act together with drivers.

 

The problem is not so much frame count but missing/jumping/droping frames (a.k.a stuttering). I also get that kind of frame count (40/60).

I did not had the time yet to remove the battery and proceed with the tests as advised. Only now at 22:48 I had some time to sit.

Wife with the flew and a year old son giving me a lot of work and pleasure

Stay cool,

Trance

 

; ; please test as soon as you can, I wanna know if its just a bad battery that has to be replaced or if its my motherboard.

 

Yeah, but take care of the wife, and play with the son first - trust me, from someone who's been in the same place (daughter's 3.5 y.o. - wife's over the flu now ), wives need just as much maintenance as a computer - even more so (and deserve it more, too), and kids, well, they grow up so d**ned fast (I know it's a cliche, but trust me, once you have your own, you quickly realize that it's also the gods' own truth).

 

By no means do I pretend to be an expert; but I read somewhere on this website that some games do not fully benefit from dual core processors and likewise some games do not benefit from Sli very much if at all.

It was in a thread that compared the models of two laptops manufactured by Toshiba. I believe one model sported dual Nvidia 8600m GT's and the other was toting a single 8700m GT card. It was assumed that 1 8700m GT is roughly equivalent to 2 8600m GT's (according to 3dMark06 results [I believe that it is optimized for SLi]). Similarly, we assume that 1 8800m GTX is equivalent to 2 7950 GTX's in SLi (according to 3dMark06 results); therefore we are assuming that 2 7950 GTX's will perform seamlessly in line with a single 8800m GTX. Obviously that is not the case, that is why we are all here. And it is why it is not your hardware or drivers, it is the games and their improper Sli optimizations.

 

Ok, I had the opportunity to do some further testing

#1 Remove all USB devices (external)
Done. No effect.

#2 Only on battery
Done. No Effect

#3 Remove the battery (new)
COD4 with SLi enabled seams to run much worst without the battery then with it.

I have some more tests to do.

#4 Use an external audio card (I have one)

#5 Remove my internal TV card (although I don't have any drivers installed for it)

About test #3. I was expecting no changes in behaviour. What does this mean? Honestly this is weird and can become a problem if one want's to put a third HDD.

bwhxeon, do you have any ideas what can cause this difference in behaviour and how can I sort it out?

Trance

 

I'm not exactly sure exactly why it got worse. In fact I was expecting similar results to clevoguy. I have another test for you, run wprime and also try prime95 if you can. Prime 95 should be allowed to run at least for a hour and just run the regular test. wprime will test your processor and prime95 should test your entire system. Post back with your wprime score and if prime95 detects any errors. If your wprime score is higher than it should be it could be a sign that your motherboard is bad and any errors with prime 95 would reflect this as well.
As for the system running worse without the battery in, that just doesn't make sence, unless your adapter is the problem. >.> this only happens in COD4 or does it happen in any other games?

 

well if it matters any i figured out my fps crashes was related to not having vsync enabled in supreme commander. when that is enabled all is fine, although i do get a 25% performance hit with it enabled.

went to my brothers house to do direct side by side comparisons and becnhmarks with his desktop rig. he has a c2d e6300 @ 1.8ghz and 8800gts 320 graphics card. his cpu is stock speed and his gpu is bios-flashed to the OC (overclocked) version that you can purchase from various vendors. the only difference was his monitor was only a wsxga (1680x1050) resolution which he ran at that and he did not run vsync on since he does not need to (and i do otherwise my fps crashes as mention above).

he got 37.6 average fps compared to my 33 fps average. now, i did not overclock my graphics cards so i am fairly certain that i can match his average fps if i do. i then loaded up identicle saved games with fraps running in the backgroun to see how our systems performed side by side. suprisingly i was getting 50% more fps while the camera was zoomed all the way out, and he started to pull slightly ahead when the camera was zoomed all the way in a certain spot.

both our monitors supported 1600x1200 resolution so we set them at that and the in-game fraps bench was virtually tied with me still having higher fps when camera zoomed out. so i was very please with the resutls. an sli 7950gtx 512 laptop can go head to head with a desktop 8800gts 320 card.

so i am deciding to keep the laptop since it has proven itself to be as fast as an 8800 gpu, which i thought it would be in the end. sli still needs ways to improve and i hope it does. sli laptops can only get faster from here.

 

"this only happens in COD4 or does it happen in any other games?"

I'll have to try with ther games as well. I only have two games, Civilization IV (this one does not push the machine) and COD4. Once Assassins Creed is out I'll test with it as well.

Meanwhile I'll check WPrime, Prime95 and 3dMark06 to make as you suggested. If scores are so different maybe the system is getting less power under load then it should get.

By the way, I got myself am external hard drive from WD with 500Gb. "Only" 100€. I also got Acronis True Image and made all backups. Feature wise the software has all the features one could need to fully backup and restore the system, even detects RAID. I did a complete system backup of both Windows Vista x64 and XP partitions on may RAID 0 disks. If something goes wrong I simply boot from the external drive (the BIOS detects that this drive is installed) and Acronis takes over by presenting a nice user interface for us to use to restore the system or repair it. No more full reinstalls and lost data Yupiiii. I strongly advise people to do this on their Clevo's, it does not cost that much.

Trance
PS: The reason why I'm focusing on COD4 is becouse supposedly the game is tailored to get better results with SLi on, if not just the same. Even has an SLi option.

 

Sorry guess I posted that info too quick... needs qualification, so ...
Im' running 2 7950gtx's under Windows XP with drivers 169.28 from laptop2go (that's off the top of my head...not at home now).
For that the recommended setting was single card for cod4. Don't know if another driver rev / OS changes that or not.
On the sound card thing... One problem you'll have is you will have to manually disable the sound card hardware IN WINDOWS. You may also have to disable the loading of the audio drivers too.
Unfortunately, there is NO bios setting to disable the mobo audio (one of my many complaints about the bios) which would be the best solution before adding another audio device.

 

Hmmm.
It may not be the battery per se.
There is a battery charging driver that is loaded when the battery is in.
Can't exactly remember the name ... batt.sys or something like that ...
I only know about it because on one occassion I forgot to turn on the
power strip I was plugged into so I got a low battery warning eventually.
When I turned it on the charging indicator came up in the sys tray and then
viola.... blue screen... The culprit was the battery charging driver.

 

That "may" be true but you are assuming the problem is caused by the video cards or drivers and that hasn't been confirmed yet. In fact I would say that
is probably not the problem since I get it in XP with dual 7950gtx's both in sli
and in single card mode and other previous posts had other configurations and os's and get it too.
Let me add one other thing here too I hadn't thought of before....
I ONLY get this stuttering in COD4.
Not in any other game I've tried since getting my 9260.
It doesn't do this in Crysis, Counter Strike or cs Source , Soldier of Fortune 2 or the new one (can't rember name), Quake 4, Unreal tourn 2004, doom 3/doom resurrection, sin/sin episodes, far cry, prey, fear yada yada yada.
Maybe it's just the darn game

 

@eleron911 -

@DFTrance,

I still don't have the solution, but I do have a more definite idea of a possible source for your stuttering and, more importantly, some reasonably simple diagnostic utilities to use.

A canvass of the large number of google hits that come up when searching on SLi and stuttering suggest that there may be a problem with the way that Windows (and in particular, Vista) processes interrupt requests, both during the IRQ itself and afterward, using so-called deferred procedure calls or DPCs.

Basically, when an IRQ is accepted, it generates a so-called interrupt service request (ISR), which is processed at an interrupt level that pre-empts all user-mode processing and other processes and threads that have been assigned a lower level. A DPC is also processed at an elevated level, lower than an IRQ, but still higher than user-mode (aka passive-level).

The problem, in a nutshell, is that some poorly written code, typically device drivers, spend too much time doing nonessential stuff during either an ISR or a DPC which, because those are executed at an elevated level, will cause a cascading delay affecting any process that has been blocked by the ISR or DPC.

Many of the hits that I found through googling on SLi, stuttering, and DPC concerned audio professionals with very sensitive audio processing software that was stuttering, a result that appeared to be caused by slow DPC processing, aka DPC latency.

So, although I do not know enough to state with 100% confidence that this is also the source of your stuttering, there is a way to check, using the following tools:

1) A DPC-latency utility, DPC Latency Checker by Thesycon, which can be downloaded from here: http://www.thesycon.de/deu/latency_check.shtml

The actual d/l link is: http://www.thesycon.de/dpclat/dpclat.exe

This utility won't identify a specific process that is generating undue DPC latency, but it will indicate whether or not your system is suffering from DPC latency. If that is the case, based on running dpclat.exe, the next step is to try to determine the source of that latency. From what I've read concerning the diagnostic and event-tracing tools included in Vista, it should (may??) be possible to run the performance and reliability monitor included in Vista to detect the DPC time incurred by all of the processes running on the system when the performance and reliability monitor is invoked; unfortunately, I don't have access to a copy of Vista right now, so I can't give any step-by-steps.

2) The other tool that should be able to display the DPC latency for each running process is Process Explorer, originally from Sysinternals (since swallowed up by MS). The current version of Process Explorer can be downloaded directly from this link: http://download.sysinternals.com/Files/ProcessExplorer.zip

Again, I haven't had time to fully explore Process Explorer, so I cannot give a step-by-step right now; however, I've played with it a little before (looking for other things on WinXP) and it's a fairly straight-forward utility with quite a lot of power.

Since the stuttering shows up when you're running in SLi, it should be possible to pick up any DPC latency problems even without going into any of the games you've been getting stuttering in, so long as you run something that makes use of the GPU, so I would start the utilities (dpclat.exe first) with SLi enabled, and then start "exercising" the GPUs with things like opening multiple windows, grabbing one and waving it all over the desktop, or running a game or some other graphics-heavy application in a separate window (and not full screen) - if possible - to see what sorts of results dpclat.exe gets you. If that shows an elevated DPC latency, the next step would be to run Process Explorer under the same conditions and see if you can identify which process or processes are spending too much time in DPC processing.

Meantime, as I have time available, I'll see if I can't find something more specific.

Also, do you know what SLi mode the system is running in when you get the stuttering? As far as I can tell (based on the NVidia literature I've perused), NVidia SLi basically comes in two flavors:

• alternate-frame-rendering (AFR), in which each GPU renders a separate frame, with the two GPUs alternating, so that, e.g., GPU1 does frames n, n+2, ..., and GPU2 does frames n+1, n+3, etc..., and
• split-frame-rendering (SFR), in which each frame is split into two pieces along a horizontal line, with GPU1 doing the top part and GPU2 the bottom part, and the actual split moving up or down to balance the load on the two GPUs.

There are situations in which one mode is preferable to the other, and (although the NVidia literature I've perused so far doesn't say so) I would think that it's possible that a poorly written driver for another device might have a greater impact on one mode as opposed to the other. I think that you should be able to check which mode is running in the NVidia control panel.

 

Lolol here is what mine says in Vista x64 just by browsing the internet (DPC Latency Checker):

"Some device drivers on this machine behave bad and will probably cause drop-outs in real-time audio and/or video streams. To isolate the misbehaving driver use Device Manager and disable/re-enable various devices, one at a time. Try network and W-LAN adapters, modems, internal sound devices, USB host controllers, etc."

Will definitely have a look at it further.

Thanx,

Trance

 

Thanks for the heads up
I can`t read all of it though,my mind gets jizzy after the first 2 paragraphs and I drift into blissful ignorance.
I`am assuming you have more sugestions to stop the stutter. SO woohoo

 

Not really suggestions to stop the stutter but rather more ways to diagnose the cause and then hopefully to stop the stuttering.

Hmm so far from what Trance reported, it seems to be getting somewhere.

 

Unfortunately nothing as good as that yet. Just a possible line of enquiry - deferred procedure call latency - that appears to be a hobgoblin for Vista, particularly for high-end audio people. Basically, the first tool, dpclat.exe, is a quickie utility to determine if there is any high dpc latency in the system, and the second tool (either Vista's performance monitor or Sysinternal's Process Explorer) to try and find the service or process that's causing the high dpc latency.

One other idea I'm sort of nosing around is whether the SLi driver might not be tripping over its own feet on a two-processor system since, as MS states in its whitepaper on "Scheduling, Thread Context, and IRQL,"

It just strikes me that somewheres at the bottom of all this, NVidia's left a bug in that causes service requests from the two GPUs to trip over each other's interrupt requests and DPCs on a multi-processor system.

 

Thank you Shyster for this new approach:

The software suggested diagnosis problems both on Vista and XP. Yes, on XP too. I tried to disable almost possible drivers (Sound, USB Hosts, Wireless LAN, Gigabit Lan and so on). While I was doing it, the number of DCP latency occurrences have gone down, but still the it was diagnosing problems, both on XP and Vista.

I only tried to disable the GPU drivers on Vista. And guess what, no more DPC "spikes".

I don't know yet what the problem is. Drivers or IRQ "conflicts" with some other device. I'll try run Everest when possible to check how are IRQs distributed amongst the internal devices.

I have not yet figured out how Process Explorer might help diagnosing the process that may be the cause of the problem, this considering it is not a driver/hardware problem.

By the way, this would happen both when SLi is enabled and when it is disabled on XP. More often when SLi is enabled. So indeed people reporting stuttering issues even on a single card might have something to learn from this thread.

It would be interesting indeed if someone else also did this test on his/her system (d901c) just out of curiosity.

By the way, I have a desktop too ... no DPC spikes at all.

Trance
PS: Interesting enough the stuttering in the game when in SLi coincided with the DPC spikes as far as I could notice. Also I have a Q6600, so it a little more then a dual.

 

View attachment 16405

Unfortunately, that does suggest that it is the Sli driver is one of the primary players in the problem; although it doesn't clarify whether the problem is strictly with the SLi driver, or that driver's interaction with other drivers and the system.

It is possible that there is some artifact in the driver that shows up regardless of whether or not SLi is enabled, but whose effect on the system is diminished when the Sli is not enabled (e.g., because all it does is check something and then drop out once it receives a negative response).

The fact that it happens (or appears to happen) in Vista only when SLi is enabled suggests that Microsoft's enhancements to interrupt handling from WinXP to Vista may have actually yielded an improvement in OS functionality. In which case, I'll have to read through MS's whitepaper on "Interrupt Architecture Enhancements in Microsoft Windows Vista" sooner rather than later - perhaps that will yield a clue.

With respect to Process Explorer, I'll try to play around with it some more to see if I can tease out the DPC functionality of it - it may be able to help identify the particular module that is causing the high DPC latency (or, at least, identify the module suffering from high latency - it's possible that what's happening is that the SLi driver is locking up all of the cores for a long time because it has an ISR or DPC scheduled on one core for both GPUs, which would effectively block all other lower-level threads, etc, from being processed on the other core(s), thereby causing another otherwise innocuous driver to suffer from high latency).

If Process Explorer doesn't pan out, there's a Microsoft whitepaper (which I can't find right now ) that explains the improvements in Vista related to performance monitoring that includes references to the commandline tools available to generate trace reports and read them. That particular whitepaper indicated that there was a means to measure DPC latency on a per-module basis, which would allow us to determine which particular module was experiencing high latency, and thus point us to a possible solution.

Just as I was typing this (and furiously googling for that d**ned whitepaper) I did come across this blog post, ISRs and DPCs, The Silent Killers, which explains better than I can the basics of ISRs and DPCs and their effect on a system.

It also contains links to some of the tracing utilities I mentioned above, including this MS Technet step-by-step webpage on Vista Performance and Reliability Monitoring, which might be a useful guide to getting into the performance monitor that ships with Vista and setting it up to monitor the %DPC Time on the services and processes currently running on your system. Again, I'm afraid that I can't do a lot right now to help in figuring out to set it up as (i) I'm away from my home system (the one I can experiment with ) and (ii) I don't have Vista, so I can't really try it out first (although I may stop in at a _Bestbuy or something on the way home and "pretend" to be interested in one of the systems their hawking ).

 

Ok, since this thread has to do with digging into the bowels of Vista, I thought I'd post this little link here to download a large suite of Sysinternals utilities:

1) They can be d/l'd from this website: http://technet.microsoft.com/en-us/sysinternals/0e18b180-9b7a-4c49-8120-c47c5a693683.aspx

2) The direct d/l url is: http://download.sysinternals.com/Files/SysinternalsSuite.zip

For those few who don't know, Sysinternals was a small company owned by, among others, Mark Russinovich, who co-wrote with David Solomon one of the best romps through the guts of the Windows OS, Microsoft Windows Internals, 4th Ed.

The book is amazing (at least to my limited little mind ), as are the number of useful little utilities that can be had for free (I am still shocked that MS didn't simply kill off Sysinternals when they bought it - I guess that, even though MS has most of us by the cojones, there's at least someone else who has MS by the cojones, too ).

 

@DFTrance, just so this doesn't get hidden in the junk-pile that was my last post, I'm posting separately.

I think I've figured out how to use Process Explorer to get a bit of an idea which process(es) are potentially running into DPC latency problems - although it's only an indirect measure.

When you're in process explorer, go into the view menu, click on the "select columns..." menu item, in the dialog window that pops up, click on the tab labelled "process performance" and then in the top half of that item, tick the boxes marked:

• CPU Usage
• CPU Time
• Context Switches
• Context Switch Delta

The number of context switches, and in particular, a jump in context switch delta that correlates with an increase in the total number of DPCs (which is monitored in the aggregate as a pseudo-process under Process Explorer), should be a guide in determining which process is suffering from high DPC latency.

If you then right-click on a suspect process from the main Process Explorer window, you get a context menu with a "properties" option. Click on that, which will bring up a new window showing the properties of that process as recorded by Process Explorer. In that new window, go to the tab labelled "Threads." Under "Threads" is a listing of all of the different threads running under that process, with a column item showing context switch delta for each thread. If you highlight an individual thread by left-clicking on it once, that will provide data specific to that thread in the dialog section below, which will include the number of context switches that thread has accumulated. In addition, the "module" button on the lower right side of the dialog window will become active - click on that and a new window will pop open showing you the specific dll the thread is loaded from. (The function loaded from that dll is, I think, shown on the main listing for the thread itself).

Hopefully, if I'm correct that (based on the Process Explorer help file, which I searched for the term "DPC") a high number of context switches is indicative of a DPC latency problem, then this process may help you to identify the specific dll/function that may be implicated in the stuttering problem.

 

Trance.. I' m putting you into a trance.... Repeat after me..

I'm going to order the d06 mobo, and 8800m videocard upgrade kit....I'm going to sell my 8700's and other mobo on ebay or in a buy and sell mag/paper.. to compensate for the cost of the upgrade.

I now have better preformance that 2 8700's and don't have to contend with drivers, or SLI. Unless I so choose in the future when 8800m goes SLI in d901c.



then don't worry be happy now.

 

Okay checked my settings in EVE, I'm running at 1920x1200 32bit color w/8bit stencil, Pretty much everything checked and on the right hand side I have it set to Shadows: High and HDR: High.

I think I checked them as extreme before and it bogged way down. (I think that was right after the Trinity patch though) Hope that helps!

 

Well guys,

I think I'll stop persuing a solution as it is taking me too much time. I already disabled all the drivers that I can, it still stutters in COD4 and DPC reports that I have driver issues.

The only thing left to do is send it to my supplier to get analised but I can't due to work. Maybe one of these days (summer holidays).

By the way, I installed Vista SP1 and 3DMark06 scores are comparable do prev SP1. I also tested DPC latencies with the Clevo drivers and still driver problems were reported.

One thing to note, is that although in Vista i get better scores then in XP, gaming is more fluid in XP. I can tell you why. It is becouse DPC latencies in Vista are generally higher (even non video drivers). I thought that Vista was suppose to improve the way drivers are built and comunicate with the core.

Trance
PS: By the way, I don't think this is a COD4 problem. It may be a problem that shows more in COD4 but other games should have it to some degree.

 

I'm sorry I couldn't be of more help. Unfortunately, I don't work with computers day in and day out, so I'm quite the amateur here.

From what I've read, MS has made changes in Vista's handling of interrupts that, eventually, will result in a better, more responsive, system; unfortunately, the key word is "eventually." Right now, in many instances the Vista methodology is just extra overhead without any benefit. Also, I don't think that MS really thought through how a Vista-compliant driver and a legacy driver that was badly ported to Vista would interact.

Finally, since you only get the stuttering when SLi is engaged, I am convinced (granted, on insufficient evidence and knowledge) that NVidia's implementation of the Vista driver methodology is buggy in that it ends up "tripping" over itself - probably because the driver assumes the ability to do simultaneous interrupt servicing on multiple cores, but does not take into account the fact that, in SLi, there is a sufficient amount of shared data that each core is going to be trying to lock the other cores out while the first core processes it's ISR or DPC.

This would not be a problem (or would be a qualitatively smaller problem) when SLi is not engaged because there is a lot (by orders of magnitude) less shared data between different ISRs/DPCs and thus the cores don't lock each other out nearly as frequently.

In fact, if the games you're playing had been optimized to use the 4 cores in your Quad, the problem would probably be even worse, because then you would have 4 cores simultaneously trying to lock each other out.

Anyway, I completely understand the too-much-time issue; if I come up with any brilliant solutions in the meantime, I'll post 'em, otherwise, good luck with it.

 

Thank you so much for your time Shyster1. I sure appreciate your help and your nut picking brain is awesome.

What strikes me has strange (so me considering a service request) is that I get reports on driver issues on XP too. Something I was not expecting.

As a final remark on Clevo quaility from someone that does not own any other high end system.

A product that gets serviced for no usage issues:

* Zero times is good
* 1 time is ok
* 2 times is bad
* 3, is very bad

I'm still on 1 time due to LCD ribbon problems, so I'm ok (totally avoidable if Clevo used some proper ribbon connect the LCD to the main board). The second time will be bad lolol. This considering that my Toshiba Tablet PC M200 (more then $2500 dollar system back then) never got serviced, and this tiny laptop has fallen on the ground (broke the LCD) and still runs as supposed including Pen & INK (5 years usage). With this TOSHIBA I honestly got what I payed for even though it wouldn't even run Civ IV (32 MB video card), now my Clevo I'm not quite sure yet.

Trance
PS: Peoples mileage may be different.