Please make the BIOS guide for Ryzen available, even if just a draft. Need information on performance monitoring.
(While we are all waiting, here's a 2013 note that hints at how complex it can be to verify and document how to best use performance counters:
John McCalpin's blog: Notes on the mystery of hardware cache performance counters
Two related manuals were updated this week.
Performance monitoring is covered in some relevant chapter and appendix sections of Volume 2:
13 Software Debug and Performance Resources
13.2 Performance Monitoring Counters
13.3 Instruction Based Sampling
13.4 Lightweight Profiling
A.6 Performance Monitoring MSRs
Change history related to performance monitoring:
Retired Performance Counter:
The Volume 2 revision history says
"Added Instructions Retired Performance counter in Section 13.1.1." (Typo.
The short addition is in Section 13.2.1, page 370, with margin changebar.)
(Section 184.108.40.206 also discusses the instructions retired counter.)
This MSR address, C000_00E9, is not listed in Appendix A.1 (MSR by address) nor A.6 (Performance monitoring MSRs).
(Volume 2 Appendix A.6 lists MSRs C001_023x to specify/count L2 cache events. These are listed in Jaguar Family 16h BKDG but not Bulldozer Family 15h BKDGs, so might be new for software that previously targeted Bulldozer. Also discussed in section 13.2.1 on page 370.)
Time stamp counter
The Volume 3 revision history says
"Modified RDTSC and RDTSCP."
Sections RDTSC and RDTSCP have changebars on the paragraph that says the TSC is implementation-dependent and may be affected by power management frequency changes, and to consult the BKDG for your product.
[volume 2 section 13.2.4 also discusses serialization of RDTSCP with respect to other instructions.]
References to product BKDG for implementation-specific restrictions:
Sections 13.2 and 13.3 refer the reader to varying products' BIOS and Kernel Developer's Guide (BKDG) for:
Thank you. But I still need the BIOS guide for a list of performance events.
AMD posted initial Ryzen Model Specific Register (MSR) documentation to Tech Docs this week in the form of
Section 2.1.13 Performance Monitor Counters contains the PMC details.
A comparison pass shows many differences across family/model 17h/00h PPR, 16h/30h BKDG, 15h/70h BKDG (spreadsheet attached).
Many counters are presumably omitted from this edition of the PPR: no counters for interrupts, dispatch stalls, breakpoint hits, northbridge, crossbar, memory controller (nor infinity fabric).
But there might be enough to get started learning about Ryzen performance counters.
Thank you. The Processor Programming Reference seems to have all the information about performance monitoring.
The Ryzen has a new core clock counter, which is exactly what I had hoped for. It is called "Actual Performance Frequency Clock Count (APERF)". This makes it possible to get consistent and reproducible clock measurements while the clock frequency keeps changing. Unfortunately, the APERF counter cannot be read with the RDPMC instruction in user mode, only with the RDMSR instruction in privileged mode. This makes it difficult to measure the performance of small pieces of code. You have to read the time stamp counter (TSC) and the APERF over a longer interval to calculate the core clock frequency, and then measure the test code with the TSC and multiply it with the ratio of the two clocks. It is easier with Intel processors where you can read the core clock counter with RDPMC in user mode.
Dear gc9, dear AMD staff,
unfortunately, months after the Ryzen release, we still do not have sufficient details to understand how to retrive and to interpret CPU sensor readings. Could you please have a look at this record on LM-Sensors issue tracker and see which information you can make available to help your paying customers retrieve this information without a need to sign NDAs?
Support for AMD Family 17h Processors · Issue #16 · groeck/lm-sensors · GitHub
Update: AMD posted a shorter document with a few added performance counters to https://support.amd.com/en-us/search/tech-docs
Section 2 is on Performance Monitor Counters.
10 Additions (since Processor Programming Reference noted above) include:
Bad Status 2 [Store To Load Interlock]
Retired CFLUSH InstructionsRetired CPUID InstructionsSMIs ReceivedStore to Load ForwardStore Commit Cancels 2
Data Cache Refills from System
Software Prefetch Data Cache Fills
Hardware Prefetch Data Cache FillsTable Walker Data Cache Fills
Pipeline Restart Due to Instruction Stream Probe
I want to read processor temperature, but all known interfaces does not work now.
Could you provide some information about this?
Is there some short "howto" instruction to read temperature and use watchdog on 17h?
(I dont need whole BKDG 17h right now.)
For Ryzen temperatures on Linux, a web seach turned up
It is shame for AMD to not publish documents on CPU.
I take my money to AMD and got no support, even in this simple thing during almost 6 months.
You found howto for sensors read on mobo, it is not same.
For linux: echo $((0x`setpci -s 00:0.0 60.l=0x59800 && setpci -s 00:0.0 64.l`/2097152*5/4))
For FreeBSD use mine patch: ⚙ D9759 amdtemp driver update
I think is very important if AMD can create a guide to cover the most of their BIOS setting nowadays, among with Ryzen, because there are not info at all, while Intel seems to covered all :/
And to be honest AMD BIOS option sets to AUTO seems not to do well... you can clearly see by enabling or disabling or setting custom can really cause a major effect on PC performance, but to be honest not everyone knows about AMD bios settings, they are very different from Intel, and is there is lack of information :/ so please , don't ignore us
Could someone test my driver with Family 17h ?
GitHub - cyring/CoreFreq: CoreFreq is a CPU monitoring software designed for the 64-bits Processors.
For a few hours, I have had a chance to run it on EPYC and got correctly the TSC, APERF counters & PSTATES enumeration.
Here we are almost two years later and AMD still apparently has not released the full info (at least I am told that is why the linux drivers STILL don't know how to get per-core readings). What is the reason for this secrecy? Is there some terrible exploit lurking in our sensors that AMD is nervous will be discovered? Why on Earth would they not make it as easy as possible for their product to be maximally useful to as many people as possible?
Retrieving data ...