Intel’s Turbo Modes

A last minute detail from Intel yesterday was information on the Turbo modes. As expected, not all of the processors actually run at their rated/base frequency: most will apply a series of turbo modes depending on how many cores are registered as ‘active’. Each core can have its frequency adjusted independently, allowing VMs to take advantage of different workload types and not be hamstrung by occupants on other VMs in the same socket. This becomes important when AVX, AVX2 and AVX-512 are being used at the same time.

Most of the turbo modes are a sliding scale, with the peak turbo used when only one or two cores are active, sliding down to a minimum frequency that may be the ‘base’ frequency or just above it. There’s a lot of information for the parts here, so we’ll break it down into stages.

First up, a look at the Platinum 8180 in the different modes:

It should be worth noting what the base frequency actually is, and some of the nuance in Intel’s wording here. The base frequency is the guaranteed frequency of the chip – Intel sells the chip with the base frequencies as the guarantee, such that when the chip is not idle and not in normal conditions (i.e. when not in thermal power states to reduce temperature) should operate at this frequency or above it. Intel also lists the per-core turbo frequencies as ‘Maximum Core Frequencies’ indicating that the processors could be running lower than listed, depending on power distribution and requirements in other areas of the chip (such as the uncore, or memory controller). It’s a vague set of terms but ultimately the frequency is determined on the fly and can be affected by many factors, but Intel guarantees a certain amount and provides guides as to what it expects the turbo frequencies to be.

As for the Platinum 8180, it keeps its top turbo modes while up to two cores are active, and then drops down. It does this again for another two cores, and a further two cores. From this point, under non-AVX load the CPU is pretty much the same frequency until >20 cores are loaded, but does not decrease that much in all.  For AVX 2.0 and AVX-512, the downward slope of more cores means less frequency continues, with AVX-512 taking a bigger jump down at 13 cores loaded. The final turbo frequency for AVX-512 running on all cores is 2.3 GHz.

Comparing the two 28-core CPUs for which we have turbo information gives this graph. The numbers relate to the number of cores need to be loaded for that frequency.

Both processors are equal to each other for dual core loading, but the separation occurs when more cores are loaded. As we move through to AVX 2.0 and AVX-512, it is clear where the separations are in performance – to get the best for variable core loading, the more expensive processors are required.

Here’s the big table for all the processors on Non-AVX loading:

Despite the 2.0/2.1 GHz base on most of the Platinum series, all the CPUs will turbo up to 3.7-3.8 GHz on low core loading except for the lower power Platinum 8153. For users wanting to strike a good balance between the core count and frequency, the Gold 6154 is probably the place to be: 18 cores that will only ever run at 3.7 GHz with non-AVX loading (3.5-2.7 GHz on AVX-512 depending on core count), and will be $3543 as a list price at 205W. It is perhaps worth noting that this will likely top any of the Core i9 processors planned: at 18-cores and 205W for 3.7 GHz, the Core i9-7980XE which will have 18 cores but run 165W will likely be clocked lower (but also only ~$2000).

Moving onto AVX2.0 and AVX-512:

Xeon Skylake-SP SKUs Intel Expanding the Chipset: 10 GigE & QuickAssist
POST A COMMENT

217 Comments

View All Comments

  • TheOriginalTyan - Tuesday, July 11, 2017 - link

    Another nicely written article. This is going to be a very interesting next couple of months. Reply
  • coder543 - Tuesday, July 11, 2017 - link

    I'm curious about the database benchmarks. It sounds like the database is tiny enough to fit into L3? That seems like a... poor benchmark. Real world databases are gigabytes _at best_, and AMD's higher DRAM bandwidth would likely play to their favor in that scenario. It would be interesting to see different sizes of transactional databases tested, as well as some NoSQL databases. Reply
  • psychobriggsy - Tuesday, July 11, 2017 - link

    I wrote stuff about the active part of a larger database, but someone's put a terrible spam blocker on the comments system.

    Regardless, if you're buying 64C systems to run a DB on, you likely will have a dataset larger than L3, likely using a lot of the actual RAM in the system.
    Reply
  • roybotnik - Wednesday, July 12, 2017 - link

    Yea... we use about 120GB of RAM on the production DB that runs our primary user-facing app. The benchmark here is useless. Reply
  • SofiaRogers - Saturday, July 22, 2017 - link

    I resigned my office-job and now I am getting paid £64 hourly. How? I work over internet! My old work was making me miserable, so I was forced to try something different, two years after...I can say my life is changed-completely for the better!

    Check it out what i do.... http://cutt.us/SL0Hi
    Reply
  • haplo602 - Thursday, July 13, 2017 - link

    I do hope they elaborate on the DB benchmarks a bit more or do a separate article on it. Since this is a CPU article, I can see the point of using a small DB to fit into the cache, however that is useless as an actual DB test. It's more an int/IO test.

    I'd love to see a larger DB tested that can fit into the DRAM but is larger than available caches (32GB maybe ?).
    Reply
  • ddriver - Tuesday, July 11, 2017 - link

    We don't care about real world workloads here. We care about making intel look good. Well... at this point it is pretty much damage control. So let's lie to people that intel is at least better in one thing.

    Let me guess, the databse size was carefully chosen to NOT fit in a ryzen module's cache, but small enough to fit in intel's monolithic die cache?

    Brought to you by the self proclaimed "Most Trusted in Tech Since 1997" LOL
    Reply
  • Ian Cutress - Tuesday, July 11, 2017 - link

    I'm getting tweets saying this is a severely pro AMD piece. You are saying it's anti-AMD. ¯\_(ツ)_/¯ Reply
  • ddriver - Tuesday, July 11, 2017 - link

    Well, it is hard to please intel fanboys regardless of how much bias you give intel, considering the numbers.

    I did not see you deny my guess on the database size, so presumably it is correct then?
    Reply
  • ddriver - Tuesday, July 11, 2017 - link

    In the multicore 464.h264ref test we have 2670 vs 2680 for the xeon and epyc respectively. Considering that the epyc score is mathematically higher, howdoes it yield a negative zero?

    Granted, the difference is a mere 0.3% advantage for epyc, but it is still a positive number.
    Reply

Log in

Don't have an account? Sign up now