Kasa Carbon

Kasa Carbon is a simple python package to continuously monitor and understand the power and CO2 emissions from devices connected to a Kasa enabled smart plug. It can be used to provide an easy way to evaluate the impact of the green software changes you are making.

Source: GitHub Repository

Introduction

One of the initial challenges to creating any green software project is having the ability to understand the impact of your software and evaluate the energy and CO2 impacts of the changes you are making. While I’ve written in the past about leveraging Window’s built in E3 engine I found myself in need of something which was cross-platform (i.e., supports linux), supported full system power monitoring and was more extensible. I heard about the open source project python-kasa and thought it might be a good option to extend for my needs. I have extended that library for this purposes and have released Kasa Carbon.

An Example–Comparing Perf per gCO2 Across Platforms

The Green Software Foundation provides a specification for how to evaluate green software impacts called the Sofware Carbon Intensity or SCI for short. Essentially this boils down to a perf per gCO2 unit to account for the multiple variables you can impact in a software project. I was curious about how the multiple platforms in my new mini-cluster composed of Orange Pis (running an rockchip ARM cpu) and an Intel mini-pc (running Raptor Lake mobile processor) compared on some common benchmarks.

To compute the SCI for this I needed two values: the rate of CO2 emissions for the generating the consumed power in the benchmark and the perf rate for the benchmark. I started by using the Phoronix Test Suite’s Apache Benchmark as a robust and open source benchmark. I connected each device to my HS300 and ran the Kasa Carbon application to generate the power and CO2 emission values during the benchmark run.

You can see a graph of the power data here:

There are a couple things to note in this graph.

1. The Intel device draws about between 65 and 80 watts (average 66.5) when running the benchmark while the Orange Pi draws about 7 watts (average 6.8).
2. You can also see that the Intel device is idleing around 9 watts and the Orange Pi idles around 1.5 watts.
3. The benchmarks were started at the same time but the Orange Pi ran for longer due to variance detected in the output by the test suite (there were more iteretions run during the benchmark for Orange Pi to derive the benchmark value).

Here is a table of the benchmark results across the two platforms

We can use this and the average watts during the benchmark to derive initially a perf/watt comparison betwen the two different platforms. The Kasa Carbon application also pulls the carbon intensity data for the local grid to enable the SCI score calculation (this run wasn’t long and I also live in an area with low variability primarily coal fired power so there isn’t any variance in the CO2 numbers). That being said the average emission per the update frequency (15 seconds) was 1.37E-05 mgCO2e for the ARM device and 1.34e-04 mgCO2e for the Intel device. Since our perf unit is per second we’ll use 9.13e-07 mgCO2e per second for ARM and 8.93e-06 mgCO2e per second for Intel.

We see that on the Intel platform we can perform around 1.1e+10 requests per mgCO2e emitted while on the ARM platform we can perform around 1.6e+10 (around 45% more requests per mgCO2e emitted).

Note: this is just provided as an example on the process to use the library to derive various comparison metrics. I advise benchmarking your actual application as there are many other variables which may come in to play when optizing both the perf and the power/emissions of your platform. Also these are wildly different systems and I’m running a server benchmark on non-server hardware. I’ll followup in a future post trying additional platforms and benchmarks. Also I don’t have any information about the embodied carbon of these systems so have left that out of the calculation.

Additional Information

I’ve provided some initial documentation on the [GitHub Project Page]. Feel free to try it out and let me know if you have any feedback.

System Info

Orange Pi

PROCESSOR: Rockchip ARMv8 Cortex-A76 @ 1.80GHz Core Count: 4 Thread Count: 8 Cache Size: 3 MB Scaling Driver: cpufreq-dt ondemand

GRAPHICS:

MOTHERBOARD: Orange Pi 5

MEMORY: 16GB

DISK: 512GB Sabrent SB-1342-512 File-System: ext4 Mount Options: relatime rw Disk Scheduler: NONE Disk Details: Block Size: 4096

OPERATING SYSTEM: Ubuntu 22.04 Kernel: 5.10.160-rockchip (aarch64) Compiler: GCC 11.4.0 Security: itlb_multihit: Not affected + l1tf: Not affected + mds: Not affected + meltdown: Not affected + mmio_stale_data: Not affected + retbleed: Not affected + spec_store_bypass: Mitigation of SSB disabled via prctl + spectre_v1: Mitigation of __user pointer sanitization + spectre_v2: Vulnerable: Unprivileged eBPF enabled + srbds: Not affected + tsx_async_abort: Not affected

Intel Mini PC

PROCESSOR: Intel Core i5-13500H @ 4.70GHz Core Count: 12 Thread Count: 16 Extensions: SSE 4.2 + AVX2 + AVX + RDRAND + FSGSBASE Cache Size: 18 MB Microcode: 0x4305 Core Family: Raptor Lake Scaling Driver: intel_pstate powersave (EPP: balance_performance)

GRAPHICS: Intel Raptor Lake-P [Iris Xe ] Frequency: 1450MHz

MOTHERBOARD: Shenzhen Meigao Electronic Equipment RPBNB BIOS Version: RPBNB.0.09 Chipset: Intel Alder Lake PCH Audio: Realtek ALC269VB Network: 2 x Intel I225-V + MEDIATEK MT7921K

MEMORY: 32GB

DISK: 1024GB KINGSTON OM8PGP41024Q-A0 File-System: ext4 Mount Options: relatime rw Disk Scheduler: NONE Disk Details: Block Size: 4096

OPERATING SYSTEM: Ubuntu 23.10 Kernel: 6.5.0-14-generic (x86_64) Desktop: GNOME Shell 45.0 Display Server: X Server 1.21.1.7 Compiler: GCC 13.2.0 Security: gather_data_sampling: Not affected + itlb_multihit: Not affected + l1tf: Not affected + mds: Not affected + meltdown: Not affected + mmio_stale_data: Not affected + retbleed: Not affected + spec_rstack_overflow: Not affected + spec_store_bypass: Mitigation of SSB disabled via prctl + spectre_v1: Mitigation of usercopy/swapgs barriers and __user pointer sanitization + spectre_v2: Mitigation of Enhanced / Automatic IBRS IBPB: conditional RSB filling PBRSB-eIBRS: SW sequence + srbds: Not affected + tsx_async_abort: Not affected