• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Vsync, microstutter, and SLI/Crossfire

G

geraltofrivia

Limp Gawd
Joined
Jun 12, 2012
Messages
409
When running parallel GPUs, assuming Vsync is on and FPS stays above the monitor's refresh rate, is microstutter effectively eliminated? I mean if each frame is sync'ed to a screen refresh (and screen refreshes are spaced consistently), there would be 16.7ms between each frame (assuming 60hz), regardless of whether you are running one GPU or SLI/crossfire. Is that a fair statement or am I missing a part of the equation?
 
I think this has everything you need to know.

I think it's summed up here: "By running the game at a setting where your graphics cards are able to output more than the monitors refresh rate (that is, the maximum FPS the monitors are capible of; the pixels on your screen can only change so fast) microstuttering is eliminated completely. Most monitors have a refresh rate of 60 or 70Hz, meaning you would need 70 or 80 FPS to eliminate microstuttering."
 
Microstutter, as typically defined, occurs only on dual-GPU configurations. Other forms of stuttering can happen on all configurations.
 
I still think microstutter is a old wives tale, something people have passed along to scare people into consistently upgrading.

6950cf owner - microstutter twice - ( I was at 250+ fps in heroes of newarth [fixed with forced AA] / other was a bad patch from bf3, fixed next day).
5870m cf owner - microstutter a couple of times, until I figured it out ( crossfire cable was loose )
 
At this point, claiming that microstutter is an old wives' tail is akin to claiming that barometric pressure is a fabrication. We have barometers; we can measure this stuff; it's absolutely there. Both AMD and NVIDIA do things in hardware to reduce it.

When you're only kicking out frames every 16ms or so, interframe latency can get pretty bad, and multi-GPU microstutter only makes it worse.
 
wonderfield said:
At this point, claiming that microstutter is an old wives' tail is akin to claiming that barometric pressure is a fabrication. We have barometers; we can measure this stuff; it's absolutely there. Both AMD and NVIDIA do things in hardware to reduce it.

When you're only kicking out frames every 16ms or so, interframe latency can get pretty bad, and multi-GPU microstutter only makes it worse.
Click to expand...

16ms frames are fine (60fps). It's when the frames take significantly longer than that, that it starts to feel uneven. My question was basically, if I am running Vsync with hardware that never falls below 60 fps, will there be any difference between a single GPU vs multi-GPU. I believe the answer is no.

In other words, say I'm playing Dirt3 @ 720p (a situation where minimum FPS >60 all the time for a GTX680 card) with Vsync on. A GTX 680, GTX 680SLI, and GTX690 should all provide exactly the same frame latencies, a consistent 16.67ms per frame. Only when Vsync is turned off does the SLI setup theoretically suffer from a greater variation in framerate latency (a.k.a. microstutter). But this variation in framerate latency would not be noticable in this case, because these cards will all be running >100FPS all the time. Say we changed the resolution to 7680x1600 and kept vsync off, now the average FPS would be a lot lower and variation in frame latency would be more visible. 680SLI will appear smoother than a single 680 due to higher framerates. However, a 690 with hardware frame metering will provide a smoother subjective experience than 680SLI despite pumping the same FPS due to more even frame latency.

If I'm wrong on that I'd like to be corrected, but please be rigorous.
 
Last edited:
geraltofrivia said:
If I'm wrong on that I'd like to be corrected, but please be rigorous.
Click to expand...

I don't think you're wrong, but I do think that minimum framerate is a better target for the sort of measurement you're basing things on rather than average frame-rate.

Obviously that point is moot if you're sailing along at a minimum 100fps in all situations. V-sync will cap it at 60fps regardless of whether you're pulling 1000fps or 100fps. But, where a system with a single card might drop under 60fps in some situations, a dual-card configuration with the same game settings might not. Basically, I agree with what you're saying ;-)

Also, at least according to this article, it would appear that hardware based frame metering has been in place for quite some time.
 
Last edited:
geraltofrivia said:
In other words, say I'm playing Dirt3 @ 720p (a situation where minimum FPS >60 all the time for a GTX680 card) with Vsync on. A GTX 680, GTX 680SLI, and GTX690 should all provide exactly the same frame latencies, a consistent 16.67ms per frame.
Click to expand...
Vertical sync merely controls the swapping of buffers — it doesn't control how quickly each frame gets rendered and how consistent the rendering times for those frames are (how low the delta time is). Each frame is being swapped at bang-on 16.667ms, but frames are still being rendered in 11.1ms, 10.3ms, 13.6ms and so forth. Because each frame is just a 'sample' of the game's 'constant' simulation, the fluctuations in frame times can account for significant stutter, and vsync is not particularly helpful in reducing that. The best way to negate that is to push out frames as quickly as is possible such that the delta times can be reduced, and each 'sample' of the simulation is closer to a constant rate. Theoretically then, the SLI solutions will appear smoother because the average delta time between frame times will be lower.

geraltofrivia said:
Only when Vsync is turned off does the SLI setup theoretically suffer from a greater variation in framerate latency (a.k.a. microstutter).
Click to expand...
That is, at least to my knowledge, correct.
 
Appreciate the informative responses, I understand this better now. Every time the 690 pops up on Newegg I buy it, feel guilty, and cancel. But I think my raging lust has finally subsided.
 
My understanding of how/why microstutter happens after reading several articles about it reads about the same as everyone else posted, but I've seen a few different things as well. I'll have to try and find them.
 
Micro-stutter is quite real, not a wives' tale, and has been measured (at Techreport). It's the uneven generation of frames, and it can occur on a single card, though far more likely on 2 or more.

I found that I didn't notice micro-stutter on any game except BF3 with my HD6950's; with that game, going to a single, slower GTX670 was actually a significant upgrade.
 
IdiotInCharge said:
I found that I didn't notice micro-stutter on any game except BF3 with my HD6950's.
Click to expand...

If you are having stuttering issues running BF3 in SLI, do this at an elevated command prompt and reboot:

bcdedit /set useplatformclock true

I know this is one of those things that seems like snake oil but try it before you bash it. It works wonders for me and for others as well (http://www.neowin.net/forum/topic/1...n-bios-and-os-for-better-performance-and-fps/) To be fair, there are an equal number of people for whom this command has done nothing or has resulted in mouse ghosting (which does not happen on my system).

To undo this change, type

bcdedit /deletevalue useplatformclock

and reboot.
 
Last edited:
Just be aware that there's an extraordinary amount of false information in that thread. Frostbite no doubt uses high-resolution timers for anything that's time-critical and low-precision timers for things that aren't. This is standard practice in any game engine. To my knowledge, there is no synchronization of any of these timing methods (they start running when you boot and stop when you shut down), so any 'overhead' of having them all present is going to be nil.
 
Last edited:
wonderfield said:
Just be aware that there's an extraordinary amount of false information in that thread. Frostbite no doubt uses high-resolution timers for anything that's time-critical and low-precision timers for things that aren't. This is standard practice in any game engine. To my knowledge, there is no synchronization of any of these timing methods (they start running when you boot and stop when you shut down), so any 'overhead' of having them all present is going to be nil.
Click to expand...

You might be right, I don't really understand the technical pinnings behind it. I just notice a night and day difference in BF3. It doesn't have as much effect on any other game, and I haven't noticed any sort of unintended side-effects.
 
Log frame times with FRAPS with and without that switch and see if there's any difference. If there is, send an email to Johan Andersson about it and see what he might have to say.
 
You must log in or register to reply here.
Back
Top