So as far as I know, x4jtx-5dnbo-v3exa-vzamo-teufh-qsiit-txx4g-mi76n-ckrfl-oc5a6-nae is the subnet where MultiDex and only MultiDex is running. That pages shows 600 million executed instructions per second (MIEPs). For one single application (though it might have many canisters). And roughly 1 billion cycles burned per second.
How can it be that, when looking through the other subnets on the dashboard, most others are completely idling? There is for example qdvhd-os4o2-zzrdw-xrcv4-gljou-eztdp-bj326-e6jgr-tkhuc-ql6v2-yqe, a net with 60 THOUSAND canisters, yet just 300 MIEPs and 800 million cycles burned.
Or take eq6en-6jqla-fbu5s-daskr-h6hx2-376n5-iqabl-qgrng-gfqmv-n3yjr-mqe: 90,000 canisters yet only 27 MIEPs.
Are all of these canisters in fact dead or do they just hold data and are meant to not consume resources? Or is MultiDex already this compute-intense, even in demo mode?
Somewhat yes and yes. Most are HotOrNot canisters, they made canister for every user, what basically is doing nothing. There was added monthly cycle fee to every canister (low amount), so those should be deleted at some point, no way they top up to 400k-600k useless canisters, if they do than need to increase monthly cycle fee.
I do have 23 token canisters that currently waiting for ICP to move so they can be added to dex, those sitting idle, soon need to top them all up (burn ICP)
Idle canisters cost almost nothing in compute. Storage is charged continuously, execution only when something runs. 60,000 canisters holding data and doing nothing is entirely consistent with 300 MIEPs. They aren’t dead — they’re parked.
As for the scale: 1 billion cycles/sec is 86.4 trillion cycles/day. The peg is fixed at 1 trillion cycles = 1 XDR, and ic-api currently gives 1 ICP = 1.6141 XDR, so that subnet is burning roughly 53.5 ICP/day.
For context, the whole network’s burn to cycles has averaged about 2,000 ICP/day over the last nine days. So one busy subnet is a couple of percent of it — real, but not anomalous.
The caveat is that “average” is doing a lot of work there. The daily figure moved by a factor of 32 inside those nine days. I’m writing that up separately.
Both things are true. Most canisters mostly sit idle holding state, they only burn cycles when actually processing a call, so a subnet with 90k canisters can look dead if traffic is low. Instructions per second tracks active execution, not storage. MultiDex likely runs tight loops or frequent inter-canister calls, which spikes MIEPs even with one app. Volume of canisters isn’t the driver, activity is.
