We would like you to help us check this subnet as there’s an error in it that’s affecting BONE mining.
Here’s the subnet: brlsh-zidhj-3yy3e-6vqbz-7xnih-xeq2l-as5oc-g32c4-i5pdn-2wwof-oae
What are the canisters that are affected? Can you please also provide the full details on what are the issues that you are experiencing?
3 Likes
Could you provide more details on what the problem is, the subnet seems to be fine.
1 Like
I’m not an expert, but over the last two days, I noticed various messages about this particular subnet. Most concluded that it was healthy, although it was mentioned that some canisters there were overloaded. Maybe you can share more details?
2 Likes
That seems to be the general consensus, probably an issue with the canisters.
1 Like
Here’s the canister ID of the dApp: 2hrv7-oaaaa-aaaai-ap7va-cai.
With my layman understanding, data relating to mining which includes number of active miners are not showing on Bone.fun website. We have more than 1000 miners and only 9 is currently showing. Also data relating to dog alliance which is our mining pool is not showing for individual’s accounts.
1 Like
During the period of the failure, the cycles consumption of the entire subnet was zero, and when we sent an update request to the canister, the following error occurred.
1 Like
I think I don’t have the right to dm you but I have provided all the information you requested under this topic.
Kindly look into it and help us to resolve it as this is creating uncertainties in our community.
1 Like
We would need more information on how the data is displayed on the website?
Is it using an update function in 2hrv7-oaaaa-aaaai-ap7va-cai? Does the function call other canisters? When are the errors that you are getting?
2 Likes
This is the error it is bringing.
For answers to other questions, I would to wait until our dev is online
2 Likes
I am not familiar with this error so I will send to our engineering team and will follow-up ASAP.
In the meantime, can you also check with your dev if other update calls are working in this canister?
I am trying to gather all information that the engineering team may need to troubleshoot this better.
1 Like
Occasional subnet failures are common on the ICP chain, especially when the subnet experiences high call volumes. As long as the subnet can self-heal or roll back in extreme cases, there are generally no major issues.
Such issues are also common in projects like ICPSwap and BOB, but they do not affect the project.
One of the error is that we have more than 1000 active miners and only 16 are showing, there were time when non is even showing.
The second one is that the mining weight and other details of Dog alliance (mining pool) are not showing.
1 Like
FWIW, this is not a subnet failure. The subnet itself is chugging along at 1.4 blocks/s and some 10 B instructions per round (while 3.5k canisters’ timers fire all at once and result in tons of DTS executions; this is the source of the heavy load on the subnet).
But there does seem to be something else that needs to be looked into. I’ll ping the team.
That’s just an artifact of how we measure cycle consumption. We don’t track separately cycles actually burned vs cycles reserved for response delivery and execution; so when a canister makes a call, we reserve the maximum number of cycles for the response and later, when the response comes in, we refund (usually) most of that amount and the counter goes up and then down. But if a lot of calls are made at one time, then the “cycles burned” count increases a lot, then goes down by a lot. And until the subnet actually burns through that amount of cycles, it will appear to be burning zero cycles per second.
This is something that’s being worked on, AFAIK, because as you can see it’s a very confusing metric, as is.
4 Likes
Thanks alot for looking into this.
As a miner want to express my concers
This issue is creating uncertainties within the community, and timely resolution is crucial to restoring confidence and mining efficiency. Those who mine are burning ICP every second and dont have access to their miners (over 1000 now) and dont get rewards. This can impact the value of the mined token on the open market
Thank you for your continued support. Hope this will be resolved soon I hope you are in direct contact with the actual devs of bone.fun so communication can be clear
2 Likes
Are you now saying that there’s no immediate solution to this?
Honestly speaking, this is not good for ICP image and it has already bought alot of fear and uncertainty to our project.
As far as I know, the issue is not from the project itself but from the subnet, so solution to it can only comes from the foundation.
The platform has been running for two months and its control is under an SNS DAO.
This need to be fix ASAP!
1 Like
OK i have some working thesis: there is a code which reads canister cycle on each miner - there is the problem. Can you please tell the devs to check that part? I just topped up miner with nftgeek and it toppup works everything UI works - but the miner/canister still is stopped with protocol error - Miner halted low cycle balance (screenshot). The problem is there, in reading the cycles of each canister/miner (my thesis could be wrong I am not competent for this)-
OR : if there is database of the old miners maybe it is deleted? or disconnected from the propotol ? The protocol does not include old miners into mining
Miners burn cycles but they are not included in the reward mechanism somehow. Because of that it seems that the aliances are empty cause all miners are somehow disconected.
No new miners can be created or old ones upgraded. But somehow several miners are alive like 0.2% of all and they are getting rewards.
Another thing I just encountered on twitter from @icpurpz:
“$ICP $bil miner is inactive since 3 days now. Dunno what I can do. @BIL_ICP
Is this still a subnet issue? How can we restart miners?”
The whole issue started when their project went live could this be somewhat related since they also have 3 days similiar issues?
2 Likes
To put it bluntly, there’s no way around sharing a subnet with 3k+ canisters with timers that result in multiple round executions. There are some fairness tweaks that we are looking into (calling a canister that’s not one of the 3k should not result in an ingress timeout); but you won’t be magically getting 2 second latency because that’s just not possible when 3k canisters (plus yours, thrown into the mix) each want to do something that takes 1+ round to complete all at once.
We are working on canister migration and on streamlining subnet splitting so you won’t get stuck forever next to a misbehaving bunch of canisters. But it’s always going to be the case that without guaranteed resources (in this case, compute allocation) you get best-effort behavior (which will at times make your application unusable).
2 Likes
still to this moment… I have many dog miners that ive spent alot of money on… They burn my cycles and they show blocks being mined… but I never receive my $bone… where is my $bone that my miners have been mining? are they going into some random wallet? are they waiting for me? can we get some answers? this is been going on for too long now…
2 Likes
everything seems to be working when it comes to taking my money…
2 Likes
Agreed - feels more like a scam every day it’s burning cycles while my miner is stopped.