Energy consumption big differences for idle energy consumption on CPU and Xeon Phi coprocessor

Energy consumption big differences for idle energy consumption on CPU and Xeon Phi coprocessor

I tried to test the idle energy consumption for 10 seconds on Xeon Phi 5110P and  Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz energy consumption. 

I found there is a quite difference on total energy consumption for 10 seconds. This is weird. 

 20.321426 Joules for 10 seconds idle CPU Intel(R) Xeon(R) CPU E5-2650  which is 2.032 Watt. 

While the Xeon Phi 5110P is 764.650000 Joules in 10 seconds which 76.465 Watt. 

The detail codes and compile method can be downloaded in the following two links.

I use "Total power, win 0 uW" as the parameter for measurements. The code use one pthread to read the power in uW every 50 milliseconds since /sys/class/micras/power updated in around 50 milliseconds. Each time power watt updated, I update the energy with adding 50*power. Anything wrong with this measurement in measuring the total power consumption? 

Intel(R) Xeon(R) CPU power is measured by PAPI RAPL PACKAGE_ENERGY:PACKAGE0 event.

See my previous post for more detail.

#include <stdio.h>
#include <stdlib.h>
#include <iostream>
#include <assert.h>
#include "micpower_sample.h"
using namespace std;

int main(int argc, char *argv[]) {
  double energyPerCall = micpower_finalize();
  printf("energyPerCall=%lf\n", energyPerCall);
  return 0;

publicaciones de 6 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.

Both of the program just one simple sleep(10) to let program sleep 10 seconds.

Hi Qingpeng,

Now that I have my EOQ (End Of Quarter) stuff done, I'll help you on your posts as much as I can.


Hi Taylor

Thanks for helping. I am doubting the mic measurement which I use a pthread and while loop which could consume some energy.


It seems sample time length influence a lot on Xeon Phi energy consumption. 

50 milliseconds sample Energy used Energy used in 378.550000
energyPerCall=378.550000 power=75.710000 Watt


200 milliseconds sample Energy used in 485.600000
energyPerCall=121.400000 power=24.280000 Watt

500 miliseconds sample Energy used in 521.000000 for 5 seconds
energyPerCall=52.100000 power=10.420000 Watt

It will update counter to overflow if use 1 seconds sampling. There is a dilemma here. If we use longer sample, the overhead of the while loop and system file reading will reduce a lot but we can not get the precise power consumption on each moment. If we use shorter sample, the overhead of the while loop and system filing reading will introduce a big overhead. 

How to get the power consumption for  a short sample time without too much overhead like PAPI RAPL on Sandy Bridge architecture is the question need to resolved for energy measurement on MIC Xeon Phi. 


Looking at the reference information on the web page:

We need to see the output of the "micsmc" command for most of the arguments described on the web page above so that we can determine which power management features (if any) are enabled, etc.   I would start with:
             micsmc -a
             micsmc --pwrstatus

Are you sure you are being consistent in treating the values from "micsmc" as "instantaneous power" values and not as "accumulated energy" values?   The power values are not quite "instantaneous" -- a couple of different windows are used to give running average values -- but it is critical to treat them as power numbers rather than energy numbers.   If you have even sampling intervals, then there is no need to multiply by the interval to get energy -- simply average the raw power readings to get the average power in Watts (or microWatts, if you have not scaled the values).  

We run our Xeon Phi SE10P processor with most power management disabled, so we typically see 100 Watts on idle coprocessors.   I would expect the average power of an idle system to drop over time if power management is enabled --- that is what it is for!   I don't know what time scales are used by the OS and by the hardware for C state transitions, and I don't recall the details for the time averaging windows reported by /sys/class/micras/power, so it is hard to estimate what sorts of values one would expect to see in a processor that you have just "woken up" from a core or package C state after different lengths of idle time.   

If you really want the "idle" power consumption, then you probably need to measure the power draw externally on the power supply lines to the PCIe card.  Using any of the on-board facilities will "wake up" at least part of the chip and it may take a relatively long time for the average to recover from that interruption.   This is not rocket science -- it has been done before for graphics cards, for example:


John D. McCalpin, PhD
"Dr. Bandwidth"

Deje un comentario

Por favor inicie sesión para agregar un comentario. ¿No es socio? Únase ya