Is all-core boost a thing on EPYC?

Here is a little sanity-check of my understanding. I have got the impression that for recent EPYC generations, at least for Milan, there is no such thing as all-core boost - or, rather, it is the same as base clock, i.e. base clock is what you get when putting load on all cores.

But then I found this listing from cpu-monkey, where all-core boost clocks are listed for all EPYCs, even the newest generation.

For example, the 75F3, recently tested by @wendell I believe, is claimed to have a base clock of 2.95GHz and an all-core boost of 3.8GHz. But I have never seen any mention of this elsewhere, from AMD or anyone else. Is EPYC Milan all-core-boost (that is > base clock) a thing, or is CPU-monkey simply wrong?

I know nothing about that site, and there are dozens of the same kind. My default is to assume they are wrong, but I’d like to hear if not…

Edit: corrected 75F3 example

2 Likes

The answer is “It depends” the boost behavior of milan is more aggressive than rome, or at least it seems so, especially if you max out the cTDP.

More stressful avx type workloads tend to hover around the base clock. There are power and thermal limits. And these limits vary a lot depending on your workload. So I suppose its possible in “best case scenario” you might see an all core boost that high. And this is a bit different than rome.

I’ve tested SQL server extensively on rome and milan, and (again this is anecdotal) we observed more boosty behavior on milan than rome. Rome would tend to stick to the base clocks in really heavy loads but milan would have +200-300mhz typically. I would say I regularly saw boosts in the 3.3-3.5ghz neighborhood on near-full-load with the 75F3. But SQL server is a lighter workload than you might expect vs say scientific compute.

4 Likes

FWIW, I got significantly above-base all core clocks in Linpack with Rome, on a 7402P when I maxed out the cTDP/PPT to 200 W.
In actual use, on that CPU I am usually seeing all cores hitting max boost (within ~50 Mhz) even in AVX workloads, unless the package power limit (PPT) is reached.

4 Likes

Ctdp is uhhhhmazinnn. Thats why. If your thermals are good raising ctdp effectively raises the base.

2 Likes

Thanks @wendell and @Methylzero for your input! So I take the clockspeed is limited by thermals and the cTDP setting, but not simply a numeric limit. This is how it should be, so I can’t complain. Do you ever see boosts above the max boost speed? As that has been observed on consumer ryzens…

It also seems that whatever is the source of cpu-monkey’s “all-core” numbers, it is not based on observed values or any function of realistic workloads. They list it for all models, also for those who have not hit the market, and they are super-even numbers. So I suspect they are fiction, since AMD never advertised something like that. Anyway, nice to hear that you see fair clockspeeds also with all cores loaded.

Btw @wendell, here is a suggestion for future CPU reviews. What I’d be interested in seeing more of in tests are measurements of the clockspeed dynamics as a function of the number of cores loaded. (forgive me if you have already tested this somewhere, if so I haven’t seen it!).

It would be nice to see a CPU tests where you load more and more cores, and plot a curve how the clockspeed of loaded cores drops of with the number of cores loaded. This becomes increasingly relevant with Milan, where the range between base and boost speed may span > 1GHz, and it is difficult to know what to expect for e.g. a half-loaded machine.

It would also be interesting to see this dynamic if loading one chiplet at the time, as opposed to letting the OS decide (or maybe that is already what happens if the OS decides, idk). I am thinking of scenarios such running a gaming VM with 8 or so virtual cores, on a 16-64c workstation CPU. In that scenario one would presumably want to give the VM dedicated chiplet(s).

Would tests like that make any sense?

1 Like

This topic was automatically closed 273 days after the last reply. New replies are no longer allowed.