GIGABYTE GB-BXi7H-5500 Broadwell BRIX Review
by Ganesh T S on January 29, 2015 7:00 AM ESTPower Consumption and Thermal Performance
The power consumption at the wall was measured with a 1080p display being driven through the HDMI port. In the graphs below, we compare the idle and load power of the GIGABYTE GB-BXi7H-5500 with other low power PCs evaluated before. For load power consumption, we ran Furmark 1.15.0 and Prime95 v28.5 together. The numbers are not beyond the realm of reason for the combination of hardware components in the machine.
The slightly higher base clocks in the Core i7-5500U (compared to the Core i7-4500U) are probably the reason for the Haswell-based unit appearing more power efficient than the Broadwell counterpart - but, make no mistake here - the Broadwell unit wins the performance per watt test quite easily.
The evaluation of the thermal performance was performed by monitoring the various clocks in the system as well as the temperatures with the unit when subject to the following workload. We start with the system at idle, followed by 30 minutes of pure CPU loading. This is followed by another 30 minutes of both CPU and GPU being loaded simultaneously. After this, the CPU load was removed, allowing the GPU to be loaded alone for another 30 minutes.
In the pure CPU loading scenario, the cpre frequencies stay well above the suggested base value of 2.4 GHz (indicating that GIGABYTE's trust in their cooling solution). The core temperature doesn't cross 90 C during this time (the junction temperature is 105 C). On the other hand, when the CPU and GPU are both loaded, the frequencies drop down to around 1.6 GHz for the cores. The GPU is advertised to run at a base clock of 300 MHz, with a turbo mode of 950 MHz. The actual frequency stays above 800 MHz comfortably throughout our stress test. In the absence of any CPU load, the cores drop down to 800 MHz. The temperatures are also below 80 C throughout the time that the GPU is loaded up.
All in all, the thermal solution is very effective. Given that the acoustic side-effects were not irksome (subjectively), we wonder if GIGABYTE has missed a trick by dialing down the overclocking and not allowing the full performance potential of the system to come through.
Facebook
Twitter
RSS
53 Comments
View All Comments
kgh00007 - Thursday, January 29, 2015 - link
No mention of the i7-5500U turbo speeds?3GHz single core turbo and 2.9GHz dual core turbo, source notebookcheck.
voicequal - Saturday, February 7, 2015 - link
These were provided in a previous article.http://anandtech.com/show/8814/intel-releases-broa...
Shadowmaster625 - Thursday, January 29, 2015 - link
The only people who would pay that much money for so little performance already gave their money to apple.gr8pcguy - Thursday, January 29, 2015 - link
Doesn't it bother anyone that the box is printed with the statement "Supports 2.5" Hard Drivers"? Obviously Gigabyte needs to do a bit of QA on their package production line!Refuge - Thursday, January 29, 2015 - link
Ha! I noticed this to when I first clicked the link.Hopefully they fix the typo before full production for consumers. :P
skifiddle - Saturday, January 31, 2015 - link
to?Refuge - Thursday, January 29, 2015 - link
The Brix, now supports 2.5" Hard "Drivers"Is this some kind of new, super strong drivers for our HDD's?
And yes, this is me being sarcastic :P
tspacie - Thursday, January 29, 2015 - link
The huge iGPU BIOS carve-out intrigues me. Does the iGPU not handle allocations in shared system memory (in 4K pages) ?Pissedoffyouth - Thursday, January 29, 2015 - link
Nah, neither does AMD APUs. You lose whatever you allocate.rootheday3 - Friday, January 30, 2015 - link
the BIOS carve out is not necessary. The bios reserves a little (~32mb) for some internal data structures used by the driver (graphics page tables, memory for content protection, auxilary buffer for display frame buffer compression). Otherwise, the driver gets allocations out of system memory from the OS to map into the graphics page tables.the DVMT pre-Allocated is a hold over from Windows XP driver model and is no longer meaningful since Vista. In fact, if the OS comes under memory pressure and starts asking the driver to stick data into that "dedicated" segment, the PCI aperture copy/swizzle process used to load the data is slower than if the driver simply used OS allocations. Likewise, on standby/hibernate the OS "pages out" all the data from dedicated segment to "normal" memory which is slow... whereas for normal system allocations on iGPU, the pages are just "there" - no extra copy required.
The sole exception is a handful of games that are incorrectly coded to look for "Dedicated" graphics memory from OS API call and then make bogus decisions based on that (e.g. refuse to run=>PES, restrict available game resolution/settings =>SW:TOR, older Total War games, render incorrectly because they think they don't have room to load textures =>GTA IV). For this small set of games, having the BIOS option to preallocate memory (which the driver won't actually use) is a workaround to fool them into running correctly.