Showing results for 
Search instead for 
Did you mean: 

Server Gurus Discussions

Journeyman III

How can one find "P0 frequency"?

The TSC runs at "P0 frequency", but  I cannot see how to read that from any configuration information in user-space. 

Intel processors have the base frequency in the CPU identity string "Intel(r) foo(r) processor @ 99.9GHz", but AMD ones do not. There seems no cpuid leaf which would give me this, and, (on Linux), looking at

/sys/devices/system/cpu/cpuN/cpufreq/ only has max and min frequency files, which, again do not reflect the notional P0 frequency.

Surely there's some way to find this out!?

8 Replies

Hello jcownie‌,

Please try:

      cpupower frequency-info


AFAICT that is a command line answer, which is not really what I want, since it may be OS dependent, and I want to get this inside my timing code. I have ended up with code like this (My tsc_tick_count is a class which reads and stores TSC; its default constructor saves "now).

static double measureTSCtick() {

// Use C++ "steady_clock" since recommends against

// using hrtime. Busy wait for 100ms based on the std::chrono clock

// and time that with rdtsc.

  auto start = std::chrono::steady_clock::now();

  tsc_tick_count startTick;

  auto end = start + std::chrono::milliseconds(100);

  while (std::chrono::steady_clock::now() < end) { }

  auto elapsed = tsc_tick_count::now() - startTick; 

  // We should maybe read the actual end time here, but this seems

  // to work OK without that. (And, if we're worried about

  // our thread being stolen for a while, that could happen between the

  // rdtsc and reading this clock too...)

  double tickTime = 100.e-3 / elapsed.getValue(); 

  return tickTime;


which works but takes 1/10s rather than a few us which one might expect this to take at worst.


If the max and min frequencies won't work for you, and the data from cpupower won't either, then perhaps create a table that maps the base frequency from the OPN available in the CPUID to official base off of and the product page.


Max and min frequencies are useless, since they're not the rate at which the TSC ticks. Researching all current AMD products is more work than just using the code, and doesn't help me when you bring our new products!


In brief, P0 etc are part of the old ACPI standard

  • P0 maximum power and frequency
  • P1 less than P0, voltage and frequency scaled
  • P2 less than P1, voltage and frequency scaled
  • Pn less than P(n–1), voltage and frequency scaled

The modern CPU may have several P states. For example my R5 3600 has core parking so that when at idle the power levels can fall more and reduce the thermal load. Core parking has materially improved power savings over lower clock speeds and voltage reductions.

Part of the problem is that in the modern cores, P0 no longer defines a single frequency/voltage combination, but rather it's a "maximum performance" request, which encompasses a variety of voltage+frequency combinations. Clearly, one of those frequencies will be the one at which the TSC clock ticks, but that seems to be the nominal frequency from the sales document, not the max-Turbo, nor the min. Linux can give me the max and min (from one of the pseudo files), but as we just said, they aren't what I need.  Intel(r) CPUs do tell me the nominal frequency since it's there in the brandname string which you can read from cpuid, but AMD don't seem to have it anywhere in the info available from cpuid.

So, I'm reduced to allowing a known amount of time to pass and then seeing how many TSC ticks it was. Which works and is generally portable, but requires that time passes... (though 1ms is probably enough to measure, rather than the 100ms I wrote in the sample code above).


Modern processors are now so complex with power states it is very hard to compare with an old NMOS class device which ran at the same speed all day.

P0 is nominal now due to the turbo boost capability. So a CPU now is sold for its nominal default clock speeds. Actual speeds vary depending as much on power plan setting as it does with how good is the cooling.

In a data center where there are a lot of heat sources, thermal management becomes more important. Server processors can be upwards of 200W which adds to the thermal management budget.

If  you are attempting to measure CPU clock ticks,I suggest its not repeatable as CPU instructions vary a lot depending on the dynamic clock and how fast your RAM is etc.


All that you say is undoubtedly correct. However in modern AMD (and Intel) CPUs, the TSC timer runs at a fixed rate (check cpuid leaf 80000007H.edx&(1<<8)) which is independent of the actual CPU clock, and I want to know what that rate is. That doesn't seem an unreasonable thing to want to know, since this is the highest resolution and cheapest to access clock that one has.

The issues of where the rdtsc is executed in the OoO core, so what has happened before and after it and, therefore what one is timing, and how that relates to unordered load/store operations etc. are all real issues, but not the one I am interested in in this question. (And one can make arguments in different directions about those depending on what one is timing, and what one wants to measure; again, that's not the issue here, though!).

I have micro-benchmarks which extract interesting, useful, information on Intel, AMD and Broadcom (Arm) processors, so this is not merely academic...