Jump to content


Member Since 26 Mar 2006
Offline Last Active Jan 27 2008 09:30 PM

Topics I've Started

[NEWEGG] DEAL: ABS TAGAN 800W PSU $100 shipped AR

22 December 2007 - 12:34 PM


$180 + free ship - $80MIR = $100

Here you guys go... a 800W PSU by Tagan... top notch quality for $100 measly dollars AR. Keep in mind though, this is an uber stict rebate from newegg themselves. You have two weeks. I bought one to replace my 700W OCZ.

Remember it's 2x6 2x8 PCIe connectors.


Bottlenecks Re-examined: Lightmark an OpenGL Benchmark

11 November 2007 - 04:10 AM

Bottlenecks are the point at which one factor of a system slows down the rest. A similar concept is the 'rate limiting' step in chemical reaction chains. In computers, specifically gaming, they appear frequently. Despite their common occurrence, the general populace seem to have little or no knowledge of how exactly they work and effect system performance. As such, bottlenecks are important to study and characterize more clearly so that a firm grasp might be obtained by all and will be reflected in their choice of hardware.

The experiment was run on the new Lightmark graphics bench mark with an eVGA 8800GTX at 650/1800 clocks, a Q6600 processor at 3.0Ghz and DDR2 ram at 1000MHz and 5-5-5-12 timings. This was all on a DFI Infinity 975X/G motherboard.

The procedure was to set all quality fields in the drivers to the highest setting (meaning highest quality) and then take two sets of data points. One set of data points would be collected in a progressive series of benchmark runs of standard 4:3 resolutions from 640x480 through 1600x1200 at 0xAA/0xANISO. The second set would be collected in the same resolutions, except at 16xQ CSAA/16x ANISO, also set in the drivers.

Res ******FPS 0x/0x****FPS 16x/16x

The % pixel increase over the baseline (640x480) curve, you can clearly see that it increases exponentially. Since graphical output (FPS) of a given card working as fast as it can is inversely related to the graphical load, you can see that the graphical output will be decreasing exponentially. The CPU load is not as dependent on the raw pixel load, as the GPU was made specifically to do that job. However, it still will receive a SMALL amount of extra load as it must direct process and direct more information to the GPU for graphical processing. From this we can conclude that the CPUs exponential curve will be significantly shallower than the GPUs. This situation is ripe for what are considered bottlenecks. At the lower resolution the graphical load will be light allowing the GPU to output extremly high FPS. The CPU's load will lighten, but very little, allowing it to only output a few more FPS. Since the machine can only output as many FPS as the SLOWEST COMPONENT of the system you'll have what is called a bottleneck, since the CPU will not be able to output as many FPS as the GPU. The observed FPS output of the system will therefore be only as much as the CPU can output.


In the first graph, there is an extremely high amount of agreement between the exponential trendlines of the data sets and the actual data set, this is shown by the 0x/0x data set being nearly perfect with an R value of ~1. The single curve shown is consistent with a CPU bottleneck as there is no obvious intersection of outputs where a steeper graphical output would overtake the CPU curve as the resolution increased. There is to be noted that at the 1600x1200 resolution 0/0 value is less in agreement with the exponential curve than the rest of the data points in the set, but only slightly. With that result truncated from the data set the R value increases further to ~0.99 for the exponential trendline, indicating better accuracy. This could be caused by the GPU just beginning to intersect and become the limiting component. Another test at a higher resolution would show with more certainty but there was no monitor of that resolution to test on.

The 16x/16x has a very high R value indicating accuracy, however, its R value is significantly lower. Upon closer visual inspection, there is clearly the expected intersection between the CPU output curve and the GPU output curve at 1024x768 resolution. At 1280x1024 and 1600x1200 there is an obviously steeper rate of FPS decline than at 1024x756 or lower resolution. To test to see if this is not an anomaly I made two separate curves of the single 16x/16x data set. One of 640x480 through 1024x756 and another of 1024x756 through 1600x1200.


The shallow, low resolution curve is clearly very close to the same curve as the fully CPU bound 0x/0x curve indicating that it is indeed a CPU bound section of the 16x/16x data set. It should be noted that the curve IS placed approximately 50FPS lower than its CPU bound homolog 0x/0x indicating that either AA or ANISO DOES have a negative impact upon CPU output.


The second, steeper curve created from the 16x/16x data set needs to be shown that it is actually GPU bound, and not a mysterious depression of CPU output. This will be done by comparing the observed data points to the theoretical values predicted. Because there are only two points of this curve that are unequivocally decreasing more steeply, analysis will be done on them, the 1280x1024 and 1600x1200 resolutions.

Theoretically, 1600x1200 resolution is approximately a 46% heavier pixel load upon the GPU than 1280x1024. From that, we can figure that the system output, if GPU bound would be relatively close to this value. Taking the 1280 res point and dividing it by the 1600 data point (as it's inversely proportional to load) we should see a ~46% difference. We see about ~39% decrease in performance, clearly supporting the claim that it is a largely GPU bound result!


It has become clear that both the CPU and GPU curves are exponentially decreasing under exponentially increasing graphical load. It has also been clarified that the GPU curve is steeper, beginning at a much higher FPS but sloping down quickly and finishing at a much lower FPS than the CPU. It is upon this common mechanism that virtually all bottlenecking occurs. To those who fear bottlenecking so much, there is such a thing as a GPU bottleneck as well. The only way to avoid this, is to ride that inflection just between being CPU bound and GPU bound. This can be adjusted by increasing graphical load by adding detail. But with this particular application and hardware, it's at 1024x756 res 16xAA/16x ANISO or, as best as we can tell, at 1600x1200 res 0xAA/0xANISO. Here is a hastily thrown together graph of how the GPU/CPU curves intersect.


It is also well to keep in mind that your LCD monitor, should it go over the venerable 1280x1024 resolution only has a 60FPS refresh rate. Meaning, your monitor is REALLY bottlenecking all performance above 60FPS REGARDLESS of graphical load or CPU/GPU balancing.

Deal: Yate Loon Clear with Blue LED fans for $4.99ea or $4ea @ xoxide

07 September 2007 - 05:03 PM


Need 7 120mm LED fans for your brand new CM RC-690?

Look no further than xoxide selling blue led yate loon 47CFM fans for $4 a pop and cheap shipping too!

Deal: Coolermaster RC-690 ATX Case $50 shipped AR. ZZF+Newegg

07 September 2007 - 04:08 PM


Take your pick. This is an amazing case for $70 shipped let alone $50 AR.

I bought one to replace an Ultra Aluminus that was destroyed by Fedex (who were EXTREMELY good to me about the damage and paying me for it).

Buy buy buy!

OCCT versus Orthos

18 August 2007 - 06:17 PM

After my latest testing of my G0 quad core I've decided that OCCT is a useless pile of . for stability testing.

At 2.85GHz running 2x custom Orthos with 200MB allocated ram per instance it failed in 8 minutes 40 seconds. Keep in mind my computer was HIGHLY useable in all this. I could check e-mail and surf youtube to watch "I like eating read carpet" scene from family guy over yet again.

I was perturbed.

So I loaded up OCCT the supposedly 'better checker' of the two and think that 'hey, it should fail instantly'.

It went for all 30 minutes. And when OCCT is working my computer SHUTS DOWN... I can't do ANYTHING else while it runs.

This is a revelation to me because people seem to pimp OCCT as a 'faster checker'. Yeah it's faster to suck at checking. It makes sense though as the 30 minute test stable system regularly failed in SMP [email protected] after a several hours on some WUs. I chalked it up to smp being a muuuuuch longer test. Now I know the truth, for all the glitz and monitoring garbage it sucks for all but the most basic gaming.

In short. OCCT is a piece of .. Stick to Orthos.