dual-socket CPU power: Core power is greater than package?

[Rimits]

Is it normal or a bug that Core Power 279W is greater than Package Power 210W ?

OS:ubuntu 20.04 CoreFreq version: 1.91.5 CPU: epyc 7542 *2 Motherboard: Gigabyte

[cyring]

It is not normal and dual EPYC is barely never tested; before your screenshot.

Need to debug: send you code changes; is your dual socket platform available for experimentation ?

[cyring]

• Cores watt is the sum of all physical Core threads. Logical SMT Cores are excluded from the sum.
• Package watt is sourced from hardware register

Without better specs, I think Package refers to one socket.

This might explain the issue.

[Rimits]

Of course, I can do some experiments on that server. The 279W of cores power could be accurate, because the BMC shows the current and voltage of VRM_CPU0 are 142A and 0.94V. Package watt seems accurate too since the cpu is limited to 225W. Maybe appending a "0" to the Package label will fix the misleading situation.

The same goes the 480W TDP and 240W PL2.

[cyring]

The label Package0 is a good suggestion.

You can also target the second socket for a Package watt reading. You'll have to bind the CoreFreq Service Processor to a CPU which belongs to second socket.

1. Refer to the Topology to find a CPU of second socket. Let's say 64
2. Reload the driver this way:

   
   insmod corefreqk.ko ServiceProcessor=64

Or adapt your modprobe

3. Please provides a screenshot of the `Power` view

Remarks:
* I'm presuming Package0 and Package1 should slightly differ ?
* When not specified, Service Processor is selected according to kernel scheduling
* Service Processor can be assigned to any socket
* If CPU is disabled, Service Processor is auto migrated by driver
* UI is always highlighting the CPU number of the Service Processor and its SMT, (and the Hybrid with Intel 12th gen.) 

[cyring]

Of course, I can do some experiments on that server. The 279W of cores power could be accurate, because the BMC shows the current and voltage of VRM_CPU0 are 142A and 0.94V. Package watt seems accurate too since the cpu is limited to 225W. Maybe appending a "0" to the Package label will fix the misleading situation.

0.94V in your readings is during idle case

Computing from my Matisse voltage of 1.48 V (instant load voltage) and your Rome current of 142A, I'm getting a consumed power P = V x I of ~ 210W

[Rimits]

Topology:

 ---------------------------------- Topology ----------------------------------      
 CPU Pkg  Apic  Core/Thread  Caches      (w)rite-Back (i)nclusive              
  #   ID   ID CCD CCX ID/ID L1-Inst Way  L1-Data Way      L2  Way      L3  Way 
 000:BSP    0   0  0   0  0      32  8        32  8       512  8 i  131072 16w  
 001:  0    2   0  0   1  0      32  8        32  8       512  8 i  131072 16w 
 ...
 031:  0   62   6  7  31  0      32  8        32  8       512  8 i  131072 16w 
 032:  1  128   0  0   0  0      32  8        32  8       512  8 i  131072 16w 
 033:  1  130   0  0   1  0      32  8        32  8       512  8 i  131072 16w 
 ...                                          
 ------------------------------------------------------------------------------

Reload: insmod corefreqk.ko ServiceProcessor=32

Result:

When Service Processor is 19: They are slightly different, since CPU2 is cooler and the frequency is higher.

[cyring]

For your information, below specs of the two Power registers (RAPL):

• Package reading https://github.com/cyring/CoreFreq/blob/3d2abb09b54e8895e60808942d2503ef0b886ccc/corefreqk.c#L17294
• Per Core reading https://github.com/cyring/CoreFreq/blob/3d2abb09b54e8895e60808942d2503ef0b886ccc/corefreqk.c#L17338

[cyring]

Hello,

Can you try this attached version where the Package ID is appended to label. Should print 0 or 1 depending of your selected Service Processor.

CoreFreq_develop.tar.gz

Two UI views are impacted:

• Sensors
• Power

And two CLI outputs are impacted:

• corefreq-cli -C
• corefreq-cli -w

[EDIT] Remark: Custom view is a problem. I don't find enough space in its footer line.

[Rimits]

Thx, it's less confusing now.

[cyring]

Meanwhile I have enhanced the Custom view CoreFreq_develop.tar.gz

[Rimits]

well, you do have a fast hand🚴

[cyring]

well, you do have a fast handbicyclist ![截屏_20220810-171014]

Thank you.

I'll leave those changes in the develop branch for a short while; making sure no regression happens on other systems.