QUESTION: What constitutes idle_cycles_burned_per_day and how is it measured?

Developers
1

We are setting up a measurement mechanic that helps us figure out our major cost centres and where our cycle spends are majorly happening.

We are looking at tracking the idle_cycles_burned_per_day per canister and making inferences based on that.

A couple of additional questions that we have are:

  • Is the idle_cycles_burned_per_day returned by calling ic_cdk’s canister_status method as defined here computed exactly as defined here and here?
  • Does this value account for cycle transfers to other canisters? For example, a parent canister topping up a child canister.
  • Does this value account for cycle burn due to canister creation? For example, a parent canister provisioning new canisters by calling the management canister and paying the 0.1T canister creation fee
  • Does this value include elevated canister usage seen during heap based upgrades? Essentially when serializing to and deserializing from stable memory during a canister upgrade.
  • What is the trigger that kicks off this calculation on a daily basis? Or is this calculated frequently and an average derived from multiple entries during the day?

Thoughts?

@ulan @dsarlis

2

As the name suggests, the value returned in idle_cycles_burned_per_day represents the amount of cycles that your canister is burning when not taking any actions and because of resources it consumes (e.g. memory or compute allocation). The relevant excerpt from the interface spec that should be explaining what is included

The (unspecified) function idle_cycles_burned_rate(S, cid) determines the idle resource consumption rate in cycles per day of the canister with id cid , given its current memory footprint, compute and storage cost, and memory and compute allocation. The function freezing_limit(S, cid) determines the freezing threshold in cycles of the canister with id cid , given its current memory footprint, compute and storage cost, memory and compute allocation, and current freezing_threshold setting

You can also inspect the implementation to see how this value is computed.

With the above the answer to most of your questions is “no, the cases you’re interested in are not included”. Specifically:

  1. Cycle transfers are not included, these cycles are not burned anyway, they’re sent to another canister.
  2. Canister creation is not included.
  3. Consumption during heap based upgrades is not included.

What is the trigger that kicks off this calculation on a daily basis? Or is this calculated frequently and an average derived from multiple entries during the day?

The value is computed on demand whenever canister_status is called or the system needs to compute the current freezing threshold (in cycles) for the canister. The point of this value is to give you a rough measure of how many cycles you’ll be paying for resource usage and allocations you might be using per day. The main value you can get out of this is to estimate when your canister would be frozen (and e.g. top it up automatically before it gets frozen). If you want to track the other consumptions you mentioned you’d need to do it in the canister for now.

2 Likes