Core i7 Waterblocks, Roundup #1

[Vapor]

Preface
Sorry for the delay on this...GOOC messed up my schedule, as did me spending a couple weeks trying to make my own Koolance Midplate (didn't work out that well!)...anyway, this is the XS version of my first i7 waterblock roundup, which can be found here: http://vapor.skinneelabs.com/i7/Round1/Round1i7.html. I have more blocks enroute (or soon to be)

The What
I'm aiming to obtain and graph real world CPU temperatures and seeing how they change as flowrate changes. This is in addition to just getting a nice comparison between blocks and nozzles and midplates, etc.

In my opinion, this data will be very useful to readers: it will show how waterblocks compare at a given pumping power, it will show how waterblocks limit flow compared to each other (though I will not be mapping component PQ curves), and most of all, it will show how much a waterblock responds to flow.

This test is of an Apogee GTZ, a Koolance CPU-350, and a D-Tek Fuzion V2 on a Core i7 processor. I only tested 2 of the 5 single-die FV2 nozzles, and I don't think I'll be testing the others--the gains are so small from what I saw on my previous tests and the block in general isn't that competitive.

The How

• The processor I'm using for this test is my C0/C1 i7 920. I'm running it at 21x196 (4120MHz) at 1.46V loaded on a Gigabyte EX58-Extreme. It is unlapped. I'm running 2GB of G.Skill DDR3 1600MHz. All heatsinks on the board are stock and I have fans blowing over the MOSFET area for added stability. The video card is a 4850 1GB with VF830 running in the top slot. The board is sitting on my desk alongside my Odin 1200W PSU and DVDRW and HDD drives.

• The watercooling loop I'm using is very untraditional, but allows me to test the way I want to test.
  • It consists of an MCR320 + MCR220Res sandwich with three Sanyo Denki "San Ace" 109R1212H1011 fans and 5 (3+2) 120x120x20mm Yate Loons cored out as shrouds. The sandwich allows for high-dissipation ability in a compact setup. The 'Res' part of the MCR220Res is used not as a res, but as a drain port.
  • For pumps, I use three MCP350s modded to MCP355s. One is attached to an XSPC Res Top and the other two are attached to the EK Dual Turbo Top--all three are in series. The MCP attached to the XSPC Res Top I can modulate the supply voltage freely between 7.65V and 12.65V. The two MCPs on the EK Dual Turbo Top always run at 12V. I have six pump settings I run with every mount: 1) All three on at full speed, 2) XSPC Res Top only (at 12.65V), 3) XSPC Res Top only (at 10V), 4) XSPC Res Top only (at 7.65V). The ability to consistently vary flow is a huge aspect of my testing.
  • I use a Koolance FM17 for my flowrate measurement. I recognize its lack of 'professionalism' (compared to a King Instruments flowmeter or something of that ilk) but still use it because it 1) covers the entire range I anticipate I'll be testing in (~.2GPM up to 3GPM), 2) outputs measured flowrate every second via RPM wire, which is logged for the entire test and then averaged and has thus far brought on extremely consistent results.
  • Loop order: CPU block -> MCR220Res -> Koolance FM17 -> MCR320 -> XSPC Res Top + MCP -> EK Dual Turbo Top + 2xMCP -> CPU block. Air flow order: in -> temp probe array -> MCR320 -> San Ace H1011 -> MCR220Res -> out

• I do a 5 mount test, each with their own TIM application. It takes a ton of extra time (each block takes 5x4x120min to test), but it's totally worth it. In the words of Martin "It's not uncommon at all to see mounting variations as high as 2 degrees or more, so with only one mount, that error is 2 degrees. When you mount 5 times and average those results, your standard deviation is significantly lowered and the overall testing confidence improved. In addition multiple mounts serve as a means to validate data, because each test is carried out again and again, chances are if some variable is affecting results, it will show."

• I have 10 temperature probes in use: 6 Dallas DS18B20 Digital one-wire sensors on the intake of my sandwich, 4 Intel DTS sensors in the processor.

• For temperature logging, I use OCCT v3.0.0.RC1's internal CPU polling that is performed every second on all four DTS sensors and is automatically output to .csv files. I also use OCCT for loading the CPU. For intake air temperatures, I use Crystalfontz 633 WinTest b1.9 to log the Dallas temp probe data on my Crystalfontz 633. I also use WinTest b1.9 to log fan RPM and Koolance FM17 flowrate output. Martin et al. have been over the many advantages and qualities of the Crystalfontz + Dallas temp probe combinations--it really is a wonderful setup and aids the testing process immensely.

• For processor loading, I find OCCT v3.0.0.RC1 to be extremely competent. It provides a constant 100% load (so long as WinTest b1.9's packet debugger is fully disabled) and is extraordinarily consistent. It allows me to, in one button push, start both the loading and the logging as well, which helps. I immediately also start to log the Crystalfontz data simultaneously. I run a 120 minute program, the first minute is idle, then I have 115 minutes of load, and then 4 minutes of idle. The first 26 minutes of load are thrown out as warmup and only the remaining 90 minutes of load are used for data compilation. During the last 4 minutes of idle, I adjust the pumps to be prepared to immediately begin the next 120 minute program.

• For TIM, I use MX-2. It's plentiful, representative of what a lot of people use, and has no break-in period. I use the dot in the center method and validate all my mounts to be at least "good" visually upon removing the waterblock.

• Like Martin, I have found that simply using processor temperature minus ambient temperature is not adequate for Intel's 65nm Core 2 processors. However, I have found that ambient and core temps scale perfectly fine (1:1) with i7.

• My graphs....they may look a little different than what you've seen before, but I feel they're a great way to show all the individual data points from testing while also highlighting the averages of that data. I've termed them Planet/Moon graphs--each data point get its own moon and 3 moons get averaged into a planet. From there, the planets get a line drawn through them (not a trendline, just a regular line with the "smooth line" option checked). For something like flow vs. cooling, I've found Excel's trendlines to be totally incompetent. This applies to HSFs too. In fact, I have yet to see a situation where they do work involving flow vs. cooling.

• While I do 5 mounts, I discard the best and worst mounts and use the data of the middle three. I still show you the data from the worst and best, but it's not used in the 'big' graphs or the averages calculations. I take the middle three to hopefully get a fair representation of what to expect from the block in how it compares to other blocks.

Charts
The Big Daddy chart...all my data in one graph, presented as conveniently as possible!




Isolated charts....these are for a different representation of the data to make certain aspects of it easier to see.

Full pumping power = all pumps on


Medium-high pumping power = XSPC Res Top pump only (at 12.65V)


Medium-low pumping power = XSPC Res Top pump only (at 10V)


Minimal pumping power = XSPC Res Top pump only (at 7.65V)




Tables
Tables of the data graphed













More Graphs
Another graph for your enjoyment...it's something I'll be using in every waterblock test and comparison: 'Typical' performance of a block, i.e., how you can expect it to perform compared to other blocks with little regard to the rest of the loop. The data graphed is flow vs. temp and the flowrate data is the harmonic mean (great for averaging rates) of the 4 settings I tested and the temp data is the average of the 4. It's a pretty interesting way of representing the data and really shows how, in general, a block performs in regards to both flow and temperatures.

Typical performance graph:


Conclusion
This is XS, the data is really all that's needed, IMO.

n.b., after I finished these tests a couple weeks ago, I fried the EX58-Extreme I was using...forcing me to close up Round 1. I'll be retesting the GTZ and the KL-350 in Round 2 though Also planned for Round 2: a new testbed with a wider range of flowrates tested (both higher and lower flowrates) and constant flowrate through the radiator. I'm also working on an empirical way to 'rate' the flow dependence of a block, I'll post a graph of that when that's ready

[classifiedE760]

nice post u might want to throw in that mix Heatkiller V3

[hellcamino]

A good read, thanks for the test! That koolance block really seems to shine no matter what flow rate huh?

[shazza]

Thanks, Vapor ... very easy to follow. Looking forward to the next round.

[Oberon]

That koolance block really seems to shine no matter what flow rate huh?

It's a good thing, too, considering how restrictive it's purported to be!

[NaeKuh]

nice post u might want to throw in that mix Heatkiller V3

Probably if you can get HK to send vapor a block to test? :P

[Oberon]

I'll let him borrow mine if it ever gets here!

[troelsm]

Nice post. Very informative and easy reading

I'm so glad i joined XS. To actually see reviews and tests that are non biased and scientific is fantastic! Keep up the good work

[skinnee]

Excellent work as always!

Proud to have this hosted @ skinneelabs!!!

[Hondacity]

excellent work... results seem familiar

[eth0s]

Thanks for the test results! It looks like the KL 350 is not hampered by lower flow rates after all.

My Comment: I disagree with your decision to forego a conclusion section though, for two reasons: (1) you are leaving open the possibility that others might exploit your hard work by "interpreting" your data for you; and (2) by leaving it up to the reader draw his own conclusions, you risk the misinterpretation of your hard work by the untutored masses. It is sad to say, but most people are too lazy to try to figure things out for themselves, and will folllow the first person who tells them what to think.

Off topic: Rich Rodriguez is not much of a football coach, I am sorry to say. It's gonna be a rough Fall in A-squared.

[skinnee]

Off topic: Rich Rodriguez is not much of a football coach, I am sorry to say. It's gonna be a rough Fall in A-squared.

Must be a Buckeye fan...

[Vapor]

My Comment: I disagree with your decision to forego a conclusion section though, for two reasons: (1) you are leaving open the possibility that others might exploit your hard work by "interpreting" your data for you; and (2) by leaving it up to the reader draw his own conclusions, you risk the misinterpretation of your hard work by the untutored masses. It is sad to say, but most people are too lazy to try to figure things out for themselves, and will folllow the first person who tells them what to think.

I have a conclusion in the full review in the link in the beginning and wavered whether or not to post it here. I think if there were overlapping curves and any sort of 'conflict' in the data, I'd shed my thoughts on the data....but with the data like this with each block having noticeably different temps, it kind of seems like a waste of words.

The one thing I probably could have commented on more was flow dependence, but I'm saving that for when I finally settle on an algorithm

[troelsm]

I would agree that it would need a conclusion if it wans't for the first graph. In my mind that is pretty much a conclusion only as a picture not as words

By the way, i always hear how easy the GTZ mounting is compared to other blocks, can you say just a few words about the dificulty of mounting a CPU 350 Vs the GTZ (if there is any). The GTZ reputation seems more like some marketing thing. It's not like anyone is gonna care if it takes 5 minutes longer to get a proper mount

[denice25]

that's a great post....

[Vapor]

By the way, i always hear how easy the GTZ mounting is compared to other blocks, can you say just a few words about the dificulty of mounting a CPU 350 Vs the GTZ (if there is any). The GTZ reputation seems more like some marketing thing. It's not like anyone is gonna care if it takes 5 minutes longer to get a proper mount

Definitely

The GTZ and the LGA1366 Fuzion V2 have the easiest mounting systems I've ever seen. You just line up the block over the socket and screw the screws down until they don't go any more. It takes 40 seconds max and comes out the same every time. I think the LGA1366 Fuzion V2 is severely lacking in pressure though....

The KL-350 is also pretty easy....you assemble the backplate/rod assembly, put it on the board, then put the block on and screw down the thumbnuts. The 'difficult' part (comparitively) is that the assembly is an infinite-travel kit. Because they don't have mechanically defined stops or limits, you can overtighten or you can unevenly tighten really easily. I used calipers to measure that each thumbnut was the same distance down as its three siblings and made sure that each time I mounted down the same amount each time.

The KL-350 system is really flexible and high quality (about as good as any infinite-travel kit will be), but the GTZ's mounting is brainlessly easy. Incidentally, I think Gabe (Swiftech's CEO) mentioned that they'd be releasing an infinite-travel mounting kit for GTZ's on lapped processors because the existing kit wasn't providing enough mounting pressure on a lapped CPU.

[Oberon]

Must be a Buckeye fan...

Better than being a Wolverines fan these days

ASWho?

[alacheesu]

Thanks, Vapor!

Unlapped CPU and still the GTZ is soundly beaten. That's pretty conclusive evidence.

[Vapor]

Thanks, Vapor!

Unlapped CPU and still the GTZ is soundly beaten. That's pretty conclusive evidence.

You're welcome

I'm not really sure what went wrong with the GTZ. There's nothing that could have gone wrong in the grand scheme of things. The bowing plate is oriented the right way, I followed Swiftech's instructions as to orientation relative to the socket, I tightened down all the way, etc.

[dengyong]

Nicely done.

[Oberon]

I don't think anything has gone wrong, personally. The GTZ is a good block, it's just not top-of-the-line anymore.

[Vapor]

Yeah, I worded that poorly

I was comparing my results to Gabe's in my head, that didn't come through at all though.

[PatRaceTin]

wow interesting

thanks for sharing

[HESmelaugh]

Very good stuff! I love the presentation, you've found some great ways of showing lots of data in one graph without it getting really confusing.

[Vapor]

New graph to throw into the mix!



The idea behind it is that the "perfect" block is a block that gets great temps and responds appropriately to flowrate. Something like the GTZ is fun because I can see the gains from increasing flow, but also somewhat unrealistic--getting a really high flowrate isn't free, both thermally and monetarily. That's not to say that a "Flow Dependence" value of 0 is best. Rather, it's merely a way to classify the blocks; there are many plausible cases where an end-user may want a certain amount of Flow Dependence, whether that's really high, really low, or right in the middle. This is a numerical way to describe the Flow Dependence of a block based on the tests I've done.

The reason why I'm choosing to graph Flow Dependence vs. Temps instead of Flow Dependence vs. Flowrate? Well, in my opinion, "Flow Dependence" is a metric of what flowrate does. Other than at the CPU block, flow seems to be pretty overrated. There are tiny gains to be had here and there, but a tangible gain is very, very rare (of course there are situations where low flow becomes harmful to overall performance, but those aren't particularly common here at XS). That's why I'm isolating flow dependence vs. temps, rather than including flowrate.

The mathematical formula, for anyone wanting to follow along at home, is such:
10 * the square of the geometric mean of the three temp differences between the four pumping powers I tested. If you want some numbers to follow along, here are the numbers from the GTZ: 10*(geomean(.52, .52, 1.17))^2 = 4.64. I've tried to calibrate it such that a high flow dependence (a block that can't get enough flow) goes pretty high and that a block with moderate flow dependence is valued at around 1.5 (arbitrarily). Of note, at no point in the equation is flowrate considered--I figure the general restrictiveness of a block is already shown enough in my graphs, I don't need to further complicate an already convoluted equation with it when, in the end, the metric is only intended to show what flowrate does for the block, rather than what the block does to flowrate.