The GIGABYTE MZ72-HB0 (Rev 3.0) Motherboard Review: Dual Socket 3rd Gen EPYCby Gavin Bonshor on August 2, 2021 9:30 AM EST
Not all motherboards are created equal. On the face of it, they should all perform the same and differ only in the functionality they provide - however, this is not the case. The obvious pointers are power consumption, POST time, and latency. This can come down to the manufacturing process and prowess, so these are tested.
Power consumption was tested on the system while in a single MSI GTX 1080 Gaming configuration with a wall meter connected to the power supply. The only system that wasn't tested with a graphics card in our results is the GIGABYTE MZ72-HB0, which was tested via the ASPEED AST2500 BMC Controller.
Our power supply has ~75% efficiency > 50W, and 90%+ efficiency at 250W, suitable for both idle and multi-GPU loading. This method of power reading allows us to compare the power management of the UEFI and the board to supply components with power under load, and includes typical PSU losses due to efficiency. These are the real-world values that consumers may expect from a typical system (minus the monitor) using this motherboard.
While this method for power measurement may not be ideal, and you feel these numbers are not representative due to the high wattage power supply being used (we use the same PSU to remain consistent over a series of reviews, and the fact that some boards on our testbed get tested with three or four high powered GPUs), the important point to take away is the relationship between the numbers. These boards are all under the same conditions, and thus the differences between them should be easy to spot.
GIGABYTE MZ72-HB0 Long Idle result was powered off with the BMC controller on - normally this test is idle in the OS and left until the display turns off. It just goes to show how much power keeps the BMC going.
When comparing power consumption figures to other AMD EPYC/Threadripper boards we've tested, we don't really have any main comparison points. In the EPYC 7351P testing, we were using a single CPU at 170 W, whereas in the GIGABYTE, we have two AMD EPYC 7763 processors which each have a 280 W TDP. At full load, is monstrous on the power with a peak power reading of 782 W at the wall. In our long idle test, the board was powered down barring the BMC controller, which is apparent in our figures with a low power reading of just 14.6 W.
Non-UEFI POST Time
Different motherboards have different POST sequences before an operating system is initialized. A lot of this is dependent on the board itself, and POST boot time is determined by the controllers on board (and the sequence of how those extras are organized). As part of our testing, we look at the POST Boot Time using a stopwatch. This is the time from pressing the ON button on the computer to when Windows starts loading. (We discount Windows loading as it is highly variable given Windows-specific features.)
When it came to POST time testing, we typically see that server and workstation models have a much longer POST time than conventional desktop models. This is due to controller initializations and as such, the GIGABYTE takes between two to three minutes to boot into Windows. With non-essential controllers disabled including networking, we did manage to shave an additional 15 seconds off the default POST time.
Deferred Procedure Call latency is a way in which Windows handles interrupt servicing. In order to wait for a processor to acknowledge the request, the system will queue all interrupt requests by priority. Critical interrupts will be handled as soon as possible, whereas lesser priority requests such as audio will be further down the line. If the audio device requires data, it will have to wait until the request is processed before the buffer is filled.
If the device drivers of higher priority components in a system are poorly implemented, this can cause delays in request scheduling and process time. This can lead to an empty audio buffer and characteristic audible pauses, pops and clicks. The DPC latency checker measures how much time is taken processing DPCs from driver invocation. The lower the value will result in better audio transfer at smaller buffer sizes. Results are measured in microseconds.
Typically server and workstation motherboards aren't optimized for DPC latency out of the box, and as we test DPC at default settings, the GIGABYTE is certainly not optimized for this.