3770K IHS removal and results

Discussion in 'Overclocking, Cooling & Modding' started by graysky, Jul 25, 2012.

  1. graysky

    graysky ARP Reviewer

    PART 1
    Feeling somewhat curious about the reports that inferior Thermal Interface Material (TIM) ships from the factory inside Ivy Bridge (IB) chips, I found myself taking my new 3770K out of the safety of its socket this afternoon and on to my desk where it went under the knife. About 15 min later, I finalized the divorce of its Internal Heat Spreader (IHS) and its Printed Circuit Board (PCB). It was surprisingly simple to do; a standard razor blade (0.009") and a little bit of patience was all that was required. After cleanup and application of fresh TIM, I sought to put a nice story together for you readers covering how to do procedure yourself and sharing my results and the methods used to arrive at them.

    Removing the IHS from an i7-3770K
    Maintain a level blade and gently insert it between the green part of the chip (PCB), and the silver part (IHS). I found it best to start on a corner. From what I've read, care needs to be taken not to scrap the PCB, as key parts of the chip reside very close to the surface. Slowly and gently, rock the blade between the two until it penetrates. Then slide it around the perimeter. See the pics to visualize the die so you don't push the blade in too far. The IHS will come off easily once you have completed severing the glue which is removed with gentle scraping with credit card or finger nails; isopropyl alcohol doesn't help much. When finished cleaning up both pieces, apply TIM to the die, place it back in the MB, and gently place the IHS on it. Lock it into place in the MB with the mounting bracket that will hold the IHS to the chip securely thus keeping you from having to glue down the IHS.


    I'm a pretty big fan of Arctic Silver 5 (AS5) and used it both on the die, and on the outside of the IHS. My "factory" configuration had a good 120 h of load/idle cycles on it. As you probably know, AS5 has a breakin period associated with it...200 h according to Arctic Silver Incorporated. One can argue that this claim is valid based on the delta temp data.

    Data Collection and Analysis
    I wanted to generate robust and statically valid conclusions about the efficiency of entire process; results are drawn from a fairly large data set looking at the populations of temperatures and VID values. Temps and vcore values were collected via lm-sensors driven by a simple shell script which queried it every 2 sec logging the results to a file (see the end of this section for the script).

    07-28-12 09:19:31 AM,1.280,66.0,58.0,63.0,65.0,60.0,1285,255,1225,255
    07-28-12 09:19:34 AM,1.272,65.0,57.0,62.0,65.0,61.0,1300,255,1216,255
    07-28-12 09:19:36 AM,1.272,64.0,59.0,63.0,66.0,59.0,1294,255,1226,255
    These data were annotated and distributions were analyzed to see if the different TIMs under the IHS really makes a difference. Note that there are too many variable to control for this sort of analysis to be 100 % iron clad. For example, TIM spreading variations, mounting techniques, variations in hardware, etc. Even room temp can't be rigorously controlled. My office is air conditioned and ranged from 75-77 F when I ran the stress tests. In retrospect, I would have located the PC in my basement which has very consistent ambient temps but hind sight is always 20/20!

    Methods of Stressing
    I use linux, but key stress testers are cross platform. Intel BurnTest for windows is based on linpack from Intel which is available for many platforms. The settings I used were 25k problem sizes and 25k leading dimensions with 4 KB alignment.

    On top of linpack, I ran a compile job looped in the background (nice=19) set to use 8 threads to further scarfs-up any unused CPU cycles.

    System Specs and Settings
    Asus P8Z77-V Pro
    Intel 3770K @ 45x100
    Cooling is an NH-D14 with both fans; my system manages their speed but they are both running on max for the stress tests (1,200 RPM for the 140mm and 1,300 RPM for the 120mm).

    The BIOS is running using a vcore in offset mode so the vcore is automatically controlled by the BIOS and is dependent on load. Mine is stable with a setting of +0.0200 and here are the other key voltages and settings in case you're wondering:
    VCCSA Voltage = 0.92500
    CPU PLL Voltage = 1.5500
    PCH Voltage = 1.06000
    CPU Load-Line Calibration = Ultra High
    CPU Current Capability = 140 %
    CPU Power Response = Medium
    I ran the stress test described above for ~2 h period and used the geometric mean of the temps per core as the "average" temperature over that time period. I repeated this for a total of 4 nights, but lost the data on day 1 due to an overwrite on my part! Here are the average corresponding temps per day; there is a nice decrease out to day 3 where it more or less plateaus off. Perhaps that is the AS5 "breaking-in." Also note the error bars correspond to the measured ambient temp which ranged between 75-77 F or 1.1 C. You can see that some values at day 3 and 4 are not different when accounting for this:

    As well, here is a plot of the delta temp, that is, the values subtracted from the stock results indicating the magnitude of temperature decrease:

    And to be sure this horse has been beaten well after it died, here are the results compiled in a table:

    For this example, a decrease in load temps was observed after delidding an Intel 3770K and replacing the factory TIM with AS5. The magnitude of the temperature reduction was not even across all cores, and ranged for -2C to -12C. The data are consistent with Arctic Silver Inc.'s claim that the TIM requires a break in period. This has to be one of the cheapest modifications to gain lower operating temperatures which can be converted into higher voltage and likely higher clock rates. The unevenness of the decrease is puzzling. Since the overall rank order of temps was retained after the TIM replacement, perhaps it has to do with some physical unevenness in the IHS, in the base of the HS, or on the CPU die itself. Investigating this is beyond the scope of this exercise.

    Supporting Data
    Link to my shell used to log the data.
    Link to my shell script used to run gcc in the background.
    Link to the entire data file (tab separated) should you wish to dig into it.

    PART 2
    The above analysis was conducted using both a non-lapped IHS on the CPU and a non-lapped heatsink. I have since lapped both parts and repeated the experiment. My results seem to confirm that lapping these CPUs give minimal albeit real benefits. Others have reported no gains.

    Lapping Parts
    The process of lapping in detail will not be reviewed here, but in summary, one uses wet/dry sandpaper and a flat surface (glass usually) to slowly and iteratively grind an uneven surface. The goal of lapping is not be to make a mirror surface, rather, it is to make flat surface.

    Lapping setup:

    Heatsink lapping (220 grit --> 320 grit --> 400 grit --> 800 grit --> 1000 grit). Read this composite pic from left-to-right and from top-to-bottom:

    As evident in the photos, the base of the NH-D14 is actually quite flat from the factory.

    IHS lapping ( 400 grit --> 800 grit --> 1000 grit). Read this composite pic from left-to-right and from top-to-bottom:

    As evident in the photos, the IHS on this 3770K was quite concave, that is, higher in the middle than elsewhere. "Flatness" was achieved in this case when no more silver color remained on the IHS.

    Stress Testing
    In addition to the linpack+gcc method described above, mprime (this is the linux version of prime95) running large FFTs was coupled with the same gcc compile stress to give another endpoint. By default, mprime runs with a background nice level (nice=19) and gcc ran with priority (nice=10). This is in contrast to the linpack+gcc setup where linpack ran with a higher priority and gcc ran with a background priority. This was by design.

    In the linpack stress, gcc was employed to add further stress since linpack does not stress all cores evenly during a given run. In contrast, mprime does a very efficient job leveling load across all cores for a given calculation. Here gcc was given priority over mprime since the very nature of compiling code will lead to uneven usage.

    Rather than showing a per-core analysis which would make for a rather busy graph (4 cores x 2 conditions), a more simplistic "Lapped" and "Non-lapped" average results across all 4 cores is shown for each of the stress methods:

    The delta temp spread for the averaged results ranged from 0 to -9 for the mprime+gcc experiments and from -1 to -12 for the linpack+gcc experiments.

    Each line is relate to the factory TIM/unlapped result represented by the y=0 dashed black line. Again, these are delta temps which are relative to that factory result. The pink line shows the average drop in temp across all 4 cores for the unlapped results while the blue line shows the average drop in temps across all 4 cores for the lapped IHS and for the lapped HS. The data show a real but trivial difference after lapping both parts for most days. The exception being in the linpack+gcc stress on day 3. Here the average deltas are within error of each other based solely on the fluctuation in ambient temp.

    Based on these data, lapping an i7-3370K and the heatsink used to cool it produces minimal benefits in heat dissipation gains.
    Last edited: Aug 4, 2012
  2. Chai

    Chai Administrator Staff Member

    I'm quite overwhelmed by the amount of data. Are you trying to compare the difference between the stock TIM and your TIM?
  3. graysky

    graysky ARP Reviewer

    Yeah... I'll update the post after I get a good 120 h of uptime... might simplify it too.
  4. graysky

    graysky ARP Reviewer

    First post updated.
  5. Chai

    Chai Administrator Staff Member

    The unevenness could be one of the reason. Did the IHS sit flat on the core? Did you check if the IHS has full contact after reapplying the AS5?
  6. graysky

    graysky ARP Reviewer

    To my eye, yes. Based on my previous experience, either the IHS or the HS (or both) will need to be lapped.
  7. Chai

    Chai Administrator Staff Member

    Because of the new socket design, there's no way to mount HS without IHS.
  8. graysky

    graysky ARP Reviewer

    I updated the first post of this thread with new results having lapped both the IHS and the base of the heatsink. They start under the section entitled, "Part 2."
  9. graysky

    graysky ARP Reviewer

    I was able to drop my vcore offset from +200 mV down 150 mV to +5 mV and have a stable system as evaluated by: 5 h of mprime large/FFTs, 2 h of continuous compiling, 2 h of systest 64M, and 2 h of linpack+gcc. Lower operating temps have their tangibles. This is @ 45x100. I'll now switch over to 47x100 to see if I can drop the vcore by a proportional amount and might try 48x100. Just wanted to update.
  10. Chai

    Chai Administrator Staff Member

    Not too bad for an IvyBridge. Did you overclock before this mod?
  11. graysky

    graysky ARP Reviewer

    Yes, all values above are for 45x100 @ offset of +0.020 V.
    Last edited: Aug 5, 2012
  12. graysky

    graysky ARP Reviewer

    Interestingly, the lower offset (-150 mV) only translated into -1C drop across cores:

    Squares are the offset of +0.020 V and circles are the offset of +0.005 V.

    Here are a few visuals on the VID distributions. Remember, my script is sampling 30 times/sec and that on day 4, I dropped the offset by -150 mV:

    Here it is in terms of raw counts:

Share This Page