Recent content by I.nfraR.ed

I wouldn't call it too fast. I've been working on the matter since almost an year now. Have been lucky to not kill anything, but had many "oops" moments. Retail parts seem to have more protection in place, while ES are easier to kill/damage. SMUDebugTool sped up the development a lot. with all...

Linux tools can be modified, however I'm working on a better detection, since Epyc and Desktop Threadripper 3000 series (Castle Peak) share the same basic cpuid, so another more complicated detection mechanism should be implemented - at least socket type detection is needed. If you want, you...

I believe so. Wouldn't go much above 1.1V if you don't have a good cooling. Temperatures would be high on sustained load, so due to thermals it doesn't make much sense to go above that anyway. As for the frequency - whatever it could do at ~1.1. Zen1 can rarely do 4+ GHz on desktop parts and it...

The tool (GUI) only writes changed values. And for the CLI, you have full control which parameter to set. If you only use the P-States tab, then you're pretty much safe to try on any CPU. Apply button works on active tab only. The underlying terminal window should display something like this...

Ah, for Naples if the P-State DID trick does not work anymore, then currently there's no other known way. All the forks have the same P-State functionality (read/write P-State MSRs). P-State functionality is universal for all generations.

No public tool will currently work on Rome. We're trying to bring up support for Rome and I'm updating both Linux and Windows tools whenever I have more things working. Unfortunately the old DID trick for P-States does not work on Zen2-based CPUs. Even though Rome is basically the same thing as...

The same functionality is available in the Windows app. No support for Rome, since I don't have access to such system and without users debugging and trying commands on a running system, I can't do anything, sorry. I'm rewriting ZenStates for Windows (no official support for Rome), but can't...

No, I don't have a Rome CPU. Here's the first version of the updated python script (now with a GUI): irusanov/ZenStates-Linux It works on Matisse and I'm sure it also works on CastlePeak. I've included Rome in the code, but it probably won't work. Requirements are in the readme from the repo...

You're right watch -n1 "lscpu | grep MHz"; should work the same, but that's not the point. I just wanted to poll for frequency update. There might be a better way, but I'm not a hardcode linux user.

More WIP. It's a python script, so you should be able to modify as you wish, once ready.

I don't know, probably different. The logic dictates that Threadripper 3000 series should be the same as Rome, since they share the CPUID, but in fact TR is the same as Matisse. It might be just the ES Rome we're testing on, but I remember other people tried some of the commands and they didn't...

Threadripper 3 works with the commands from Matisse, it even has the same cpuid. What I'm testing now will work for TR3 as well. ZenStates (for Windows) also works on TR3 (TRX40 socket). But commands and addresses are different for EPYC or at least there's something locked.

Work in progress. It's for Matisse though. We haven't figured commands out for EPYC yet.

Unfortunately, not yet. At least nothing that support these chips. Next goal is some linux tool, because Linux is my main OS too. Yes, it appears some of the commands are the same as on Matisse, but others are different. It's a work in progress, but we're getting there.

Could you try the old commands: EnableOverclocking = 0x24 DisableOverclocking = 0x25 0x24 should force the CPU to manual fixed frequency mode, effectively disabling power limits. The SMU version gets detected, so this means the addresses are working. It's just the new 0x5A command not working...