Overclock your AMD Epyc

nero243

Active Member
Oct 28, 2018
108
76
28
There is actually only one pro for overclocking: performance. It’s why gamers and PC enthusiasts overclock a CPU and a GPU (graphics processor unit). When you send more voltage to either the CPU or GPU, the graphics increase, response times within applications are reduced, and benchmarks can identify peak performance for complex software.

The biggest issue with overclocking is the reduction in a component’s lifespan. You can overclock a CPU, GPU, motherboard or RAM, but sending increased volts gradually damages these components. Damage is caused by heat generated from increased power. Additional heat doesn’t usually ruin a circuit immediately, so the damage is seen gradually over time.
I... I don't even wan't to respond to this. Let's keep the blood pressure low for today.
 

alex_stief

Active Member
May 31, 2016
625
189
43
35
The biggest issue with overclocking is the reduction in a component’s lifespan. You can overclock a CPU, GPU, motherboard or RAM, but sending increased volts gradually damages these components. Damage is caused by heat generated from increased power. Additional heat doesn’t usually ruin a circuit immediately, so the damage is seen gradually over time.
There is always that one guy...
He forgot to mention that OC voids warranty :eek:
 

Wasmachineman_NL

Dell Precision Fanboy
Aug 7, 2019
288
74
28
I'm not sure there is much point. Even going to 3200 from 2933 has impacted the TDP enough to reduce the boost slightly under full load. And there is only about an extra 10% I could get out of the timings, so 3600 would just turn into a massive time sink for questionable benefit.



You really need to stop fanboying EVGA. Having had two SR-2 motherboards, I can very confidently say they were the most garbage grade board I have ever had the misfortune of owning. There were so many firmware bugs and hardware design faults it wasn't even funny. It was unfit for purpose. Off the top of my head:

1) CPUs were rated for 192GB of RAM each. The board could only reliably handle 48GB. 96GB resulted in POST only succeeding about 25% of the time. Obviously a firmware initialisation timeout big since once it managed to POST, it would work fine with 96GB.

2) A SATA-3 controller with two 6-Gbit ports connected via a single 5-Gbit PCIe lane.

3) Advertised as VT-d/VT-x capable, but features NF200 PCIe bridges on _every_ PCIe slot, which bypasses the IOMMU for DMA, which in turn completely breaks PCI pass through by not remapping the VM memory and trampling the PCI apertures. It took me weeks to get to the bottom of that bug and write a Xen HVM loader patch to work around it.

4) It's key feature of OC-ability never really worked properly due to vastly sub-standard clock generators used. The clock stability deteriorated to unusable levels at barely 10% above defaults and no mitigation worked to get it stable again.

The only reason I bought the 2nd was because I was initially convinced I had a duff board, but the 2nd one exhibited all of the exact same issues.

I eventually gave up, sold the SR-2s to fanboys in eBay for twice what I paid for them new, and for a fraction of the amount bought a Supermodel X8DTH-6i, and lived happily for the next 6 years - until a few weeks ago when I replaced it with EPYCD8/7402P.
Never fanboyed for EVGA, the only thing i'm a massive fanboy of are Dell Precisions and Toughbooks.

tbf though the SR-2 is exactly that: Super Record 2, it's used by those nolifers on HWBOT to set world records on dual Xeons.
 
  • Like
Reactions: Sparky'sAdventure

_Robert

New Member
Dec 2, 2019
2
0
1
...the EPYCD8 board...is limited to 200W. Bumping the TDP form "auto" (180W) to 200W bumps the full load all-core boost [of a 7402P with TDP 180W] from about 3000 to 3125 , but going further makes no difference
Thank you for sharing your results. I wonder how clock rates of the 7232p(120W) and 7262(155W) with appropriate cooling would respond to setting TDP 200W in BIOS.
 

Patriot

Moderator
Apr 18, 2011
1,306
690
113
Never fanboyed for EVGA, the only thing i'm a massive fanboy of are Dell Precisions and Toughbooks.

tbf though the SR-2 is exactly that: Super Record 2, it's used by those nolifers on HWBOT to set world records on dual Xeons.
Yeah having been in the F@H arena with lots of 2p and 4p setups ... the SR-2 has a very unkind nickname.
Something about queen of a dog or something. It was a finicky and not well done board.

Supermicro G34 boards on the other hand, wooooeee 3 8-pin for power was plenty to overclock opterons on. Had Magnycours 4p beating sandybridge 4p.
 

Sparky'sAdventure

New Member
Dec 9, 2019
6
1
3
I added the procedure to the start post.

Your running retail CPUs, right? Can you maybe try the custom core P-states from the modded v1.3 bios provided in the startpost?


Edit:

Added the first V2.0 Bios for the H11SSLi with the unlocked new CBS.
Consider this experimental, since idk which menu layout is the right one. There are like 2 full bios layouts in there all with their own variables and 2 CBS menus alone in the new layout. Also this weird thing isn't UBU compatible so i have to use MMtool and do a switcharound for BCP editing. I will write up a step by step DIY when i know it's working.

You'll get a few new settings on rome like XFR performance enhancer, where you can boost the max turbo up. Without being stuck in OCmode. Also DRAM OC goes now up to 4200MHz!

Naples and Rome just indicate which CBS menu is unlocked, both should run fine on both CPUs. Just the CBS Settings aren't going to work if you run the rome bios on naples.
Have you personally tested that the DRAM OC works past JEDEC spec? 4200mhz across 8 channels would be pretty insane, and any Micron E-Die based memory should do that relatively easily if vdimm is controllable. Also, if it does go past, do you have any idea if the 7XX2 chips are limited to the same 1900fclk ratio that the desktop and Threadripper chips are capped with?

Not entirely related but the Zen 2 Threadripper chips don't appear to have an fclk coldbug even on LN2 fullpot according to a few HWBot benchers; I wonder if this carries over to the Epyc chips...
 

nero243

Active Member
Oct 28, 2018
108
76
28
Have you personally tested that the DRAM OC works past JEDEC spec? 4200mhz across 8 channels would be pretty insane, and any Micron E-Die based memory should do that relatively easily if vdimm is controllable. Also, if it does go past, do you have any idea if the 7XX2 chips are limited to the same 1900fclk ratio that the desktop and Threadripper chips are capped with?

Not entirely related but the Zen 2 Threadripper chips don't appear to have an fclk coldbug even on LN2 fullpot according to a few HWBot benchers; I wonder if this carries over to the Epyc chips...
The only stuff i personally tested in the last few month is, how a FX-8350 holds up in 2019. The answer: not great.

LN2 benching with Rome wouldn't make much sense, considering on how difficult the unlock seems to be. But it's a little early to even think about it since we haven't made any progress with OCing whatsoever.
 
  • Like
Reactions: Sparky'sAdventure

I.nfraR.ed

New Member
Aug 20, 2019
19
23
3
Bulgaria
Hello,

Here's the first preliminary version of the "debug" tool. Basically manually setting the addresses and commands.
SMUDebugTool_v1.0.0.zip

The software is provided "as is" and using it is on entirely on your own responsibility!
Trying the test message (0x1) should be safe, but I can't guarantee it.


upload_2019-12-27_1-15-46.png

How To
The app provides several fields
  • CMD Address (hexadecimal) - the base SMU address where the command is sent, or the message address (SMU_ADDR_MSG)
  • RSP Address (hexadecimal) - the response is read from this address
  • ARG Address (hexadecimal) - the address for the first argument. Second argument is calculated automatically
  • Command ID (hexadecimal) - the desired command ID. It's pre-populated with 0x1, which is always a "Test message". If that doesn't return OK, then some of the addresses is incorrect.
  • Argument 0 and Argument 1 (integer) - used for arguments when the command is of type "read". Most of the time you want to set just the Argument 0. Both arguments are used when e.g. you want to set the frequency of a specific CPU core/thread.
  • Status strip at the bottom
The fields are populated with the default values of the detected CPU Core. Defaults button resets all the fields to the detected values.

Some examples (for Matisse/Rome/CastlePeak)

1. Enable Manual Overclock
Change command to 0x5A and hit Apply. Status should say "OK" and the CPU should be forced to base frequency.
2. Disable Manual Overclock
Change command to 0x5B and hit Apply. Status should say "OK" and the CPU should be back to default.
3. Set Overclock Frequency for all cores
Manual OC should be enabled first (step 1). Change command to 0x5C and Argument 0 to 4000 (or your frequency of choice). Hit Apply. Status should be OK and a dialog with the response should be the frequency in HEX.​

I'm still trying to figure out per core overclock, perhaps we don't need the second argument at all. It seem I will need to set the argument to hexadecimal as well.

It is strange that Matisse has 2 different mailboxes and the command IDs are different, too.

first set of commands:
Code:
SMC_MSG_EnableOverclocking = 0x5A;
SMC_MSG_DisableOverclocking = 0x5B;
SMC_MSG_SetOverclockFreqAllCores = 0x5C;
SMC_MSG_SetOverclockFreqPerCore = 0x5D;
SMC_MSG_SetOverclockVid = 0x61;

SMC_MSG_SetPPTLimit = 0x53;
SMC_MSG_SetTDCLimit = 0x54;
SMC_MSG_SetEDCLimit = 0x55;
SMC_MSG_SetHTCLimit = 0x56;

SMC_MSG_GetPBOScalar = 0x6C;
SMC_MSG_SetPBOScalar = 0x6E;

SMC_MSG_GetTctlOffset = 0x70;
2nd set of commands (with addresses):
Code:
const UInt32 SMU_ADDR_MSG = 0x03B10530;
const UInt32 SMU_ADDR_RSP = 0x03B1057C;
const UInt32 SMU_ADDR_ARG0 = 0x03B109C4;

const UInt32 SMC_MSG_TestMessage = 0x1;
const UInt32 SMC_MSG_GetSmuVersion = 0x2;
const UInt32 SMC_MSG_EnableSmuFeatures = 0x3;
const UInt32 SMC_MSG_SetTjMax = 0x23;
const UInt32 SMC_MSG_EnableOverclocking = 0x24;
const UInt32 SMC_MSG_DisableOverclocking = 0x25;
const UInt32 SMC_MSG_SetOverclockFreqAllCores = 0x26;
const UInt32 SMC_MSG_SetOverclockFreqPerCore = 0x27;
const UInt32 SMC_MSG_SetOverclockVid = 0x28;
const UInt32 SMC_MSG_SetBoostLimitFrequency = 0x29;
const UInt32 SMC_MSG_SetBoostLimitFrequencyAllCores = 0x2B;
const UInt32 SMC_MSG_GetOverclockCap = 0x2C;
const UInt32 SMC_MSG_MessageCount = 0x2D;
PS: Think I've figured out how to set per core. The Asus tool first sets all core frequency to lowest one, then sends the other command for a single core. The first argument is
Code:
0x01200FA0
for CCX 1, Core 2 (for core # 6), frequency FA0 which in DEC is 4000. So we don't need the second argument.

Difference between SMU MSG and SMU RSP addresses seems to be 0x4C. So I could probably scan some range of addresses to find the start address. The offset of the ARG is different, though.
 
Last edited:

Wasmachineman_NL

Dell Precision Fanboy
Aug 7, 2019
288
74
28
Have you personally tested that the DRAM OC works past JEDEC spec? 4200mhz across 8 channels would be pretty insane, and any Micron E-Die based memory should do that relatively easily if vdimm is controllable. Also, if it does go past, do you have any idea if the 7XX2 chips are limited to the same 1900fclk ratio that the desktop and Threadripper chips are capped with?

Not entirely related but the Zen 2 Threadripper chips don't appear to have an fclk coldbug even on LN2 fullpot according to a few HWBot benchers; I wonder if this carries over to the Epyc chips...
4200 would be useless on Epyc, because the IF stops scaling about 3800/4000 MHz.
 
  • Like
Reactions: Sparky'sAdventure

Gordan

Member
Nov 18, 2019
39
8
8
Hello,

Here's the first preliminary version of the "debug" tool. Basically manually setting the addresses and commands.
SMUDebugTool_v1.0.0.zip

The software is provided "as is" and using it is on entirely on your own responsibility!
Trying the test message (0x1) should be safe, but I can't guarantee it.


View attachment 12602

How To
The app provides several fields
  • CMD Address (hexadecimal) - the base SMU address where the command is sent, or the message address (SMU_ADDR_MSG)
  • RSP Address (hexadecimal) - the response is read from this address
  • ARG Address (hexadecimal) - the address for the first argument. Second argument is calculated automatically
  • Command ID (hexadecimal) - the desired command ID. It's pre-populated with 0x1, which is always a "Test message". If that doesn't return OK, then some of the addresses is incorrect.
  • Argument 0 and Argument 1 (integer) - used for arguments when the command is of type "read". Most of the time you want to set just the Argument 0. Both arguments are used when e.g. you want to set the frequency of a specific CPU core/thread.
  • Status strip at the bottom
The fields are populated with the default values of the detected CPU Core. Defaults button resets all the fields to the detected values.

Some examples (for Matisse/Rome/CastlePeak)

1. Enable Manual Overclock
Change command to 0x5A and hit Apply. Status should say "OK" and the CPU should be forced to base frequency.
2. Disable Manual Overclock
Change command to 0x5B and hit Apply. Status should say "OK" and the CPU should be back to default.
3. Set Overclock Frequency for all cores
Manual OC should be enabled first (step 1). Change command to 0x5C and Argument 0 to 4000 (or your frequency of choice). Hit Apply. Status should be OK and a dialog with the response should be the frequency in HEX.​

I'm still trying to figure out per core overclock, perhaps we don't need the second argument at all. It seem I will need to set the argument to hexadecimal as well.

It is strange that Matisse has 2 different mailboxes and the command IDs are different, too.

first set of commands:
Code:
SMC_MSG_EnableOverclocking = 0x5A;
SMC_MSG_DisableOverclocking = 0x5B;
SMC_MSG_SetOverclockFreqAllCores = 0x5C;
SMC_MSG_SetOverclockFreqPerCore = 0x5D;
SMC_MSG_SetOverclockVid = 0x61;

SMC_MSG_SetPPTLimit = 0x53;
SMC_MSG_SetTDCLimit = 0x54;
SMC_MSG_SetEDCLimit = 0x55;
SMC_MSG_SetHTCLimit = 0x56;

SMC_MSG_GetPBOScalar = 0x6C;
SMC_MSG_SetPBOScalar = 0x6E;

SMC_MSG_GetTctlOffset = 0x70;
2nd set of commands (with addresses):
Code:
const UInt32 SMU_ADDR_MSG = 0x03B10530;
const UInt32 SMU_ADDR_RSP = 0x03B1057C;
const UInt32 SMU_ADDR_ARG0 = 0x03B109C4;

const UInt32 SMC_MSG_TestMessage = 0x1;
const UInt32 SMC_MSG_GetSmuVersion = 0x2;
const UInt32 SMC_MSG_EnableSmuFeatures = 0x3;
const UInt32 SMC_MSG_SetTjMax = 0x23;
const UInt32 SMC_MSG_EnableOverclocking = 0x24;
const UInt32 SMC_MSG_DisableOverclocking = 0x25;
const UInt32 SMC_MSG_SetOverclockFreqAllCores = 0x26;
const UInt32 SMC_MSG_SetOverclockFreqPerCore = 0x27;
const UInt32 SMC_MSG_SetOverclockVid = 0x28;
const UInt32 SMC_MSG_SetBoostLimitFrequency = 0x29;
const UInt32 SMC_MSG_SetBoostLimitFrequencyAllCores = 0x2B;
const UInt32 SMC_MSG_GetOverclockCap = 0x2C;
const UInt32 SMC_MSG_MessageCount = 0x2D;
PS: Think I've figured out how to set per core. The Asus tool first sets all core frequency to lowest one, then sends the other command for a single core. The first argument is
Code:
0x01200FA0
for CCX 1, Core 2 (for core # 6), frequency FA0 which in DEC is 4000. So we don't need the second argument.

Difference between SMU MSG and SMU RSP addresses seems to be 0x4C. So I could probably scan some range of addresses to find the start address. The offset of the ARG is different, though.
Is the source code available? I don't use Windows and I would really like to give this a go.
 

hrvoje.sedlic

New Member
Dec 23, 2019
20
3
3
We have a couple of 7742's on h11dsi-nt and wondering if this would work on this board? Anyone maneged to oc 7742's?

These don't scale too good in 2cpu setup, so thinking of splitting to two systems with an overclokable mobo. Any advice for a good one?
 
Last edited:
  • Like
Reactions: Sparky'sAdventure

ExecutableFix

Active Member
Nov 25, 2019
108
44
28
We have a couple of 7742's on h11dsi-nt and wondering if this would work on this board? Anyone maneged to oc 7742's?
Well not yet, but we're definitely making progress. You could try playing with ZenStates and the SMUDebug tool and see if you can get anything to work
 

ExecutableFix

Active Member
Nov 25, 2019
108
44
28
Will do. Any advice for a good overclockable 1cpu mobo?
Pretty much any SP3 board will work, there isn't really a standout one when it comes to VRMs. I personally use a H11SSL-i rev 2 and it's been pretty good for the Naples overclocks. I guess the Asus/Gigabyte boards are just as good
 

I.nfraR.ed

New Member
Aug 20, 2019
19
23
3
Bulgaria
Is the source code available? I don't use Windows and I would really like to give this a go.
Yes. There are also 2 more released versions.
irusanov/SMUDebugTool

I'm also a Linux user and would love to port or at least have a tool with similar functionality.
The windows version is not even close to finish, because there's no documentation. Plus I'm not really a .NET developer. However, I don't have any experience with programming for linux (except Linux/Android kernel). Eventually I can try to make a .NET Core (console) application, similar to the windows app, but that's when (and if) we figure out all the missing bits.

Edit: These might help you
FlyGoat/ryzen_nb_smu
zamaudio/smutool
 
Last edited:
  • Like
Reactions: anoother

ExecutableFix

Active Member
Nov 25, 2019
108
44
28
What is standard clock of your sample? Our is 2.4, max boost 3.0, so it should go that higher?
Well the Naples ES has a clockspeed of 1.9Ghz base and 3.0Ghz boost, so it does go higher. But I'm pretty sure that doesn't work the same on Rome. There's not much headroom on the 64C. You might have more luck on the 32C