FAQs

What is the OpenFlight Carbon Leaderboard?

The OpenFlight Carbon Leaderboard is a community initiative aiming to provide a simple methodology and clear comparison of Carbon Impact Estimates for a range of servers while adding a light competitive edge. This service should be used to help get an understanding of the impact of resources (both physical and virtual) at various levels of load.

Currently the Carbon Leaderboard supports physical & virtual devices running Linux.

How Are Carbon Figures Estimated?

This project utilises the Boavizta API  for performing calculations based off of system specifications and collected carbon impact reports (from manufacturers).

This project uses the Global Warming Potential (GWP) metric to identify the Carbon Equivalent of the system specifications at run time (this means that estimations of impact of hardware manufacturer are not included in the value). This value is provided in grams of CO2 equivalent per hour (gCO2eq/hr).

For more information on the intricacies of the estimate, please refer to the Boavizta project documentation .

How Are Devices Ranked?

Devices in the leaderboard are ranked based on the gCO2eq/hr per core. Comparing on a per-core basis means that the leaderboard won't skew based on size of resources but will instead use a fairer method for clearer insight.

How Do I Submit Data?

Data can be submitted by running the Carbon Client script. More information about how to run this script can be found here .

Are the Values Accurate?

Calculating carbon equivalent impacts is not a simple procedure and takes in multiple factors:

Therefore, the values are merely estimates to the best of the ability of the Boavizta service (which has put considerable effort and transparency into their methodology), which can be read about on their website .

Things that are not currently considered by the leaderboard:

How Are Virtual Devices Estimated?

The estimation of virtual devices is still in early estimation and will improve over time. One of the main complexities in estimating the impact of virtual resources is through knowing the hardware that hosts the virtual system.

Some initial understanding of the hardware backing AWS instances is implemented in the underlying API which allows for a better estimation in the impact of those resources.

For other platforms (e.g. Azure, GCP, OpenStack), the underlying hardware is not known or is bespoke as is the case with private cloud solutions, such as OpenStack.

For example, it has been observed that estimations for virtual resources on OpenStack have seemed higher than expected because OpenStack will, by default, provide very little CPU layout information to instances. This leads to each core that a VM has being seen as a separate physical CPU. With more physical CPUs this will largely inflate the carbon estimates for the virtual system. It is possible to address this issue on an OpenStack deployment by defining the CPU topology .