Power Measurements using performance counters CSL862: Low-Power Computing By Radhika D (2014SIY7530)

Transcription

1 Power Measurements using performance counters CSL862: Low-Power Computing By Radhika D (214SIY753)

2 1 Objective: To observe and note the performance and power consumption of Raspberry PI for various benchmark under various settings. 2 Hardware Details of Raspberry Pi: 9MHz quad-core ARM Cortex-A7 CPU 1GB RAM 4 USB ports 4 GPIO pins Full HDMI port Ethernet port VideoCore IV 3D graphics core 3 Setup: 1. To measure current Raspberry Pi was connected to power via USB ammeter. USB ammeter gives current and voltage being consumed by entire raspberry Pi system. We used differential method to get the power numbers for benchmarks. USB ammeter does not give online logging facility so all the logging was done manually. 2. Assignment was to run the benchmark on single core, two core, three core and all cores. Since cores are shared among processes and operating system does the scheduling by default we don't have control over number of processes being run on any given core. Thus the performance and power measurements may not be appropriate. So we isolated CPUs (cores) so that none of the kernel jobs or any other processes are run on these cores. And we used these cores to exclusively run the benchmarks. Since Raspberry Pi has 4 cores we were able to isolate 3 CPUs and one CPU was kept for the kernel and other processes like ls, top etc. We configured isolcpus=1,2,3 in cmdline.txt to isolate core 1, 2 and 3 and kept core for the kernel and other processes. 3. System Tools: i. To measure performance we used perf tool. ii. Operating frequency is updated by kernel in the file cpuinfo_cur_freq. There is one such file for each core. We used /devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq to note frequency on each

3 CPU during execution of testbench. Since raspberry pi is homogenous system all the cores run at same frequency even when some of the cores are idle. iii. Apart from this we used top tool with option 1 to see the utilization and state of the CPU. 4 Benchmarks For Raspberry Pi we didn't have standard testbench suite. We used following testbenches which are modified to run on Raspberry Pi. i. Linpack We had to modify makefile of the standard linpack testbench available and compile it for Raspberry Pi. The values of p and q in hpl.dat file specifies number of nodes the testbench is supposed to run. We specified the value of p and q as 1. For different numbers it was creating threads multiple threads but was running on the single core instead of multiple cores. So we kept p and q as 1 and ran multiple instances of the testbench each on different CPU. ii. iii. iv. Mprime Mprime was written for x86 and x86-64 processors and not arm. But raspberry Pi processor is based on armhf architecture. So there were no standard testbench for this, so we had to download a tailor made Mprime program from internet. ( Also used sysbench tool. FileIO Used sysbench utility tool provided by Ubuntu. This tool provides various testbenches but we used it for mprime abd FileIO only. To measure performance and power under fileio we used this utility tool to create 128 files each of 16MB size (total of 2GB data). WhileLoop v. Dhrystone Dhrystone benchmark measures integer performance of the processor. There are two versions available of which we have used Dhrystone 2 (second version). This benchmark was defined by Roy Longbottom. vi. Whetstone The Whetstone benchmark primarily measures the floating-point arithmetic performance. It was one of the first general purpose benchmarks that set industry standards of computer system performance and was written in Fortan. More information can be found in written by Roy Longbottom who carried out further development in Whetstone. 5 Results Power Measurements: Each Benchmark was run for 5 times under each configuration. Current and Voltage value was noted down manually for each iteration from ammeter. Power was calculated and averaged for each iteration. Performance numbers given by perf tool was saved in a file. Following gives the graph of the power consumed by the processor while running each benchmark

4 Avg.Power (mw) while running on single core, 2 core, 3 core and 4 core Power Consumption from USB Benchmarks 1 Core 3 Core 4 Core Fig 1: Power verses Benchmarks run on single core, 2 core, 3 core and 4 core. While running benchmarks, linpack, mprime and Dhrystone, on 1 core, 2 core and 3 core we see power requirement increases. But when running on 4 core power requirement decreases except for Whetstone. This is mainly because ammeter is unable to output the power required to run these benchmarks on 4 cores running at 9Mhz and thus toggles between min. freq of 6MHz and default freq of 9MHz. While loop showed slight increase in power with increase in cores as there was only single math operation of increasing the loop counter. Seq Wr, Seq Read and random Wr as expected showed constant power consumption irrespective of cores since they are memory intensive benchmarks and not CPU intensive. Following figure gives the power used by peripherals of RaspberryPi2.

5 1 Cor e 2 Core 3 Core 4 Core peripherals HDMI Eth idle eth+cpu(internet) We measured power by differential method by pulling out each cable. For HDMI port even though monitor was not connected and only HDMI cable was connected Raspberry Pi2 still pulled power required by the HDMI port. Power consumed by these peripheral can be reduced by changing their configuration in config file. Performance: We measured performance by running each testbench individually on each core. Following figure gives the performance of linpack and mprime when run on 1 core, 2 core, 3 core and 4 core. It gives the time taken to execute the benchmarks. Performance (time in seconds) Core Core mprime linpack

6 1 Core 3 Core 4 Core 1 Core 3 Core 4 Core In the above figure we see that upto 3 cores we don t see much effect on the performance but when we run on all the core performance decreases drastically and this is because Raspberry Pi was unable to get enough power to execute these benchmark on all 4 cores and thus operating frequency was reduced to 6MHz. Also we observe that core is taking much more time to execute the benchmark and this is because we have reserved core1, 2 and 3 and thus only core is available for the kernel operations and other applications like top and watch. Dhrystone (MIPS rating) Whetstone(MWIPS) Core Core Core 1 Core Performance measurement for Dhrystone is given in MIPS (million instruction per sec) ratings and Whetstone it is given in Million whetstone IPS. Here when we run these two benchmark on all 4 core we do not see performance degradation as seen in Linpack and Mprime because raspberry Pi was able get enough power to execute these benchmarks. Here also we see that core is under performing. Performance of core2 and core3 was observed to be better compared to core 1. 6 OverClocking: Source : By default Raspberry Pi2 gives max 9 MHz and 6 MHz operating frequency. This is the most conservative settings ensuring that Raspberry pi does not cross the thermal limit of 85 deg Celsius. When you say you overclocking a system, it means you are trying to run the system at higher frequency then the default settings. As mentioned default settings are always conservative and thus there is always scope for running the processor at higher frequency before the thermal limit it hit. Earlier Raspberry pi had sticky bit inside BCM2835 which would get set when overclocked and the warranty would become void. This was because in the initial Pi releases over clocking system would permanently run it at overclocked speeds and possibility of damaging or reducing the life span was higher.

7 In later release of Raspberry Pi turbo mode was introduced which dynamically enables overclock and overvolt under the control of a cpufreq driver. With help of this Driver and keeping tap on the BCM2835 s (compute module) internal temperature turbo is applied only when busy and the temperature is less than thermal limit. To configure overclocking on raspbian OS there is rasp-config tool which gives set of predefined overclocking configurations which user can choose from. This tool internally updates config file accordingly. But on Ubuntu we have to modify config.txt file (/boot or /boot/firmware) directly. Following are the parameters that were modified during the testing: <snip> arm_freq = 1 sdram_freq = 5 core_freq = 5 over_voltage = 4 <snip> arm_freq gives the max frequency of the CPU, sdram_freq gives that of sdram, core_freq sets the GPU max frequency. over_voltage increases voltage in step of.25v. 1.2V being the default which is over_volatge =. For turbo mode we need to set over_voltage to 6 and above but at the risk of reducing the lifespan or damaging the board. We conducted overclocking experiments for Linpack, Dhrystone and Whetstone. For 11MHz we were able to run test-bench on just two core but with three core it toggled between 6MHz and 11MHz, since our ammeter was unable to output the required power. Max power ammeter can supply was 3.7W, whereas Linpack on two core itself consumed peak power of 3.6W (.69A and 5.21V). With ammeter removed and suppling the power directly we were able to run on 3 core but with 4 core the system hung. Thus we could conclude that system becomes unstable with all 4 core busy at 11MHz. We later conducted tests with 1MHz and 15MHz core frequency without ammeter. System was stable even with all 4 core busy at 15MHz. Since performance on 3 core is same except for core as seen before we are showing the results of benchmark on one core (core with good performance) for various frequency. Though we have readings for all cores and is given in document given along with this document. Whetstone (MWIPS) Dhrystone (MIPS rating) MHz 1MHz 15MHz 11MHz 9MHz 1MHz 15MHz 11MHz

8 Linpack (execution time in secs) MHz 1MHz 15MHz 11MHz As expected performance is increased by overclocking. But as we see we don t see much gain as we increase the frequency. Because of the power limit posed by the supply we used we were able to go upto 11MHz. But some people have achieved upto 15MHz by modifying the charging circuit and using nitrogen cooling system. Such systems are extremely over clocked and are at risk of reducing the life span of the board especially when they choose over_volatge = 6 or above setting. Similarly we tried various operating frequency for SDRAM but the output were not conclusive. 7 Conclusions When we run test bench on all 4 cores, core cpu-freq fluctuates between 6Mhz 9MHz mainly because the power supply was unable to provide the required power to run the test benches. Default thermal limit is 85 deg Celsius for any testbench is temperature increases beyond 85 deg Celsius system become unstable or reduces to 6MHz. For File IO CPU-freq is at 6MHz since CPU utilization is very less. Since all the testbenches are run on dedicated core 1,2 and 3 and Only core is shared for housekeeping, other apps like top. Thus performance of core for all the test-benches was poor when compared to other cores. Raspberry PI-2 does not switch the drivers off when device connected to it does not exist or is in idle state. Thus power consumed in idle state is high. Though Raspberry Pi2 gives the option of modifying config file in order to change the peripheral settings for either performance or power efficiency. We can also get the last drop of performance improvement from Raspberry pi2 by overclocking and overvolting the system but should be done with caution.