Laptop SLi rantz (A desktop view)

Hi,

Most people on this forum probably know me due to my rants over the 8700M SLi due to stuttering and so on. To spice up why I get upset here is graph around what is going on in the desktop world.



Techreport

What basically jumped to my eyes in this graph is that an SLI config of card X outperforms a a single card X+1.

So tell me why the need to disable SLi in mine to get better performance in SLi in a Clevo is justifiable once again (or simply a bummer)? (that is, to play COD4 and Assassins Creed without stuttering)

Trance

 

Interesting review.

Did you notice that both the 8800 GT and the 9600 GT ran slower in SLI than in non-SLI in COD4?

 

Driver issues?

 

I`m guessing bad drivers, poor SLI support,fragmented disks,it`s anyone`s bet on this.
But Clevo`s SLI implementation kinda sucks,I`ll bet that much.

 

sager has new drivers out for vista. give those a try.

trance is talking about a quick and constant stutter at hot spots within the game making multiplayer quite unplayable since you really need a constant smooth experience to compete at high levels. i really think this is driver related issue and the current nature of sli.

sli is still quite young and has a ways to go for improvement. we are at the mercy of nvidia here and i do not think it is related to how clevo engineers their products.

for example in crysis, i did a quick test at a hot spot. in sli it would give me 33 fps but produce the stutter. then at the same spot in single gpu mode i would get 23 fps but it appears to be smoother. this pretty much negates the benefit of. but i will say again it must be a driver related issue for the most part. it is also probably an issue related to gpu power. some hot spots are more taxing than others so thats where the stuttering will occure.

i must add, also, that the benefits of sli are still at very high resolutions. i mean, it is not possible to play crysis at all high settings in single gpu at wuxga resolutions or wsxga becase the average fps is too low. but, turn on sli and it is possible then as it you get a healthy 60-70% fps increase. but, there will be hot spots with stuttering even if the fps meter says 30+.....

so i think there is a trade off here. you can play at a choppy 18 fps in your native high res with single gpu mode or you can play at 30 fps with stuttering with sli enabled.

 

no, the stuttering is not related to hard drive performance or memory or anything other than the gpu's and sli.

another explenation i have is that maybe our q6600 are bottlenecking us in sli mode. everything performance thread i read out there state that you should OC to at least 3.0 ghz to relieve bottlenecking. maybe the stuttering is related to this.

 

Maybe so. With the E6850 I've never seen the stuttering you seem to be describing in any games including Crysis.

 

hhmm, if you understand fully what the stuttering is, then maybe our cpu's are indeed bottlenecking sli. that would be a the best scenario for the stuttering as all you need is to swap the cpu.

i must add that COD4 and crysis do not use 4 cores, just two. so maybe in a game that does take advantage of quad cores, like UT3, there may not be any stuttering?

 

ARGH are you willing to do the pin mod to get the CPU to 3.0 Ghz and see if the stuttering will totally dissapear?

 

yes i will try it tonight or tomorrow. i have to go buy some rear window defogger kit from auto store.

 

That`s cool. Dexgo had the same idea, and with the pin mod his 8800M GTX got him to 12k. So I`m pretty sure the CPU is the bottleneck for the SLI in most of the D901Cs...

 

The best that I can come up with (I posted a more detailed discussion much earlier, and cannot find it right now) is that the quad CPUs are, in effect, a bottleneck because the L2 cache structure results in a lot of cache coherency transactions that require communication across the FSB (because of the 2x2-core design, cores 0 and 2 cannot talk to cores 1 and 3 directly, but only across the bus). This causes serious problems because (1) cache coherency transactions are critical, and thus have a very high interrupt priority, and (2) the FSB is not point-to-point, which means that each time a cache coherency transaction is done, the bus is monopolized and all other communication is blocked, including communication between the GPUs and anything that isn't on the GPU cards, such as system memory or DMA access to a drive.

Since SLi has two GPU processors blazing away, and both are required for frames to go smoothly, either within each frame, or frame-to-frame, depending on which mode SLi is operating in, the undue latency caused by the coherency transactions monopolizing the bus means that if even one of the two GPUs gets blocked too long on the bus, the entire graphic system comes to a screeching halt because neither GPU can keep going past its current frame until the block is lifted.

OC'ing to 3.0GHz appears to smooth out the stuttering because, at that clock, the CPU can clear the cache coherency transactions quickly enough to prevent perceptible blocking of the GPUs on the bus.

 

we will find out soon enough. i will try with just black electrical tape first and block the two pins so i don't have to waste time conductive ink. i will simply run the crysis test and maybe a quick 3dmark test but will rervert back to stock clocks as i do not want any damage to the mobo because of this.

 

Yea, but if your score and test will remove stuttering, you`ll have proven that SLI 8800M GTX needs at least 3.0GHZ cpu power,be it dual or quad.

 

I've not been thinking that the Quad maybe the problem. If it is I'm suprised but not that much.

I'm eager to know more about your experiment ARGH. What Shyster said makes some sense, but I'm not really sure. I would expect the a bus not to get overloaded that easily. Indeed if that explains the stuttering, then is more a sign of a weak motherboard/implementation then anything else. Something that one expects from a cheap motherboard, not in a high end system.

The article is refreshing. Apart from other things (such as usefullness) it does not follow a standard review/analysis template that we got so used to. Sometimes when reading a review I don't know anymore if we a reading about a product X or product Y as they look so similar.

Trance
PS: Maybe I'll try OC mine if you are successfull just for the fun of it. I don't think thought that I would keep it overclocked, since I couldn't stand the fans running full speed all the time.

 

pin mod done!

i am happy to see that the VID did not change from stock


now on to see the resutls in crysis....

 

@DFTrance:

Actually, since the FSB design is Intel's it's not so much a matter of it being a cheap motherboard so much as it is a matter of a thoroughly outdated Intel design. That's why Intel is moving to a new system communication system, now known as Intel Quickpath Architecture.

As for the issue with the current FSB getting saturated with cache communications, it is a serious issue, particularly with multiple core CPUs, as indicated in the abstract for an article from 2002 entitled An Effective L2 Cache Replacement Policy to Distribute the Bus Traffic in the SMP Node, originally published in Proceeding (373) Parallel and Distributed Computing and Systems - 2002. (Unfortunately, I don't subscribe to that website, so I can't get a copy of the actual paper ). In particular, the need to go onto the FSB to do cache coherency between cores 0 and 2, and cores 1 and 3, imposes a very big hit on the latency of the FSB.

 

I`m willing to bet that stuttering will be almost obliterated with the 3.0 quad now.

 

aaaahhhhhh!!!

the pin mod was not stable! kept hard booting. i start her up for the first time and log in here to post the success, so i thought.

then i load crysis and load a map and it hard booted. kept rebooting. very unstable even with max fans.

so i re-did the pin mod with the defogger kit again and it would not post. i went back to stock now.

sorry folks, i almost had it.

damn, was so close....!

 

Thanks for trying!
Where are all the other brave men?

 

maybe i did a poor job of applying the conductive paint. but i thought it looked pretty good to me oh well;

 

i am going to try it again and this time do it with electrical tape and only doing one pin. it appears to be easier and works better from what i read.

 

ok folks i did the tape mod on 1 pin this time and it was just as unstable as the window defogger trick.

BUT.....i did manage to load crysis and test it out!

with an overclock to 3 ghz and 1333fsb the results = same stutter! it did not resolve the stuttering at all.

i exited the game and tried to run it's benchmark but the system was unstable are hard booted. it could not even boot into window's as it kept hard booting so doing this mod is not really an option. i would advise against it. maybe if you have an older bios it may work. i have the newest bios and it may be incompatible with this pin mod.

so it is not related to the cpu speed, it seems. i am going back to my "it's the nature of sli drivers" issue with this. maybe some people don't realize they have stuttering and only focus on the high fps count so thats why we are not seeing it more widespread reported.

there you have it folks, more bad news regarding the stutters. i will try asking the dell m1730 folks to see if they experience the stuttering in sli.

 

got that from m1730 owner so it appears to be a common problem with sli.

 

Damn, and I was so sure the CPU was bottlenecking the GPUs.
So driver issue all the way.
Time to go grab Clevo by the ... and get them to release A GOOD SLI driver.

 

give this thread a read

Evidence of CPU Bottlenecking for 9800GTX's in SLI

http://www.evga.com/forums/tm.asp?m=360398

 

I read something similar on the net, and that`s why I was so sure that the q6600 was holding back the SLI and translated that into stuttering.
I still thing 2.4 is not enough for SLI
But at least we`ve eliminated one of the probable causes...

 

but i just proved that 3ghz played no effect in the micro stutter so i do not think we are cpu bound.

 

Yes, but the CPU is still bottlenecking your SLI.
So the stuttering is not bottlenecking related, it`s something else.Driver maybe the most obvious choice.

 

looks like we are not alone with the stuttering. did a qiuck google search of sli micro stutter and looks like it is a commonly widespread problem with multi gpu platforms. drivers are being blamed.

here is a good article.

http://www.pcgameshardware.de/?article_id=631668

 

another thread on this. it affects all multi gpu users;

http://www.rage3d.com/board/showthread.php?p=1335357611

 

Mheh, see? SLI is still poorly supported,even after all this years.

 

yea it is. i enabling vsync might help with the micro stutters, though. won't hurt to try.

 

It will also drop the frame rates to the lowest values
But then again, VSync tends to give a better impression of overall smoothness.

 

doing some more reading on this micro stutter and it is just getting the attention of the masses as sli has become more popular enough. before, all the sli users were either to proud of their purchase or too stupid to even realize micro stutter so they never complained about it.

oh yeah, vsync will not help at all i have readl. i also tested it in crysis and there was no difference, it seemed.

 

Hm.
VSync will mostly help with screen tearing...so
It`s not the CPU bottlenecking, VSync doesn`t help.
I really sugest a complaint to the supplier.
I mean come on, you pay 4000$ to get a stutter machine?

 

it's not clevo's fault it is the gpu makers lke nvidia and ati who have not addressed the issue. it's a shame, really.

 

What is a shame is that the same system in the desktop world can be had for less than 1/2 of that price. And it still performs better.
When you have too much power,the stuttering is not an issue.

 

you are paying for mobility going with the laptop world. that's the whole point.

 

Gents, as I've maintained for a while, at bottom the problem is bus latency - a problem that is greatly aggravated by the architecture of the L2 cache in the current Quad-cores; namely, the quad is actually two dual-cores glued together into an ersatz quad-core. In particular, while the cores on each dual-core core can maintain coherency without accessing the FSB, coherency between the two dual-core cores requires bus access, and that eats up a lot of clock cycles - by my estimate, each cross-bus coherency transaction consumes 5.5 bus cycles in addition to the normal 14 clock cycles used for non-bus coherency transactions.

One of my magnum opera on the subject is posted here. In particular, that post references an Intel whitepaper, CMP Implementation in Systems Based on the Intel Core Duo Processor, that discusses issues relating to L2 cache coherency problems in core duo processors.

Now, in terms of ARGH's results, I'd be a little leery of drawing definite conclusions on the basis of an unstable OC as that could lead to all sorts of other issues that would affect the bus, among other components. Also, it could have something to do with the fact that you're running a Raid 0 array as well as a separate third drive, and they're all 5400 rpm drives - the Raid array is going to entail I/O operations on both drives, which will increase bus latency since the raid controller on these systems is a software controller, not a hardware controller (and thus must consume its own share of CPU clock cycles and bus cycles).

Finally, did you shut everything else down, like bluetooth, wireless, and etc? In particular, I believe all of these systems ship with bluetooth, and if that module isn't shut down, the repetitive polling is going to impose a severe latency cost on the system as it generates constant hardware interrupts. The same goes for Wi-Fi wireless; if it's not locked down tight, it'll be constantly polling for networks (think hooker on the corner ).

In terms of the desktop/notebook comparison, I haven't gone looking for the stats from Intel, so I don't know if there's a difference, but if the desktops generally get a wider FSB than in a notebook with an equivalent FSB clock frequency, then the desktop will still suffer less stuttering from bus latency than the notebook will.

 

I know that article already. But the issue varies a lot from motheboard to motherboard implementation. My opinion is the following:

1) Since the d901c motherboard was designed prior to the launch of the 8000 series, it was actually designed for the 7000 series. The overall architecture does not address the specifics (timings balablabla) of the 8000 series cards.

2) The 8000 series cards realy suck in terms of stability when compared with the 7000 series. I mean in SLi of course.

I will upgrade my laptop to the 9000 series when it comes out if better results regarding stuttering and mouse lag are posted. By then I hope Clevo can update the motherboard including the chipset.

I will try to overclock mine when I have the time to focus on this task. But as I said before I doupt it will help.

As for the price that one pays for gaming mobility being justifiable or not when compared with desktops. If "everything" went smoothly I would argue that it might with some specific needs. But it is not the case with my setup. It took me 6 months to realize that. For more or less the same price one could by an SLi desktop that is faster ($1500-$2000), an XBox360 ($400) media center extender and play some games on the TV), and a fast laptop for work ($1000-$1500 granted not that good to play games). This I think is quite a lot of tech.

But let's not go that way and focus on the present issues.

Trance
PS: I would buy mine again with the lowest card possible and the systems above. This becouse I enjoy the power of my system for work.

 

Unfortunately, I'm not sure if just waiting for the 9xxx series will solve the problem since the core issue revolves around the FSB, which is why Intel is dropping the FSB and going with its new Quickpath system; in order to upgrade around the FSB, you'll definitely have to change the motherboard.

EDIT: Intel actually has a utility out that can be used, in part to diagnose and spot bus latency and bus saturation issues, VTune Performance Analyzer. One of the accompanying whitepapers, Analyzing and Resolving Multi-core Non Scaling on Intel® Core™2 Processors discusses some of the relevant issues, and how to use VTune to identify bus latency/saturation issues. I'm not technically sophisticated to use it in that manner (and I don't yet even have a D901C I could experiment on even if I was ); however, perhaps some of the more technically adept here could give it a go, at least with the trial evaluation copy, to see if it provides any insight into the stuttering problem.

 

Darn it, so no upgrades is that is the case.
But Shyster, not only SLI has the stuttering, I have it too

 

shyster, i don't think your quad core fsb theory holds up;

-the dell m1730 owners experience the micro stuttering as well with their dual cores.

-you can simulate dual cores by setting the affinity to only two cpu's (on same die like core 0 & core 1) through task manager.

-i did the pin-mod and it did not help with the micro stutter at all, regardless if it was not a stable mod, it still managed to load the game for the test.

-just google sli micro stutter / sli micro stuttering and you can easily see this is a common issue with multi-gpu's through all platforms, including desktops. it has been a problem since sli was introduced 4 years ago.

-the mucro stutter issue is just beginning to be realized globally since multi-gpu setups have become popular enough.

-people percieve things differently and most just watch their fps counter and say "oh yea there really is a perfomance gain" when in fact the micro stuttering almost defeats the high fps gain.

eleron911, you o not have micro stutter. single gpu's do not have this issue. you have to experience it in sli to know what it's like.

 

@ARGH,

Fair dinkum, although I still think that it plays a role; I won't get pestiferous about it unless I find something else more definite/useful along that line of thinking.

One question - is the micro-stuttering worse when SLi is configured in AFR (Alternate Frame Rendering) or SFR (Split Frame Rendering)?

 

99% of games use AFR. nvidia has all but abandoned SFR, anyway.

the problem with sli drivers and settings is that if you sometimes change the default "nvidia recommended" settings (which does not even tell you what setting it is) to somethine else for testing reasons or whatever, you permanently lose sli performance in the game and the only thing you can do is re-install the drivers. this, i am sure, further causes more confusion out there and thats why we have people saying "sli gives me no gains in my game!" and stuff like this.

i have tried SFR in crysis and most other games i have and it does not work. it simple causes an horizontal green line to run accross the screen.

 

I still have stuttering,is it macro stuttering then ?

 

Ok, so for purposes of my cogitating (ouch, that hurts! ) and speculation (yes, the moon is still made of green cheese , it's just really dusty, like the bits of swiss that fell under the couch ), I'll just worry about AFR.

 

For you, maybe it's just valve-timing?

 

I wonder if there is any stuttering in real life.
I`ll ask my grandparents
I`m outta ideas on this one...I supose it`s up to Clevo and Nvidia to fix it...or maybe Ati`s Crossfire has the issue also ?