Just Research: Ryzen Clock Behavior in Perf v. Balanced & EFI FPS Impact

As with any new technology, the early days of Ryzen have been filled with a number of quirks as manufacturers and developers scramble to support AMD’s new architecture.

For optimal performance, AMD has asked reviewers to update to the latest BIOS version and to set Windows to “high performance” mode, which raises the minimum processor state to its base frequency (normally, the CPU would downclock when idle). These are both reasonable allowances to make for new hardware, although high-performance mode should only be a temporary fix. More on that later, though we’ve already explained it in the R7 1700 review.

This is quick-and-dirty testing. This is the kind of information we normally keep internal for research as we build a test platform, as it's never polished enough to publish and primarily informs our reviewing efforts. Given the young age of Ryzen, we're publishing our findings just to add data to a growing pool. More data points should hopefully assist other reviewers and manufacturers in researching performance “anomalies” or differences.

The below is comprised of early numbers we ran on performance vs. balanced mode, Gigabyte BIOS revisions, ASUS' board, and clock behavior when under various boost states. Methodology won't be discussed here, as it's really not any different from our 1700 and 1800X review, other than toggling of the various A/B test states defined in headers below.

BIOS & MOBO DIFFERENCES

The EFI version (5704) which we used on the Crosshair Hero VI ($255) during testing was the newest* possible version, supplied to us directly by ASUS. This was updated from the AMD-distributed earlier EFI rev that corresponded with initial review samples, and so we had moved to the newest EFI option prior to executing tests. The initial distribution of ASUS boards (from the review kit) hosted an EFI which was built on unfinalized ucode for the CPU, hence some initial concern. Because AMD has not provided motherboard vendors the list of media partners who received each board, it has been on media to contact their reps and stay on top of EFI updates. We used the Crosshair throughout testing for various reasons, including AM3 mounting holes that enabled use of a Kraken X62, but were more recently supplied a Gigabyte board using beta BIOS version F3n—slightly older than publicly available version F3.

(Note: During the writing and research process for this content piece, Gigabyte pushed yet another EFI update. We have not yet tested F5.)

(Note 2: ASUS just contacted us with this information pertaining to another EFI update:

“[The new beta EFI] has some DOCP tweaks as discussed before and memory performance changes plus a lot of little bugs we have found in the AGESA code that needed to be cleaned up. The one caveat is that reporting utilities like CPUZ will not report voltages correctly. We have found some discrepancies in how the third party tools access SIO registers that can cause some unpredictable behavior in the platform. We will work with them on updating our version of CPUZ along with a couple of other programs.”

We’ve been informed by AMD and other media members that some motherboards (e.g. MSI’s) have improved significantly in performance after updating to the latest BIOS from initial review revs, but some brief testing in Watch_Dogs 2, Ashes of the Singularity, and Total War: Warhammer showed negligible FPS differences between Gigabyte’s BIOS revisions F3n and F3. Differences certainly exist in overall bugginess of the interface (read: less), but framerate differences were largely unseen between those two versions.

Above: No significant difference.

Above: Although measurable in some cases (Total Warhammer, where the change is more exaggerated), we are looking for major changes. Thus far, the EFI differences appear to be largely insignificant, if at times measurable.

Ashes and Total Warhammer showed negligible improvement, with the greatest change in Watch_Dogs 2, decreasing from an average of ~83.7 (F3n) FPS to ~82.3 (F3) FPS—not significantly different, and potentially within range of random deviation. Cinebench also scored slightly lower, but the changes in both single- and multi-threaded performance were less than 1%. This doesn’t mean that BIOS updates are useless altogether—it just means that at a glance, the beta BIOS that Gigabyte shipped to reviewers is near equivalent to the finalized public version with our test configuration (which, again, has since been updated – it's nearly nonstop EFI updates right now, and so is hard to nail anything down). We've heard some folks get stuck at 2666MHz-2800MHz on the Gigabyte motherboard and know that EFI revisions theoretically help improve this, though our particular configuration (could be memory dies, in part) seems permitting of at least 2933MHz.

The performance differences between the Gigabyte and ASUS boards were up and down, but overall, they reinforced our (then only) choice of the ASUS board for initial testing. From ASUS to Gigabyte, AOTS dropped 1.2%, WD2 0.7%, and TWW decreased ~1.5% in average FPS on the Gigabyte board. AMD favorite Cinebench dropped 5.7% in multithreaded performance on Gigabyte's board.

Normal variance in tests can account for some of the differences, but the logical conclusion is that differences in hardware (and software) can cause visible, repeatable differences in benchmark results. This is good news for consumers—if there’s repeatable variance or unreliability between platforms right now in our tests, it implies that there’s some room for optimization and improvement. This also means that our test results should only be 100% directly compared against our other test results—other benchmarks on other platforms will show different results, even using the same CPUs. Memory support has a tremendous impact on this, from what we've read, and so testers or users incapable of exceeding 2666MHz may be more affected by that quirk than anything else. Grabbing relevant EFI updates for memory support should help in this regard. We can sustain 2933MHz on both motherboards as long as an 1800X is used.

BALANCED VS PERF

Turning on high performance mode is a stopgap measure to resolve some Windows core parking functionality, according to AMD, and it’s something that should be avoided by most users once Microsoft and AMD adjust to Ryzen; holding an 1800X at a constant 3.6GHz is wasting a useful efficiency feature which has already shown its effectiveness with Intel CPUs. Moreover, our tests show a possible negative impact on AMD’s XFR limited-core frequency boosting feature when high performance is enabled (although this will not affect overclocked CPUs). It would seem that forcing performance mode reduces the voltage headroom and clock flexibility to boost to higher frequencies when desirable.

Battlefield 1 – Balanced vs. Performance (1800X, Crosshair 5704)

GTA V – Balanced vs. Performance (1800X, Crosshair 5704)

Metro: Last Light – Balanced vs. Performance (1800X, Crosshair 5704)

Watch Dogs 2 – Balanced vs. Performance (1800X, Crosshair 5704)

(Some of the above may have been rerun since review, depending on if we had the data available.)

Performance vs. Balanced Boosting & XFR Behavior

Ryzen’s frequency adjustment features are explained in detail in this post on Anandtech’s forums, but the gist is this: for each Ryzen CPU, there’s a base frequency across all cores, a boosted “XFR” frequency across all cores, a base frequency for a single core, and an XFR frequency for a single core. For the 1800X, these frequencies are 3.6, 3.7, 4.0, and 4.1 respectively. In our power draw testing, we found that the 1800X would keep all cores at 3.7GHz when under 100% load, but would boost one core to 4.1GHz in single-thread synthetic tests.

Ryzen Clock Behavior: Performance Mode Cinebench 1T (R7 1700)

Above: Workload moves threads constantly (1T workload) during Performance Mode.

Note: During this process, we discovered a bug with HW Monitor's chart generation. HWM captures frequencies every 0.5 seconds; if it captures 3750 three times, for example, it will show a plateau. If it captures 3750 once or twice, it will extrapolate an incorrect (high) frequency. The CSVs do not do this, and so we have corrected the above charts with a quick Photoshop brush layer to match the CSVs. Lows are also inaccurate (below baseline) due to the same bug.

Ryzen Clock Behavior: Performance Mode Cinebench Multithreaded (R7 1700)

As seen in the above graphs of an R7 1700 running Cinebench in high performance mode, all cores remain at 3.2GHz (the multi-thread XFR limit) under 100% load. While in the single threaded test, individual cores will boost up to 3.75GHz (the peaks above this are due to a bug in HardwareMonitor’s graphing software). The R7 1700's non-X demarcation contributes to its lower XFR range.

This is of particular interest to overclockers because, from what we’ve seen, any overclocking automatically disables XFR. In our (very basic) Ryzen overclocking experiments, we were only able to push our CPUs to 3.9 or 4.0GHz—below the 4.0-4.1GHz single-core limit of the 1800X. This is somewhat expected, given the limited thread spread of the higher 4.0 and 4.1GHz speeds, but we also know that further fine-tuning, ref CLK management, and lower-level tweaking could likely give us more play. In POVRay’s single-threaded benchmark, performance actually worsened with an overclock, since our 1800X was locked at 3.9GHz rather than being allowed to boost. In every multi-threaded benchmark, performance improved as expected, since 3.9GHz is greater than the stock 3.7GHz multi-core limit.

For us, this issue was unique to the 1800X because of its high stock XFR limit. Our testing suggests that it’s not unreasonable to expect 3.9 or 4.0GHz from overclocked 1700 and 1700X chips as well, which is beyond their boost frequencies of 3.7 and 3.8GHz respectively. If this continues to hold true and isn't some binning gold mine of early chips, the best option would be to buy a 1700 and overclock it, as it can compete with the 1800X on all levels except (stock, XFR enabled) single-core performance.

This also relates to high-performance mode in Windows. The relevant aspect of high-performance mode that has motivated AMD to suggest it is that it sets the minimum clock speed to the current base clock of the processor, reducing latency as the CPU is forced to ramp into workloads by minimizing the frequency modulation and power saving functions. Performance ensures that the Ryzen CPUs are working at full capacity during workloads, or as close to it as permissible given the platform and OS.

1700 core frequency during POVRay single-threaded benchmark (high performance mode)

1700 core frequency during POVRay single threaded benchmark (balanced mode)

Again, ignoring the bugs in HardwareMonitor’s graphs (quickly corrected with Photoshop), when running POVRay’s single-threaded benchmark in high-performance mode, there’s a hard minimum of 3.2GHz and a hard maximum of 3.75Ghz, and nothing logged between these two extremes. Load balancing between threads also behaves significantly differently, as indicated between the two tests.

In balanced mode, however, cores 4-7 sat at 1.5GHz constantly, core 3 and core 2 alternated between 1.5 and 1.422GHz, core 1 ranged anywhere from 1.5 to 3.75GHz, and core 0 maintained a relatively constant 3.2-3.75GHz. There’s definitely a visible effect from Windows power settings, and boosting in balanced mode seems to prefer one or two cores rather than bouncing between them constantly. Some testing in Cinebench suggests a very mild single-threaded performance advantage in balanced mode, if anything (145.25 vs. 147.5 average, after half a dozen passes), but it seems that the end result isn’t much affected by the Windows power setting. As discussed in our 1800X review, high performance mode does seem to have a 4-5% positive impact on gaming and multithreaded benchmarks. High-performance mode isn’t great for power consumption, especially for overclocked CPUs that will be forced to constantly run at their OC frequency, and hopefully software updates will resolve the problems with balanced mode soon.

Conclusion

The troubleshooting tips most often offered by AMD during Ryzen’s launch have been updating BIOS, using a different motherboard, and changing Windows power management settings. Based on our tests, it’s certainly worth taking all of these things into consideration, but we feel confident that the BIOS update given to us by ASUS was the best one to use for testing at the time, though a new beta version was just sent to us, further indicating an active dev state for the platform. The most recent BIOS version available on Gigabyte’s site prior to locking-in this content (F3, but an F5 is in and out of dev) for the GA-AX370 is similar enough to the one shipped with the board (F3n) not to significantly affect gaming results. We have not yet tested F5. Windows power profiles did have a mild effect on performance and are important to max-out for more fair comparisons, as we've been doing. This effect will hopefully be minimized over time. It'd be nice to revert to balanced mode for power savings without the performance hit. Different hardware is one of the most important and unpredictable factors, and although we got solid performance from the ASUS Crosshair, we encourage Ryzen buyers to read reviews and select their motherboard carefully. Motherboard and platform selection will matter more in these early days of a new uarch than may have felt true for the last several generations of Intel boards.

Again, these numbers are just part of the community's efforts to better understand Ryzen and the AM4 platform. These tests are by no means fully conclusive of the potential differences between all motherboards and all EFI versions. We do now have a foundation for our platforms, and will continue to iterate as further EFI, Windows, or other updates are pushed. We are publishing from the show floor of PAX East right now and will return to HQ soon for further testing. Lots to do with Ryzen.

Editorial, Research & Testing: Patrick Lathan
Additional Research: Steve Burke