To test a heat sink and fan assembly to the limit, a computer is not the best option. With some of the many variables, which can be attributed to the computer alone and completely outside the control of the tester, software and hardware results can be skewed to the point of being outright wrong. Things that can be controlled are often ignored and sometimes forgotten.
Factors contributing to unreliable test results that can be controlled by the tester:
- Air temperature and humidity: When doing a comparison, temperature and humidity should be kept the same, or at least as close as possible.
- Location: Testing should be done in an area that has little air movement or an area with a reasonably controllable environment.
- Sunlight: Testing in direct sunlight will skew results.
- Electronic devices: Most electronic devices expel heat. Avoid testing near such devices, if this is unavoidable, make sure that the device is in the same state for all testing; preferably off.
- Other environmental considerations: Consider air movement; as limiting air movement will eliminate many variables.
- If central air is being used, the testing should be done near the thermostatic control unit as this will limit many of the temperature variances that occur in a structure between on/off cycles.
- Fans: Box, osculating, ceiling or any other type of fan should be turned off.
- The testing should not be near an air duct.
Eliminating the biggest contributor to inaccurate results (the computer):
The computer needs to be eliminated from the equation if a heat sink is to be tested accurately.
- Background operations that are controlled through the services settings panel in the administrative control panel need to be completely eliminated, as these may cause random CPU cycles.
- Legacy buses (dumb buses) need to be disabled as they are polled by the CPU.
- Motherboard monitoring hardware and software are not always dependable and accurate.
- CPUs and Chipsets have been known to have temperature monitoring issues.
Building an external test unit is the only way to eliminate the factors that are beyond the tester’s control.
Components and tools used for testing. Only the fan headers are used on the motherboard. Molex to fan header adapters are available.
A hole needs to be drilled for thermocouple insertion. The hole above is 7/8" deep with a 5/8" counter bore to allow the thermocouple ball to fit tightly.
A thermocouple can be used if you wish to test specific points on the HSF for variance, which can indicate a poor performing or bad/damaged HSF.
Using water as a heat transfer medium allows for more control of environmental factors that are otherwise left unchecked.
- Humidity is controlled and maximized
- Temperatures are controlled (as long as air movement is eliminated)
- Air density is affected but will not be a factor that can be readily measured.
Using water will allow for repeatability in testing. This allows the temperatures to be easily stabilized and the maximum temperature will usually be in a predictable range; thus allowing for data sets to be formulated. After a point, head to head tests will no longer be necessary.
Keeping the meters on during the heating process can help identify trends in HSF units and also identify potential problems.
Testing temperature scaling and humidity is a necessity as they will work together to give a more controlled testing environment.
Using a humidity of 90-100% in the testing zone will help better control temperature for dependable and repeatable results.
Though the temperatures should remain uniform, there is no guarantee. ALWAYS CHECK TEMPERATURES AT MORE THAN ONE POINT!
Video of fan on a cool down run.
Testing:
- Although a passive test, the process of heating up the HSF shows the ability to absorb and dissipate heat with no fan assistance.
- Variance testing will show the HSF’s ability to evenly spread it’s heat (this is best done with the fan off), which is critical for the HSF to respond to rapid changes in heat output. If there is a large variance between the closest point to the CPU and the furthest point away from it, then the HSF generally will not deal well with rapid heat output changes or the high heat output from overclocking.
- Testing of heat pipe efficiency is similar to standard variance testing. Testing the heat pipe at the points closest to and the furthest from the CPU will show the efficiency of the heat pipes.
- Building on the heat pipe test, a heat pipe to fin variance test shows the efficiency of the bond between the two materials/components of the HSF. This test shows design weaknesses and may show manufacturing flaws that show up from time to time in production runs. The causes for this are dependent on many factors, and if a HSF is found to be poorly made, the manufacturer should be contacted so that it can be corrected. It is never the intent of a major manufacturer to sell a bad product. If it is found to be a poor design then the tester or reviewer has little choice, a spade is a spade and a bad product should be shown for what it is.
- The fan on test shows which HSF is more capable of dispersing heat into the surrounding environment.
There are many other types of tests that can be done with an out of the box setup. The testing above is just a start.
Data collection: Keeping track of information allows the tester to build a database of results. By studying the variances, from run to run, choose a control heat sink to work with as a standard for comparison; a benchmark of sorts. The best way to record and store the information is with a meter that will log the information and allow output in a standard form that can be used in something like Excel or Open Office.
Obtaining a testing pan and plate: Most of these items are easy to acquire, save the box or pan. Local fabrication shops usually have plenty of scrap around and will usually sell it at a discount rate. If you are a product tester, the shop may cut you a break for a little free advertising in your review/blog, or you can part with the ~ $70 – $200 and just have it made.
That is all for now. Feel free to comment or ask questions and I will be happy to help in any way that I can.
























9 Comments
James you are correct. This testing is not really of use to the everyday user but it allows them to know what to look for in a thorough HSF test.
The days of sticking a cooler in a box, running some bench marks, recording heat results fed to you by potentially inaccurate software and hardware and repeating with the next HSF while working in an environment that has many variables that are not controlled will end. The playing field is getting very competitive and that 2* difference that helps a customer decide on which HSF to purchase needs to be a real number not just a guess.
“Gee that is what the software told me and I guess it does not matter that the door was opened 20 times during the test” is what we get now because that is the way it has always been and there was no real need in the past because it was usually a blow out with one HSF showing clear superiority and at times dominance.
Today we just can’t trust 2 or 3 degrees that could be the result of many different factors. We need to have better testing because the people doing the buying need the best information possible.
Thank you for the link.
Great testing methodology, but the data analysis will need to be very clear and strong to provide any benefit to those not in the heatsink design industry. Most of the information gathered here won’t be of any use to people looking for differences between product a and product b, for a purchase.
I’ve always liked Frostytech as they do offer some good info and data about cooling capabilities. By using a heat plate they remove all the system variations.
http://www.frostytech.com/testmethod_mk2.cfm
Those tests (db) would be great. I don’t know about starting them up at 7 but running them should not be a problem.
Thanks for the ideas, not just for me but everyone who reads this. People testing products need to know what is important to others. In the end this is about the guy/gal out there looking to buy a product after all.
Agreed. All fans must be documented for cfm and static pressure and watts consumed. So a popular mix of various 140mm and 120mm fans with their stats documented would fit the bill. This setup would also allow you to log the db levels to create a sound log too documenting just how noisy each heatsink fan combo would be. You could also vary the voltage down to 7 volts if you wished using a reostat or resistor. LOL… have we missed anything?
Great Idea. Unfortunately I did not think of that. There are so many ways to test a HSF it is really unbelievable, as you have pointed out.
As far as fans. All fans are not created equal. The blade design has a lot to do with overcoming the back pressure that can build up in some HSF assemblies. Generally a fan with a large fairly flat blade can push more CFM but when it encounters any resistance the whole CFM idea flies out the window.
As to the last part of your comment, right on! If the data is kept from run to run you can turn this into a science of why it is better. Unfortunately I do not do enough HSF work at present to build such a database.
Archer
First. You should be building a heating unit that is only putting out so many watts of heat with various set points. example. 125 watts, 150 wats, 175 watts, 200, ect. Possibly setting a base line of what is acceptable (Pass/Fail) would be helpfull to people wanting to cool overclocked cpu’s. The same example could be used for air flow too using set points for cfm. 50, 60, 70, 80, 90, 100, ect. Using this established basis for measurement, you could test all your heatsinks with very valid data on how well they preform under various stress loads and how much air flow they need to hit pre-determined temperature levels. This would be very valuable to all of us in making purchasing decisions… Blackheart
There are a lot of variables involved inside the BOX. When the computer is running all possible services need to be shut down. Taking screen shots will even cause the CPU to cycle. If you did everything exactly the same way with the exact same atmospheric conditions then you can get close but not as close as testing two at the same time in the same place.
-”Humidity also makes a NOTEABLE difference in temperatures? Can you prove this please?”- Could you please give me a quote from the article? I did a search of this page and the only place I find the word noteable is in these two comments. I guess I could be wrong but that is what the search tool said.
Well? I just don’t see it.
Thanks
These points:
Background operations that are controlled through the services settings panel in the administrative control panel need to be completely eliminated, as these may cause random CPU cycles.
Legacy buses (dumb buses) need to be disabled as they are polled by the CPU.
Are you kidding? So long as its the same across all testing that wouldnt matter. Those items by themselves or together in the majority of cases would result in a negligable difference if any what so ever. CPU polling of buses causing a temp rise? Wow. If the same services start up and do the same thing, it should matter as its the same across all tests. Not to mention, a test with any sort of time involed should negate the minimal variance in ‘cpu polling of legacy items’ and services.
Humidity also makes a NOTEABLE difference in temperatures? Can you prove this please?
This article, while somewhat informative, is potentially just as flawed as some of the articles you speak of Im afraid. Feel free to prove me wrong and support your findings.
Thank you,
Jack.
[...] This post was mentioned on Twitter by Kevin S, Marlin, TechREACTION.net. TechREACTION.net said: New: Rewriting the Book on CPU HSF Testing (http://bit.ly/bGl8J5) [...]