# Subnets with heavy compute load: what can you do now & next steps **URL:** \ **Category:** Developers\ **Created:** [October 2, 2024, 7:22pm UTC](https://forum.dfinity.org/t/subnets-with-heavy-compute-load-what-can-you-do-now-next-steps/35762 "2024-10-02T19:22:17Z")\ **Posts on this page:** 20\ **Page:** 5
**Author:** ![Manu](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/manu/32/3999_2.png) [@Manu](https://forum.dfinity.org/u/Manu)\ **Post date:** [October 15, 2024, 12:32pm UTC](https://forum.dfinity.org/t/subnets-with-heavy-compute-load-what-can-you-do-now-next-steps/35762/82 "2024-10-15T12:32:51Z")
> [@h1teshtr1path1](#): > > 1. Is there any way to pre compute additional cycles required to setup canister compute allocation to 1 (or any other value)? The cost is 10M cycles per second on a 13 node subnet. That’s roughly equal to 26T cycles per month, or 35 USD. You need to make sure that your canister holds more cycles then it needs to pay for the compute allocation for the [freezing threshold](https://internetcomputer.org/docs/current/developer-docs/smart-contracts/maintain/settings#freezing-threshold). So if your freezing threshold is X seconds, and you want to set a Y% compute allocation on a 13 node subnet, your canister must at least have X_Y_10M cycles. It is of course smart to make sure it has some extra cycles such that it wouldn’t freeze shortly after setting the compute allocation. ---
**Author:** ![skilesare](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/skilesare/32/5609_2.png) [@skilesare](https://forum.dfinity.org/u/skilesare)\ **Post date:** [October 15, 2024, 12:35pm UTC](https://forum.dfinity.org/t/subnets-with-heavy-compute-load-what-can-you-do-now-next-steps/35762/83 "2024-10-15T12:35:29Z")
This proposal seems a bit odd and off without specificts. The issue isn’t even compute. I’m sure some things can be tweaked, but the clogged subnet issue is a result of the number of canisters on a subnet at the moment. They could all be spending 1 cycle during their turn and converting them to spending 3x for that cycle doesn’t fix anyone’s problem. If some scheduler issues are fixed things may get a bit better, with scheduling throughput. I’m pretty sure you’d have to increase compute costs well above 83x to actually make people think twice about choosing the architecture that is causing this. And yes…if timers become 83x more expensive very few will use them. But the more features you add to this mix…suddenly you wake up and your platform is more expensive than anyone can justify. ---
**Author:** ![Manu](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/manu/32/3999_2.png) [@Manu](https://forum.dfinity.org/u/Manu)\ **Post date:** [October 15, 2024, 12:42pm UTC](https://forum.dfinity.org/t/subnets-with-heavy-compute-load-what-can-you-do-now-next-steps/35762/84 "2024-10-15T12:42:42Z")
**Update on the new replica version** The new replica version has reached the first busy subnet, `fuqsr`, and I’m happy to report that the first signs are looking very good. We have not seen any expired ingress messages on that subnet in the hour that it is running the new version. You can see on the [release page of the dashboard](https://dashboard.internetcomputer.org/release/aba60ffbc46acfc8990bf4d5685c1360bd7026b9) which subnets have received the new replica version. If you use canisters on one of the upgraded subnets, please let us know if you notice an improvement. ![image](https://us1.discourse-cdn.com/flex023/uploads/dfn/original/3X/4/2/42d318d2d2772357b1325bbe2114bf8e39c0ebb1.jpeg) ---
**Author:** ![skilesare](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/skilesare/32/5609_2.png) [@skilesare](https://forum.dfinity.org/u/skilesare)\ **Post date:** [October 15, 2024, 1:26pm UTC](https://forum.dfinity.org/t/subnets-with-heavy-compute-load-what-can-you-do-now-next-steps/35762/85 "2024-10-15T13:26:52Z")
My friend, I’m afraid this situation has exposed a very rough proposition for you if on-chain AI is your goal. I’m pretty sure that for anything useful that is guaranteed to compute every round and across rounds, you’re going to end up having to do the equivalent of compute allocation 100 which gets you to $3500/month really quickly and will demand some kind of extraordinary use case. You can always rent your own subnet to ensure you have priority, but I think that’s going to limit you to 4 concurrent processes for \>$16k/month I think DTS gets some kind of special priority once it gets going, but the latency to kick off your process is going to require something pretty high. ---
**Author:** ![Manu](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/manu/32/3999_2.png) [@Manu](https://forum.dfinity.org/u/Manu)\ **Post date:** [October 15, 2024, 1:52pm UTC](https://forum.dfinity.org/t/subnets-with-heavy-compute-load-what-can-you-do-now-next-steps/35762/86 "2024-10-15T13:52:24Z")
I personally see it much more positively actually. I really believe that we can get to a place where only dapps with very strong availability requirements need to use compute allocations, and that dapps without compute allocations typically still are responsive. I also think we wouldn’t need huge pricing changes for that. There is not a big problem right now with eg AI workloads, where you do a significant chunk of computation in one go. Small canisters and small messages are harder for the system. I fully agree that this needs to be worked out in more detail, but I hope and expect that we can land in a good spot with replica improvements and targeted price changes that don’t make things hugely more expensive overall. ---
**Author:** ![frederico02](https://avatars.discourse-cdn.com/v4/letter/f/7bcc69/32.png) [@frederico02](https://forum.dfinity.org/u/frederico02)\ **Post date:** [October 15, 2024, 2:47pm UTC](https://forum.dfinity.org/t/subnets-with-heavy-compute-load-what-can-you-do-now-next-steps/35762/87 "2024-10-15T14:47:59Z")
Thanks for the update Manu, much appreciated. We also have a canister on that subnet and it does appear to not timeout so far so well done 😁 ---
**Author:** ![icpp](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/icpp/32/9310_2.png) [@icpp](https://forum.dfinity.org/u/icpp)\ **Post date:** [October 15, 2024, 2:53pm UTC](https://forum.dfinity.org/t/subnets-with-heavy-compute-load-what-can-you-do-now-next-steps/35762/88 "2024-10-15T14:53:08Z")
Off course, today’s protocol will not lead to anything beyond tiny AIs doing some fun things, but I expect the protocol to change to enable experiences with larger AIs. ---
**Author:** ![TusharGuptaMm](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/tusharguptamm/32/11944_2.png) [@TusharGuptaMm](https://forum.dfinity.org/u/TusharGuptaMm)\ **Post date:** [October 15, 2024, 3:33pm UTC](https://forum.dfinity.org/t/subnets-with-heavy-compute-load-what-can-you-do-now-next-steps/35762/90 "2024-10-15T15:33:09Z")
Hi @Manu, thank you for sharing the update about the new replica version. At RuBaRu, we’ve been very thoughtful about balancing costs and our project vision when selecting the architecture (on-demand scaling, multi-canister approach, with multiple users sharing the same canister) for building the fully OnChain Creator ecosystem. Since we store rich media like videos, audios, and images directly on-chain, we anticipate significant storage demands as a social media platform. However, we expect more query calls than updates. I’m curious if there are any anticipated cost escalations for storage that could help us better estimate the scaling costs. From previous discussions, it seems computation costs may rise, while storage costs could remain steady. This information would be invaluable for us in accurately calculating and forecasting future requirements. TIA ---
**Author:** ![Lorimer](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/lorimer/32/17601_2.png) [@Lorimer](https://forum.dfinity.org/u/Lorimer)\ **Post date:** [October 15, 2024, 5:03pm UTC](https://forum.dfinity.org/t/subnets-with-heavy-compute-load-what-can-you-do-now-next-steps/35762/91 "2024-10-15T17:03:58Z")
> [@Manu](#): > > the first signs are looking very good. We have not seen any expired ingress messages on that subnet in the hour that it is running the new version This is excellent news! I’m looking forward to see how this progresses as the changes are rolled out to more subnets. Well done everybody at DFINITY! ---
**Author:** ![Mar](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/mar/32/17788_2.png) [@Mar](https://forum.dfinity.org/u/Mar)\ **Post date:** [October 15, 2024, 5:06pm UTC](https://forum.dfinity.org/t/subnets-with-heavy-compute-load-what-can-you-do-now-next-steps/35762/92 "2024-10-15T17:06:04Z")
It feels super fast for the moment (subnet lhg73). Congrats! 🥳 ---
**Author:** ![xalkan](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/xalkan/32/16076_2.png) [@xalkan](https://forum.dfinity.org/u/xalkan)\ **Post date:** [October 15, 2024, 5:07pm UTC](https://forum.dfinity.org/t/subnets-with-heavy-compute-load-what-can-you-do-now-next-steps/35762/93 "2024-10-15T17:07:06Z")
Any idea when `yinp6-35cfo-wgcd2-oc4ty-2kqpf-t4dul-rfk33-fsq3r-mfmua-m2ngh-jqe` will be updated? ---
**Author:** ![icpp](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/icpp/32/9310_2.png) [@icpp](https://forum.dfinity.org/u/icpp)\ **Post date:** [October 15, 2024, 6:09pm UTC](https://forum.dfinity.org/t/subnets-with-heavy-compute-load-what-can-you-do-now-next-steps/35762/94 "2024-10-15T18:09:18Z")
Back in business ! Thank you 🙏 ---
**Author:** ![Borlay](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/borlay/32/20894_2.png) [@Borlay](https://forum.dfinity.org/u/Borlay)\ **Post date:** [October 15, 2024, 6:16pm UTC](https://forum.dfinity.org/t/subnets-with-heavy-compute-load-what-can-you-do-now-next-steps/35762/95 "2024-10-15T18:16:42Z")
it sounds a bit strange to ask people of small dapps to pay more just because some Yral puts heavy load… Why AWS don’t ask more money from me because instagram uses a lot of resources? Why would we need cost increase if nodes running profitable? Cost increase only makes sense if nodes losing money. Other than that we end up in same situation except devs who build will pay more or projects like Yral will move away, which not good at all. If you increase price then just because Yral gonna pay more that will not help for me to get to run my app in any way. I will end up paying more and still with no resources. I see here only one potential cost increase is for hearbeats. Make everything that runs in that hearbeats cost 10x more than usual. That devs will think twice before launching 100k canisters with hearbeats in it. If that causes problems, that should be solved, but not everything else. Other thing is that we clearly need some kind of sharding. We can’t run heavy app on single node… I mean yes there is 13 nodes, but if all 13 nodes hold same data, then it’s same as running everything on 1 node and others just a backup. Yes we have subnets for that, but subnets would only make sense if that would be some kind of automatic, like you create canister and it will end up on subnet that is least used and if subnet becomes too busy some canisters automatically will be moved to other subnets without any manual interaction. Other thing is how query calls different from hearbeats? Do hearbeats run on all 13 nodes for same canister but query call will be run only on 1 node at the time? That makes sense to make hearbeats cost way more than usual query call which is for free i believe? And why do hearbeats need to run every beat? Maybe some canisters need to run hearbeats every 10 minutes only? Make that canister interface provide period at which it will be run. And if cost of that hearbeat will increase devs will choose wisely how often they want to run it. ---
**Author:** ![Manu](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/manu/32/3999_2.png) [@Manu](https://forum.dfinity.org/u/Manu)\ **Post date:** [October 15, 2024, 6:47pm UTC](https://forum.dfinity.org/t/subnets-with-heavy-compute-load-what-can-you-do-now-next-steps/35762/96 "2024-10-15T18:47:39Z")
are you experiencing any issues on `yinp6`? From the metrics it looks like it is not overloaded at all. ---
**Author:** ![sea-snake](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/sea-snake/32/7243_2.png) [@sea-snake](https://forum.dfinity.org/u/sea-snake)\ **Post date:** [October 15, 2024, 6:48pm UTC](https://forum.dfinity.org/t/subnets-with-heavy-compute-load-what-can-you-do-now-next-steps/35762/97 "2024-10-15T18:48:00Z")
> [@Borlay](#): > > Make that canister interface provide period at which it will be run. If I remember correctly, it’s already possible with timers to do so, heartbeats are the older approach that was available before timers were introduced back at the end of 2022. As for why timers and heartbeats are update calls that go through consensus, any call that modifies state goes through consensus and is thus an update call. Query calls do not update state and thus do not need consensus, doing query calls on a heartbeat or timer wouldn’t be very useful since they wouldn’t update the state. ---
**Author:** ![Borlay](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/borlay/32/20894_2.png) [@Borlay](https://forum.dfinity.org/u/Borlay)\ **Post date:** [October 15, 2024, 6:54pm UTC](https://forum.dfinity.org/t/subnets-with-heavy-compute-load-what-can-you-do-now-next-steps/35762/98 "2024-10-15T18:54:19Z")
> [@sea-snake](#): > > As for why timers and heartbeats are update calls that go through consensus, any call that modifies state goes through consensus and is thus an update call. > > Query calls do not update state and thus do not need consensus, doing query calls on a heartbeat or timer wouldn’t be very useful since they wouldn’t update the state. That makes sense, why would you need query call on a timer. ---
**Author:** ![icme](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/icme/32/4327_2.png) [@icme](https://forum.dfinity.org/u/icme)\ **Post date:** [October 15, 2024, 6:54pm UTC](https://forum.dfinity.org/t/subnets-with-heavy-compute-load-what-can-you-do-now-next-steps/35762/99 "2024-10-15T18:54:19Z")
Well done 👏 ! Confirming that we haven’t seen any expired ingress messages on our side over the past 6 hours on `3hhby` ---
**Author:** ![xalkan](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/xalkan/32/16076_2.png) [@xalkan](https://forum.dfinity.org/u/xalkan)\ **Post date:** [October 15, 2024, 7:02pm UTC](https://forum.dfinity.org/t/subnets-with-heavy-compute-load-what-can-you-do-now-next-steps/35762/100 "2024-10-15T19:02:09Z")
Yes, the ingress expiry issue. ---
**Author:** ![TusharGuptaMm](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/tusharguptamm/32/11944_2.png) [@TusharGuptaMm](https://forum.dfinity.org/u/TusharGuptaMm)\ **Post date:** [October 16, 2024, 6:42am UTC](https://forum.dfinity.org/t/subnets-with-heavy-compute-load-what-can-you-do-now-next-steps/35762/102 "2024-10-16T06:42:00Z")
That seems to have resolved the issue! Our DApp is back to normal and working smoothly. We’ll keep an eye on it with some extra load testing. Thanks for @Manu and team! ---
**Author:** ![rbole](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/rbole/32/1334_2.png) [@rbole](https://forum.dfinity.org/u/rbole)\ **Post date:** [October 16, 2024, 7:08am UTC](https://forum.dfinity.org/t/subnets-with-heavy-compute-load-what-can-you-do-now-next-steps/35762/103 "2024-10-16T07:08:26Z")
Will this fix also work on the European Subnet ?? [Previous page](https://forum.dfinity.org/t/subnets-with-heavy-compute-load-what-can-you-do-now-next-steps/35762.md?page=4) [Next page](https://forum.dfinity.org/t/subnets-with-heavy-compute-load-what-can-you-do-now-next-steps/35762.md?page=6)