The GIGABYTE Z170X-Gaming G1 Review: Quad-SLI on Skylake, and now with Thunderbolt 3

System Performance

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, but also the ability for the manufacturer to optimize USB speed, audio quality (based on audio codec), POST time and latency. This can come down to manufacturing process and prowess, so these are tested.

Power Consumption

Power consumption was tested on the system while in a single MSI GTX 770 Lightning GPU configuration with a wall meter connected to the OCZ 1250W power supply. This power supply is Gold rated, and as I am in the UK on a 230-240 V supply, leads to ~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 test bed 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’s Z170X-Gaming G1 implements MultiCore Turbo with K-series processors by default, which seems to require an extraordinary amount of voltage when at stock frequencies (1.404 volts at load). This translates into a large power consumption at stock, which can be mitigated by some manual adjustments. For example, our 4.7 GHz overclock saw 1.392 volts at load at 73C max temperature for only 167W total system power draw.

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 7 starts loading. (We discount Windows loading as it is highly variable given Windows specific features.) 

The BIOS we tested was more of an early beta BIOS, but even then the G1 comes with a large number of extra controllers that need to be checked at POST which adds on to the non-UEFI POST time. That being said, 16 seconds or so comes out well enough, but the ‘stripped’ POST time seemed to go awry.

Rightmark Audio Analyzer 6.2.5

Rightmark:AA indicates how well the sound system is built and isolated from electrical interference (either internally or externally). For this test we connect the Line Out to the Line In using a short six inch 3.5mm to 3.5mm high-quality jack, turn the OS speaker volume to 100%, and run the Rightmark default test suite at 192 kHz, 24-bit. The OS is tuned to 192 kHz/24-bit input and output, and the Line-In volume is adjusted until we have the best RMAA value in the mini-pretest. We look specifically at the Dynamic Range of the audio codec used on board, as well as the Total Harmonic Distortion + Noise.

As we’ve known in the past, audio is difficult to test outside of Realtek operations mainly due to the extra ‘enhancements’ offered by certain software packages that refuse to completely turn everything off. As a result, the GIGABYTE numbers seem low for what they should be, but this is usually some software tool always enabled that interferes with out result.

USB Backup

For this benchmark, we transfer a set size of files from the SSD to the USB drive using DiskBench, which monitors the time taken to transfer. The files transferred are a 1.52 GB set of 2867 files across 320 folders – 95% of these files are small typical website files, and the rest (90% of the size) are small 30 second HD videos. In an update to pre-Z87 testing, we also run MaxCPU to load up one of the threads during the test which improves general performance up to 15% by causing all the internal pathways to run at full speed.

Due to the introduction of USB 3.1, as of June 2015 we are adjusting our test to use a dual mSATA USB 3.1 Type-C device which should be capable of saturating both USB 3.0 and USB 3.1 connections. We still use the same data set as before, but now use the new device. Results are shown as seconds taken to complete the data transfer.

As a first look into the Alpine Ridge controller, the USB speeds for our transfer were a little down compared to the motherboards with the ASMedia, but in our case this also translates to Thunderbolt 3 being in this port as well. Unfortunately we do not have any TB3 devices to test it with at the minute.

DPC Latency

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.

The DPC Latency on the G1 is clearly unoptimized at this point, or might be a victim of having a large number of controllers involved. Some manufacturers at this point would suggest ‘well, you need XYZ setting’, but then it becomes a game of ‘hunt the needle’ trying to get the best DPC Latency value. In that context, this is why we always say we test the out-of-the-box value, which is what most people are going to experience, rather than a few hours fiddling with BIOS options to squeeze out that extra microsecond to say one is better than the other.