Favored Core

For Broadwell-E, the last generation of Intel’s HEDT platform, we were introduced to the term ‘Favored Core’, which was given the title of Turbo Boost Max 3.0. The idea here is that each piece of silicon that comes off of the production line is different (which is then binned to match to a SKU), but within a piece of silicon the cores themselves will have different frequency and voltage characteristics. The one core that is determined to be the best is called the ‘Favored Core’, and when Intel’s Windows 10 driver and software were in place, single threaded workloads were moved to this favored core to run faster.

In theory, it was good – a step above the generic Turbo Boost 2.0 and offered an extra 100-200 MHz for single threaded applications. In practice, it was flawed: motherboard manufacturers didn’t support it, or they had it disabled in the BIOS by default. Users had to install the drivers and software as well – without the combination of all of these at work, the favored core feature didn’t work at all.

Intel is changing the feature for Skylake-X, with an upgrade and for ease-of-use. The driver and software are now part of Windows updates, so users will get them automatically (if you don’t want it, you have to disable it manually). With Skylake-X, instead of one core being the favored core, there are two cores in this family. As a result, two apps can be run at the higher frequency, or one app that needs two cores can participate. 

Speed Shift

In Skylake-S, the processor has been designed in a way that with the right commands, the OS can hand control of the frequency and voltage back to the processor. Intel called this technology 'Speed Shift'. We’ve discussed Speed Shift before in the Skylake architecture analysis, and it now comes to Skylake-X. One of the requirements for Speed Shift is that it requires operating system support to be able to hand over control of the processor performance to the CPU, and Intel has had to work with Microsoft in order to get this functionality enabled in Windows 10.

Compared to Speed Step / P-state transitions, Intel's new Speed Shift terminology changes the game by having the operating system relinquish some or all control of the P-States, and handing that control off to the processor. This has a couple of noticeable benefits. First, it is much faster for the processor to control the ramp up and down in frequency, compared to OS control. Second, the processor has much finer control over its states, allowing it to choose the most optimum performance level for a given task, and therefore using less energy as a result. Specific jumps in frequency are reduced to around 1ms with Speed Shift's CPU control from 20-30 ms on OS control, and going from an efficient power state to maximum performance can be done in around 35 ms, compared to around 100 ms with the legacy implementation. As seen in the images below, neither technology can jump from low to high instantly, because to maintain data coherency through frequency/voltage changes there is an element of gradient as data is realigned.

The ability to quickly ramp up performance is done to increase overall responsiveness of the system, rather than linger at lower frequencies waiting for OS to pass commands through a translation layer. Speed Shift cannot increase absolute maximum performance, but on short workloads that require a brief burst of performance, it can make a big difference in how quickly that task gets done. Ultimately, much of what we do falls more into this category, such as web browsing or office work. As an example, web browsing is all about getting the page loaded quickly, and then getting the processor back down to idle.

Again, Speed Shift is something that needs to be enabled on all levels - CPU, OS, driver, and motherboard BIOS. It has come to light that some motherboard manufacturers are disabling Speed Shift on desktops by default, negating the feature. In the BIOS is it labeled either as Speed Shift or Hardware P-States, and sometimes even has non-descript options. Unfortunately, a combination of this and other issues has led to a small problem on X299 motherboards.

X299 Motherboards

When we started testing for this review, the main instructions we were given was that when changing between Skylake-X and Kaby Lake-X processors, be sure to remove AC power and hold the reset BIOS button for 30 seconds. This comes down to an issue with supporting both sets of CPUs at once: Skylake-X features some form of integrated voltage regulator (somewhat like the FIVR on Broadwell), whereas Kaby Lake-X is more motherboard controlled. As a result, some of the voltages going in to the CPU, if configured incorrectly, can cause damage. This is where I say I broke a CPU: our Kaby Lake-X Core i7 died on the test bed. We are told that in the future there should be a way to switch between the two without having this issue, but there are some other issues as well.

After speaking with a number of journalists in my close circle, it was clear that some of the GPU testing was not reflective of where the processors sat in the product stack. Some results were 25-50% worse than we expected for Skylake-X (Kaby Lake-X seemingly unaffected), scoring disastrously low frame rates. This was worrying.

Speaking with the motherboard manufacturers, it's coming down to a few issues: managing the mesh frequency (and if the mesh frequency has a turbo), controlling turbo modes, and controlling features like Speed Shift. 'Controlling' in this case can mean boosting voltages to support it better, overriding the default behavior for 'performance' which works on some tests but not others, or disabling the feature completely.

We were still getting new BIOSes two days before launch, right when I need to fly half-way across the world to cover other events. Even retesting the latest BIOS we had for the boards we had, there still seems to be an underlying issue with either the games or the power management involved. This isn't necessarily a code optimization issue for the games themselves: the base microarchitecture on the CPU is still the same with a slight cache adjustment, so if a Skylake-X starts performing below an old Sandy Bridge Core i3, it's not on the game.

We're still waiting to hear for BIOS updates, or reasons why this is the case. Some games are affected a lot, others not at all. Any game we are testing which ends up being GPU limited is unaffected, showing that this is a CPU issue.

Analyzing The Silicon: Die Size Estimates and Arrangements Power Consumption, Test Bed and Setup
Comments Locked

264 Comments

View All Comments

  • AnandTechReader2017 - Monday, June 19, 2017 - link

    And no load/idle? And clockspeed at full load?
    Also, no mention of Intel drawing more than the rated load?
  • AnandTechReader2017 - Monday, June 19, 2017 - link

    Sorry, missed the paragraph under on refresh.
  • wolfemane - Monday, June 19, 2017 - link

    Seriously... you don't post gaming results because of bios issues? Seems RYZEN had issues due to premature bios as well but that sure as hell didn't keep you all from posting results anyways.

    I was going to give kudos to you guys as I was reading the article for excluding gaming reaults on workstation CPU's. But nope, you had to add that little blurb there at the end.

    Pretty god damn shameful if you ask me. Post the results, then do a follow up when venders get their crap together and release reliable bios. The same venders that blamed AMD for their inability to create half way decent bios.
  • Ryan Smith - Monday, June 19, 2017 - link

    Unfortunately it's a bit of a damned if you do, damned if you don't situation for us. The Skylake-X platform is still quite immature in some respects, and Intel did not give us a ton of lead-time in testing it. The BIOSes only came in a bit before Ian had to get on a plane. So we've been racing the clock for the past week trying to pull things together.

    What we do have are a set of incomplete data that still shows some issues. But we need time to further validate that data, and even more time to write about it. Both of which have been in short supply over the last few days.

    Mentioning gaming at all is because we wanted to point out that there are still issues, and that anyone who is primarily interested in gaming is likely best served by waiting, rather than jumping on Intel's pre-orders.
  • wolfemane - Monday, June 19, 2017 - link

    I GET where you are coming from. But you (Anandtech) had no issues posting AMD Ryzen results knowing full well that the x370 platform was far *FAR* from mature. Anandtech and other reviewers didn't hesitate to mention all the bugs possibly holding the platform back. But you still posted the results. As you should have.
  • Ian Cutress - Monday, June 19, 2017 - link

    Err, what? Our Ryzen 7 review did not have gaming benchmarks.
    http://www.anandtech.com/show/11170/the-amd-zen-an...
  • wolfemane - Monday, June 19, 2017 - link

    Well... guess how incredibly stupid I feel? If I could retract my comment I would. I'll go reread the launch review again.
  • cheshirster - Monday, June 19, 2017 - link

    No need to apologize
    Here are gaming tests on DDR4-3000 @ 2400 downclocked memory
    With Ryzens BADLY underperforming in RoTR and Rocket League pretty much published
    http://www.anandtech.com/show/11244/the-amd-ryzen-...
    And for Intel they write this
    "Our GTX1080 seems to be hit the hardest out of our four GPUs, as well as Civilization 6, the second Rise of the Tomb Raider test, and Rocket League on all GPUs. As a result, we only posted a minor selection of results, most of which show good parity at 4K"
  • DanNeely - Monday, June 19, 2017 - link

    Check the dates; that was published about 5 weeks after the initial Zen review that Ian linked to above. The initial one didn't have any gaming data yet; because in both cases the release day situation was too broken.
  • melgross - Monday, June 19, 2017 - link

    Yeah, it's usually considered to be proper to first read about what you're commenting upon.

Log in

Don't have an account? Sign up now