It’s been a few months since our last PC build--in fact, it was published well before Ryzen was released. For our first post-Ryzen build, we’ve pulled together some of the components we liked best in testing to make an affordable ultrawide gaming machine. As we did in January, we pulled parts out of inventory and actually assembled and tested this PC to back up our recommendations--we’ll try to continue doing this going forward.
This gaming PC build is priced at just over $1000 -- about $1200, depending on rebates -- and is made for UltraWide 3440x1440 gaming. Our goal is to take reasonably affordable parts and show that UltraWide 1440p gaming is feasible, even while retaining high settings, without buying the most expensive GPUs and CPUs on the market. We’re only using parts in this build that we actually have, so that partially dictates cost (yes, you might be able to do some things cheaper -- like the motherboard), but it also means that we’ve had time to build, validate, and use the system in a real environment. In these early days of Ryzen as a new uarch, that’s important. We’ve done the hard work of troubleshooting a functional build. All you’d have to do is assemble it, configure BIOS, and go.
As a note: This build is also readily capable of production workloads. CUDA acceleration on the GTX 1070 will work well for Premiere renders, and the CPU thread-count will assist in CPU acceleration (like for streaming).
Prior to the Ryzen launch, we discovered an issue with GTA V testing that would cause high-speed CPUs of a particular variety to stutter when achieving high framerates. Our first video didn’t conclude with a root cause, but we now believe the game is running into engine constraints – present on other RAGE games – that trigger choppy behavior on those CPUs. Originally, we only saw this on the best i5s – older gen i5 CPUs were not affected, as they were not fast enough to exceed the framerate limiter in GTA V (~187FPS, or thereabouts), and so never encountered the stutters. The newest i5 CPUs, like the 7600K and 6600K, would post high framerates, but lose consistency in frametimes. As an end user, the solution would be (interestingly) to increase your graphics quality, resolution, or otherwise bring FPS to around the 120-165 mark.
Then Ryzen came out, and then Ryzen 5 came out. With R5, we encountered a few stutters in GTA V when SMT was enabled and when the CPU was operating under conditions permitting the CPU to achieve the same high framerates as Intel Core i5-7600K CPUs. To better illustrate, we can actually turn down graphics settings to a point of forcing framerates to the max on 4C/8T R5 CPUs, relinquishing some of the performance constraint, and then encounter hard stuttering. In short: A higher framerate overall would result in a much worse experience for the player, both on i5 and R5 CPUs. The 4C/8T R5 CPUs exhibited this same stutter performance (as i5 CPUs) most heavily when SMT was disabled, at which point we spit out a graph like this:
Following our in-depth Ryzen VR benchmark (R7 1700 vs. i7-7700K with the Rift + Vive), we immediately began compiling results for the concurrent R5 test efforts by GN Sr. Editor Patrick Lathan. Working together, we were able to knock-out the VR benchmarks (check those out here – some cool data), Ryzen Revisit piece, and today’s R5 reviews.
Both the R5 1600X ($250) and R5 1500X ($190) CPUs are in for review today, primarily matched against the Intel i5-7500 and i5-7600K. For comparison reasons, we have still included other CPUs on the bench – notably the i7-7700K and R7 1700, just to give an understanding of what the extra ~$70-$130 gets.
For anyone who hasn’t checked in on our content since the initial Ryzen reviews, we’d strongly encourage checking the Ryzen Revisit piece for a better understanding of how the scene has changed since launch. That revisit looks at Windows updates (and debunks some myths), EFI updates, and memory overclocking impact on Ryzen performance.
Although we have rerun the R7 gaming benchmarks with higher memory frequency (thanks to GSkill and Geil for providing B-die kits), we have not yet rerun them in synthetic tests. The 2933MHz frequency, as a reminder, was a hard limitation on our test platforms in the initial round of R7 reviews.
We will be including that data (albeit truncated) in our new tests, alongside Intel retests for the same games. For now, though, we’re reviewing the R5 1600X and R5 1500X CPUs in the Ryzen family, priced at $250 and $190, respectively.
AMD today made available a power plan update which should change how the Balanced plan impacts Ryzen performance.
Problems with Windows preset power modes have been one of the biggest annoyances with Ryzen, and AMD has officially recommended the High Performance preset in the past in order to avoid subpar performance in benchmarks. This wasn’t a big deal from a testing point of view since High Performance mode effectively avoids all of these issues, but for everyday use, it was: High Performance mode doesn’t allow CPU frequency to drop when idle, and the additional power consumption can really hurt the long-term value of the system (it’s also just wasteful). Balanced mode does drop frequency, but it’s also been overly aggressive with core parking on Ryzen chips specifically, making it sub-optimal for use. We discussed what this looks like from a user’s point of view in our “Just Research” article, where frequency plots offer visualization for the impact of Performance vs. Balanced mode. The same article contains some FPS benchmarks between the two power modes.
AMD has made two major changes in this update. Quoting their statement:
Maintain residency in CPU p0 or p1 to give Zen full control over clocks and volts.
Disable core parking.
They specifically noted that Intel also fully disables core parking in the Balanced power plan. Our tests have always used High Performance mode for Ryzen platforms (except power tests), and our results will not be affected by this update.
This first revisit to Ryzen’s performance comes earlier than most, given the tempestuous environment surrounding AMD’s latest uarch. In the past weeks, we’ve seen claims that Windows updates promise a significant boon to Ryzen performance, as has also been said of memory overclocking, and we were previously instructed that EFI updates alone should bolster performance. Perhaps not unrelated, game updates to major titles could have potentially impacted performance, amounting to a significant number of variables for a revisit.
Today’s content piece aims to isolate each of these items as much as reasonable – not all can be isolated, like game updates – to better determine the performance impact from the individual changes and updates. We’ll then progress cumulatively through charts as updates are applied. Our final set of charts will contain Windows version bxxx.970, version 1002 EFI on the CH6, and memory overclocking efforts.
This 47th episode of Ask GN features questions pertaining to test execution and planning for multitasking benchmarks, GPU binning, Ryzen CPU binning, X300 mITX board availability, and more. We provide some insights as to plans for near-future content, like our impending i7-2600K revisit, and quote a few industry sources who answered questions in this week's episode.
Of note, we worked with VSG of Thermal Bench to talk heatpipe size vs. heatpipe count, then spoke with EVGA and ASUS about their GPU allocation and pretesting processes (popularly, "binning," though not quite the same). Find the new episode below, with timestamps to follow the embed:
We’ve praised the R7 1700 ($330) for its mixed workload performance and overclocking capabilities at $330, and we’ve criticized the 1800X for its insignificant performance improvements (over the 1700) at $500. That leaves the R7 1700X ($400), positioned precariously between the two with a base clock of 3.4GHz, but the full 95W TDP of its 1800X sibling.
The 1700X performs as expected, given its flanks, landing between the R7 1700 and R7 1800X. All three are 8C/16T chips with the same CCX layout; refer back to our 1800X review for a more thorough description of the R7 CPU & Ryzen architecture. A quick comparison of basic stats reveals that the major advantage of the 1700X is a moderate increase in frequency, with additional XFR headroom as demarcated by the ‘X’ suffix. That said, our R7 1700 easily overclocked to a higher frequency than the native 1700X frequency, with no manual adjustment to voltage or EFI beyond the multiplier. The 1700X has a base clock of 3.4GHz and a boost clock of 3.8GHz, which theoretically means it could come close to the performance of our 3.9GHz 1700 straight out of the box while retaining the benefits of XFR (circumvented by overclocking).
The AMD Ryzen 5 series is set to continue AMD’s launch of its new Zen architecture, debuting earlier this month with the Ryzen 7 (R7) CPUs. Thus far, we’ve seen the release of the 1800X flagship, 1700X, and 1700 CPUs (the last of which being our option of choice). AMD’s subsequent launches will be focused on the R5 line, announced today, and a later-specified R3 line. We’re looking at a retail release date of April 11 for the R5 1400, R5 1500X, R5 1600, and R5 1600X CPUs; the R3 CPUs, meanwhile, are expected for availability in 2H17.
AMD hasn’t fully revealed all the technical details of these SKUs at this time. We know enough of the basics, but will have to wait for more information on how the CCXs are configured in 6C/12T scenarios.
Here’s a listing of prices, to get started:
AMD yesterday released a community update with interesting assertions regarding thread scheduling, temperature reporting, Windows power plan issues, and SMT challenges.
According to AMD’s Robert Hallock, the company has found no indication that Windows 10 thread scheduling is operating improperly for Zen. This should be the final word in any argument that Microsoft thread scheduling issues are sabotaging Ryzen: they aren’t, as stated by AMD below:
“We have investigated reports alleging incorrect thread scheduling on the AMD Ryzen processor. Based on our findings, AMD believes that the Windows 10 thread scheduler is operating properly for ‘Zen,’ and we do not presently believe there is an issue with the scheduler adversely utilizing the logical and physical configurations of the architecture.
“As an extension of this investigation, we have also reviewed topology logs generated by the Sysinternals Coreinfo utility. We have determined that an outdated version of the application was responsible for originating the incorrect topology data that has been widely reported in the media. Coreinfo v3.31 (or later) will produce the correct results.”
When we first began benchmarking Ryzen CPUs, we already had a suspicion that disabling simultaneous multithreading might give a performance boost in games, mirroring the effects of disabling hyperthreading (Intel’s specific twist on SMT) when it was first introduced. Although hyperthreading now has a generally positive effect in our benchmarks, there was a time when it wasn’t accounted for by developers—presumably partly related to what’s happening to AMD now.
In fact, turning SMT off offered relatively minor gaming performance increases outside of Total War: Warhammer—but any increase at all is notable when turning off a feature that’s designed to be positive. Throughout our testing, the most dramatic change in results we saw were from overclocking, specifically on the low stock frequency R7 1700 ($330). This led many readers to ask questions like “why didn’t you test with an overclock and SMT disabled at the same time?” and “how much is Intel paying you?” to which the answers are “time constraints” and “not enough, apparently,” since we’ve now performed those tests. Testing a CPU takes a lot of time. Now, with more time to work on Ryzen, we’ve finally begun revisiting some EFI, clock behavior, and SMT tests.