Temperatures and Noise

Wrapping up our look at the Compal notebook, we measured the noise levels and temperatures at idle and at load. Since we don’t know if this particular configuration will even hit retail, we won’t dwell on it too much, but here are the results. Idle surface temperatures measured between 24C and 29C on the keyboard and palm rest, while the bottom of the notebook is slightly warmer and showed temps of 26-32C. Most of the notebook is close to room temperature, but near the CPU and exhaust at the back/middle the system is a bit warmer. Under heavy load (for over an hour), the temperatures increase, but the fan and dynamic CPU/GPU clocks keep things reasonable. The top temperatures increased to 24-33C, while the bottom measured 26-38C. Temperatures at the exhaust under load were around 44C. Here’s a shot of internal system temperatures, courtesy of HWMonitor.

Using the same idle and load tests, we also checked noise levels. The BIOS on this particular setup allows you to configure two temperatures and fan speeds, with the defaults being 75% fan speed at 55C and 100% fan speed when the CPU hits 70C. There are apparently other settings in effect, however, as we noticed four distinct fan speeds. Anyway, below about 45C, the fan shuts off and you have a silent notebook. Given the low power requirements and CPU temperatures at idle, the system fan is usually off under light loads, with the result being system noise right at the floor of our testing environment/equipment: 30dB. Occasionally the fan will spin up and create about 32.5dB of noise, but this usually only lasted a few seconds at most. Running heavy loads will usually get the fan at maximum speed after 20 seconds or so, at which point we measured 41dB; that’s still tolerable considering how infrequent such loads usually are, though if you do heavy number crunching or video editing you might end up with a moderately noisy notebook.

Average Resolution, Average Performance

What about the LCD? We’ve only looked at a few 17.3” notebooks, with their associated 900p resolution. So far we’ve had the Clevo W870CU (Chi Mei N173O6-L02), the ASUS X72D/K72DR with the same panel, and the Dell Studio 17 (with an unknown panel). The Sandy Bridge test system apparently comes with a Seiko Epson 173KT panel, but the characteristics are no better—and sometimes worse—than the other 17.3” 900p displays we’ve looked at.

Laptop LCD Quality - Contrast

Laptop LCD Quality - White

Laptop LCD Quality - Black

Laptop LCD Quality - Color Accuracy

Laptop LCD Quality - Color Gamut

Color gamut is pretty good, and accuracy is perhaps a bit better than average, but the contrast is a disappointing 217:1 and the maximum brightness is a none-too-impressive 226nits. While there are certainly worse LCDs out there, this particular panel is yet another that fails to rise above mediocrity. We have yet to test a 900p display that has impressed us, so consider this a warning.

Performance and Power Investigated Sandy Bridge: Bridging the Mobile Gap
Comments Locked

66 Comments

View All Comments

  • tipoo - Monday, January 3, 2011 - link

    Sorry if I missed this somewhere in the review, but does the graphics component support OpenCL?
  • RyuDeshi - Monday, January 3, 2011 - link

    Second to last paragraph on the "Extended compatibility and performance results:"

    "Ultimately, Sandy Bridge’s IGP is far more capable than many would have expected. Sure, it doesn’t even try to support DX11 or OpenCL, but at least for gaming DX11 is typically too much for even midrange GPUs."
  • CharonPDX - Monday, January 3, 2011 - link

    An Intel rep has said that Sandy Bridge will support OpenCL. (http://news.cnet.com/8301-13924_3-20024079-64.html ) The trick is that it may be a combo CPU+GPU to do it. So it may not be what you are thinking by OpenCL being solely GPU, but OpenCL code should be able to run.

    And in the end, what does it matter, really, as long as it runs? As the desktop Sandy Bridge review points out, video encoding is just as fast using solely the x86 codepaths as using nVidia's CUDA or ATI's Stream.
  • Voldenuit - Monday, January 3, 2011 - link

    OpenCL was designed from the outset to run on heterogenous resources, including CPU.

    So intel claiming that they "support" OpenCL is nothing special - they just needed the right drivers/API.

    However, don't expect OpenCL code running solely on the CPU (my guess as to how SB will handle it) to be any faster than the x86 codepath running on the same CPU.

    Checkbox feature.
  • jameskatt - Monday, January 3, 2011 - link

    What Intel wants to do is to have the CPU run OpenCL code.

    This totally defeats the purpose of OpenCL.

    OpenCL is suppose to allow both the GPU and the CPU to run code simultaneously. This is to allow significant acceleration in running OpenCL code compared to using just the CPU.

    Sure. OpenCL code will run. But it will run MORE SLOWLY than with a discrete GPU. And the 16 GPUs in Sandy Bridge will be wasted.

    Intel's Sandy Bridge has non-programmable GPUs. This is a serious limitation and deal killer when it comes to running OpenCL code.

    I expect Apple to continue use nVidia's or AMD's discrete GPUs with the MacBooks and Mac Book Pros.

    This is very disappointing. It shows that Intel still doesn't have the talent to produce decent GPUs.
  • PlasmaBomb - Monday, January 3, 2011 - link

    And the 16 GPUs in Sandy Bridge will be wasted.


    *cough* I think you mean 12 EU *cough*
  • Guspaz - Monday, January 3, 2011 - link

    <i>What Intel wants to do is to have the CPU run OpenCL code.

    This totally defeats the purpose of OpenCL.

    OpenCL is suppose to allow both the GPU and the CPU to run code simultaneously. This is to allow significant acceleration in running OpenCL code compared to using just the CPU.</i>

    No, this is the *primary* purpose of OpenCL. The goal of OpenCL is not to "allow the GPU and CPU to run code simultaneously", but to provide a single unified code path that can be used with any hardware, be it CPU or GPU. There are/were already code paths specific to each vendor/type (CUDA for nVIDIA GPUs, Stream for AMD/ATI GPUs, x86 for Intel/AMD CPUs). The problem is that fully supporting all three platforms requires three separate code paths.

    OpenCL unifies this, and allows a single codepath to be used regardless of the GPU's type or existence. You've completely misunderstood the purpose of OpenCL.
  • Wiggy McShades - Tuesday, January 4, 2011 - link

    You need to ask what applications on a desktop actually use OpenCL in a meaningful way? Intel added hardware for media transcoding, which makes transcoding on something besides the cpu useless and that was roughly all openCL can be used for on the desktop, laptop, or cellphone.
    OpenCL is for vector calculations, AVX is for vector calculations. All four cores running AVX instructions would just be a faster choice than OpenCL on a low end gpu. Intel most likely could get sandybridge's gpu running OpenCL, but it would be pointless. OpenCL just is not a desktop feature.
  • strikeback03 - Wednesday, January 5, 2011 - link

    Given how much money they have, I doubt Intel is lacking the "talent" to do anything they want. OpenCL execution on the GPU portion of the SNB chips was probably just not that big a deal to them, and given the number of other things (such as speed and battery life) SNB brings to the table they probably won't have trouble selling lots of these to the average consumer.
  • 8steve8 - Monday, January 3, 2011 - link

    which mobile cpus on pg1 support TXT or VT-d or AES-NI or VT-x or Quick Sync?

Log in

Don't have an account? Sign up now