# Assessment and Calculation | Compute methodology
Source: https://greenpixie.com/docs/methodology/cloud-compute/assessment-and-calculation

The calculation components and their outputs.

## 7.1 Processor Power Derivation [#71-processor-power-derivation]

A published server measurement covers the whole machine, including memory and storage devices chosen by whoever submitted it. Greenpixie first removes those components, using the memory module power reference and the drive power reference in Sections 5.5 and 5.6, leaving the electricity attributable to the processor and its chassis at each measured workload level. Greenpixie rejects any measurement where the components removed would account for more of the system total than those references support.

The remaining figure is divided by the hardware thread count of the machine measured and averaged across every matched measurement, giving electricity per vCPU at each workload level. That figure includes chassis overhead.

A processor a cloud provider designs for its own fleet is never sold, so no server carrying one can be submitted for measurement. Such a processor takes the measured per-thread curve of the closest related processor in the published measurements. The whole curve is scaled according to the ratio between the two clock speeds, and again by one published per-core factor where the core generation differs. The relationship between clock speed and power that the scaling follows is read from a chip vendor's own product ladder. On such a ladder, one processor design is sold at several clock speeds, each with a published power. Section 11.3 states the uncertainty this derivation carries.

## 7.2 Memory Power Derivation [#72-memory-power-derivation]

The memory removed from the published measurement is replaced with the memory the cloud host is modelled as carrying. Host memory capacity follows from the instance memory allocation and the number of instances of that instance size the host is modelled as running. Capacity per module follows from the module slot and socket count of the processor.

Module electricity is read from the memory module power reference, by memory generation and capacity, at a fixed module activity level. The same module figure is counted at every workload level of the curve.

## 7.3 Accelerator Power Derivation [#73-accelerator-power-derivation]

An instance carrying accelerators takes a proportion of each accelerator's rated power, multiplied by the number of accelerators attached. Where a chip vendor publishes a separate rated power for each form factor of the same model, Greenpixie reads the figure for the form factor the accelerator is sold in. The form factor an instance carries is taken from the cloud provider's own instance documentation. The proportion is measured by Greenpixie, as described in Section 5.7.

## 7.4 Local Storage Power Derivation [#74-local-storage-power-derivation]

The drives removed from the published measurement are replaced with the drives the cloud host is modelled as carrying, resolved as described in Section 6.4. The drive type and capacity rules of Section 6.4 also classify the drives disclosed with the published measurement. Greenpixie reads the same drive power reference when it removes the drives disclosed with a published measurement and when it adds the drives the cloud host is modelled as carrying.

Every drive is counted at its idle draw. A cloud provider's usage report does not show how heavily a customer uses a drive. Section 11.3 states the uncertainty this treatment carries.

Idle draw is read from the drive power reference, by drive type and by capacity per drive. That reference holds a figure at each of a series of capacity points for each drive type. A capacity between two points takes an interpolated figure.

## 7.5 Operating Point Selection [#75-operating-point-selection]

A cloud provider's billing data states an instance's size and its duration. It states no processor utilisation for the workload that ran on it, so Greenpixie reads one operating point from the curve for every unit of cloud usage.

For a standard instance Greenpixie reads the same fixed operating point at every instance size, being one of the load levels the published server measurements record directly. A load level is a share of the throughput the measured server reached at full load. It states nothing about the processor utilisation of any workload running on the instance.

For a burstable or shared-core instance the operating point is the cloud provider's own published baseline allowance for that size. A burstable or shared-core instance size is calculated against a curve Greenpixie rebuilds from the measured curve, read at that allowance. Only the electricity attributable to the processor and its chassis is scaled by the allowance. At every size the instance's share of the host's memory modules and drives is counted in full, as they draw their power however much of the allowance the instance uses.

Some burstable families run by default in a mode where the cloud provider bills usage above the baseline allowance separately, as processor credits of one vCPU-hour each. Each of those credit hours is calculated as one vCPU at full load on that family's own host. No memory or drive electricity is added to a credit hour, as both are already counted on the instance-hour the credit accompanies.

## 7.6 Billing Unit Conversion [#76-billing-unit-conversion]

The per-instance figure is converted into the usage unit the SKU is billed in and joined to the cloud provider's billing catalogue. Where a cloud provider bills an instance size that is sold with fewer active vCPUs than the underlying machine provides, the size is calculated against the whole machine. A function or container service billed per vCPU of allocated capacity, and not as an instance, takes a per-vCPU rate.