Test Report: Loop Order, does it make a difference?
Preface
This test is somewhat of a detour from my normal waterblock testing, but one that was worthwhile--answering a long-debated question: does placement of the pump in relation to the CPU block matter? Specifically, does the increased inlet pressure from placing the pumps directly before the block increase performance as suggested by many.
The What
While my normal tests focus on how flowrate effects temperature performance of blocks (and how they compare to each other), this one is only comparing two scenarios: pump immediately before the CPU block versus pump then "everything else" then the CPU block. Theory says that the pressure drop of a block at a given flowrate is a non-variable quantity, so there should be no change in flowrate (though it is still measured) between the various options, so this test merely focuses on the position of the CPU block in relation to the pumps and what difference in temperatures are present.
Inlet pressure and pressure drop should not be confused...this test is isolating the change in inlet pressure (via changing the position of components in a loop) and how that compares to temperature. If I were to change the pressure of the pumping system, that would change flowrate, but I am not. If I were to change pressure drop, I would be changing flowrate, but I am not. I am only testing what happens when you increase inlet pressure.
If an increase in inlet pressure increases the thermal performance of a block, the pumps-before-block configuration will be superior. Gains are reported to be as high as 2C.
If an increase in inlet pressure has no effect on the thermal performance of a block, the rads-before-block configuration will be slightly superior simply because water leaving the pumps (in my case three DDC3.2s at at least 12V) will be slightly warmer due to the heatdump of the pumps. The difference should be insiginficant, a small fraction of a degree, but it should be there.
In this test I will be examining three waterblocks: 1) the Swiftech Apogee GTZ, a block with moderate restriction that I have confirmed to respond well to increases in flowrate (and therefore turbulence); 2) the Koolance CPU-350, graciously sent to be my NaeKuh for this testing (and future tests) because it's not only a flagship block, but it's a high restriction block and also a block has that has been reported to have an increase in performance based on pump positioning; 3) the Fuzion V2 + 3.5mm nozzle....simply put, it's the most restrictive block I know to exist and that's a quality that some theorize to have an impact in this scenario.
It's important to note that this is, in no way, a comparison of the three blocks. While I am using my normal block testing test procedure (and therefore the data is viable for cross comparison), that is not the objective. I'm running a non-stock mounting system on the KL-350 simply because the stock mounting system was not available to me. Also, three DDC3.2s in series in a CPU-only loop is a ludicrous amount of pumping power and does not paint the full picture for block performance. Those tests are partially completed and will be done when they're done.
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 at ~1570MHz. All heatsinks on the board are stock and I provide airflow over the mosfets to aid 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 some processors. While my 65nm processors report an increase in CPU temps of ~1.22C for every 1C in ambient difference and I have to correct for it, my i7 processor does not have this deficiency and I've mapped out to be a perfect 1:1.
- 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
I have no charts for this test....just one simple table :)
Tables
All applicable data from the three blocks I tested in one table :)
Temps are adjusted for 21C....yes my 920 runs really cool, I hate it even though it clocks well.
http://img30.imageshack.us/img30/993/capturez.png
Conclusion
There's no change in flowrate and basically no change in CPU temps. The rad-before-block config performs slightly better, but the difference is insignificant (even with a lot of heatdump from the pumps). I think this myth is busted. Thanks for reading :)
