Mining for the pool doesn't seem to be working for me since the introduction of ABN. My debug console is saying this: "gsc_errors": "low abn weight 0", "poolmining": true, "pool_url": " https://pool.biblepay.org", "required_abn_weight": 256000 "Command": "getabnweight", "version": 1.1, "weight": 307379.4657638889, "total_required": 286408 Any idea what could be wrong? Thanks! yeah , i'm also wondering why mining won't start : {
"Command": "getabnweight",
"version": 1.1,
[b] "weight": 274797.669525463,[/b]
"total_required": 4383370,
"coin_age_data": "696007.5834(0.04)=[29612.52] depth=13, \n3471778.8328(0.04)=[147711.30]
depth=13, \n165899.5165(0.34)=[56169.48] depth=75, \n581.2655(1.38)=[802.40] dept
h=296, \n5456.2700(1.87)=[10177.65] depth=402, \n0.0648(2.28)=[0.00] depth=479,
\n36413.3417(0.42)=[15434.22] depth=86, \n",
"weight 259000.00": 259907.5719097223,
"total_required 259000.00": 4376136
}
"poolinfo3": "",
"gsc_errors": "low abn weight 0",
"poolmining": true,
"pool_url": "https://pool.biblepay.org",
"required_abn_weight": 256000 mining started although after my abnweight went a bit up from 274797 I am mining as well but very slowly and intermittently, and it still says my abn is 0 even though it's over 300k. 3 miners running the same wallet showing different abnweight  {
"Command": "getabnweight",
"version": 1.1,
"weight": 878829.5629976852,
"total_required": 4383370
{
"Command": "getabnweight",
"version": 1.1,
"weight": 165733.9069791667,
"total_required": 911591
}
{
"Command": "getabnweight",
"version": 1.1,
"weight": 189473.1778125,
"total_required": 911591
}
}How do we know you didn't find a block between the time you typed the command? And yes, ABN weight changes over time (as would be expected with coin age), so I wouldnt expect it to necessarily match unless you can guarantee you can type the command into all 3 at the same time, and show us all 3 are mining the same block concurrently with the same number of threads and all 3 synced to the same height. |
|
|
|
So I am noticing something funny in the windows miner calculations on ABN. Maybe I just don't understand the calculations enough but here is what I see
When running exec getabnweight 256000 1 I get the following output
{
"Command": "getabnweight",
"version": 1.1,
"weight": 334184.134375,
"total_required": 300610,
"coin_age_data": "173.0000(1.91)=[331.21] depth=410, \n24844.0227(2.44)=[60651.57] depth=498, \n658.0000(2.78)=[1832.00] depth=572, \n5999.9000(3.40)=[20402.09] depth=693, \n611.0000(3.48)=[2123.88] depth=712, \n39459.7973(0.84)=[33099.43] depth=177, \n210427.3141(0.84)=[176512.69] depth=177, \n",
"weight 256000.00": 294952.8723611111,
"total_required 256000.00": 282173
}
When I look at the debug log I see the following for CreateABN
2019-06-26 13:55:15
***** CreateNewBlock::Unable to add ABN because CreateABN::Fail::(Create Transaction) Insufficient funds.::TargetWeight=294953, UsingBBP=282173.00, I=25, NeededWeight=256000, GotWeight=230516.75 *****
2019-06-26 13:55:20 ERROR: TestBlockValidity: Consensus::ContextualCheckBlock: (code 0)
Not sure why a couple of things are being displayed
1. Why does CreateABN have a different GotWeight that getabnweight : "weight 256000.00": 294952.8723611111 <> GotWeight=230516.75 *****
2. Why does CreateABN have a different UsingBBP than The total amount of BBP in the wallet when no immature blocks : "total_required": 300610 <> UsingBBP=282173.00
Anyone know what this line means?
2019-06-26 13:53:02 ERROR: AcceptBlockHeader: Consensus::CheckBlockHeader: c982c3e05e4b59a9b559e26600e56bc621c8baa158439d63f7e4e5b97488125a, high-hash, proof of work failed (code 16)
Finally, once a block has been found and ABN is low, anything other than 1 or 2 threads in the miner seem to send the process into not responding state in windows as others have pointed out.
Fortunately, I do see 2 issues with our current ABN, and I believe after this - we will see this problem addressed in the next version. It appears we had 2 problems (one additional case for ABN transactions) that needs addressed. This additional case causes a discrepency. So - please let me address this issue, and the performance issue, and while we are compiling, then I will come back and reply to all these questions everyone has. |
|
|
|
New version .8 installed Windows 10
setgenerate true 50 CPU load about 50%
In the meantime I solved a block... so I have the following after block solve
If gen=1 and genproclimit=40 and minersleep =0 in conf Then Wallet freeze (not responsive) - CPU load about 0-1%
if gen=1 and genproclimit=8 and minersleep =0 in conf then Wallet freeze (not responsive) - CPU load about 0-1%
if gen=1 and genproclimit=8 and minersleep =5 in conf then Wallet freeze (very slow response) - CPU load about 0-1%
if gen=1 and genproclimit=4 and minersleep =0 in conf then Wallet freeze (slow response) - CPU load about 0-1%
if gen=1 and genproclimit=3 and minersleep =0 in conf then Wallet freeze (a little slow response) - CPU load about 0-1%
It sounds like what you all are telling me is its lagging when it doesn't have enough abn weight. I've been focusing on issues where we lag when we Have ABN weight And we were mining. OK, that gives me something else to look at. I'll try to simulate that and reproduce. |
|
|
|
|
BiblePay
1.4.3.8-Leisure Upgrade
- Add spent_amount and spent_time to getrawtransaction output
- Add POG rule to prevent sanctuary scalping
- Added deadlock mutex in CreateAntiBotNetTransaction
** 1.4.3.8 has been re-deployed **
|
|
|
|
|
Remember, if anyone has a lag on the next version, try minersleep=5 and verify the HPS is still 99%, and no lag exists.
If you have no lag then keep minersleep=0.
Also, tell us if there is no lag with a proclimit of < 10 as compared to when you overload the proclimit (> machine core count).
|
|
|
|
Windows is working great, Slovakia, please see PM.
Rob, does this mean you believe .8 is out there now? It's being redeployed but it takes a while due to the last step - I believe it will be out in < 10 mins (roughly). I'm waiting for it and will re-post when it redeploys successfully. |
|
|
|
|
Windows is working great, Slovakia, please see PM.
|
|
|
|
Is 1.4.3.8 out for 64bit Windows?? Only downloading 1.4.3.7 from the link
yes, 1437 for win only Is this by plan Slovakia or just a miss on the page setup? Do you know? Seems like the .8 release is supposed to fix some of the non responsiveness of the gui Its being regenerated; glitch being fixed now; 1438 will be redeployed very soon. |
|
|
|
Is 1.4.3.8 out for 64bit Windows?? Only downloading 1.4.3.7 from the link
Hmm your right, let me check whats wrong. |
|
|
|
|
Could someone that experienced a deadlock after finding a block, or a lag try 1.4.3.8?
MIP has already deployed all versions.
This version technically only addresses the deadlock after finding a block (not the lag).
One other thing I need help with: Please try minersleep=10 and multiple threads, let me know if the lag stops but the HPS is still 99% high (as since threads overlap, you should still technically get the HPS from the machine). We just want to see if the UI is usable.
I make all assumptions that you are running QT and having a problem typing commands in the debug console. Not in the linux bash shell.
|
|
|
|
|
BiblePay
1.4.3.8-Leisure Upgrade
- Add spent_amount and spent_time to getrawtransaction output
- Add POG rule to prevent sanctuary scalping
- Added deadlock mutex in CreateAntiBotNetTransaction
|
|
|
|
Hi,
now I'm using all of my coins only for mining.
Today I solved 9 blocks. I'm using 1436 version on my VPS and 1437b on WIN. Yes, it is laggy, but it works. It looks that I need around 2 hours to reach 256k weight again, I hit the block, It spends all of my coins for ABN and then it goes round and round again. I have not used exec bankroll, but maybe I ll try it. But definitelly it looks, that it is not neccessary, because when you mine all the time, I always hit the block right after all of my coins have coinage 256k and they are spended all.
Well the reason I ask is we really had the same hashpower before ABN, and the only difference with ABN is it creates an ABN transaction before it starts mining. Thats not a huge dent in horsepower (since a transaction is guaranteed to last at least 60 seconds). So when you say lag, please tell us if you used to lag before ABN, or if this is new. And what does lag mean exactly? Im running a windows miner with just 5 threads, and I can type fine into the debug console in QT and notice no lag. But I have always been afraid to set up 20 threads - regardless of ABN or not, as the whole machine starts to lag. Which is normal if you use 100% of the processor on every core. |
|
|
|
|
Best solution we have for overloading the server with > 20 threads:
- Upgrade to 1.4.3.8 to prevent deadlocks (out in a couple hours)
- Run the miner with a very high thread count, overloading the server and procs
To access the machine, use biblepay-cli:
./biblepay-cli setgenerate false
Then administer the machine, then restart the miner using cli again, etc.
This type of thread management problem is basically why most mining programs end up being external, but here - we only support full nodes with BiblePay.
|
|
|
|
is there any difference between minersleep=0 and minersleep=-1?
my wallet freezing also, but i need to have >20 threads as i have 40 cores...
No difference. When you say freezing do you mean you cant type when its mining, or it only freezes when it finds a block? Please describe in great detail what you mean. And if you use qt. |
|
|
|
linux binary also freezing, it is responding but it takes looooong time
Please ensure you have minersleep=-1 in the config also, and lower threads to 20, and see if it still is not using 100%? It was frozing but CPU load was 0-1% for biblepay I changed the conf to the following and it's not frozen addnode=explorer.biblepay.org
genproclimit=2
gen=1
minersleep=0
nickname=pagalo
CPU load still 0-1%
18:59:44

getmininginfo
18:59:44

{
"blocks": 127709,
"currentblocksize": 3515,
"currentblocktx": 3,
"difficulty": 1905.996228215673,
"errors": "",
"pooledtx": 3,
"chain": "main",
"genproclimit": 2,
"networkhashps": 173313.7089183765,
"hashps": 0,
"minerstarttime": "06-25-2019 15:50:08",
"hashcounter": 0,
"pooledtx": 3,
"chain": "main",
"biblepay-generate": true,
"poolinfo1": "",
"poolinfo2": "",
"poolinfo3": "",
"gsc_errors": "low abn weight 0",
"poolmining": false,
"pool_url": "",
"required_abn_weight": 256000
}
18:59:51

exec getabnweight 256000 1
18:59:51

{
"Command": "getabnweight",
"version": 1.1,
"weight": 49679.76461805556,
"total_required": 1299031,
"coin_age_data": "0.0374(3.13)=[0.00] depth=637, \n0.0134(3.06)=[0.00] depth=623, \n3219.1499(0.69)=[2221.59] depth=157, \n516055.0835(0.04)=[18527.81] depth=12, \n779320.3504(0.04)=[27979.75] depth=12, \n0.4628(0.69)=[0.00] depth=157, \n272.1468(2.31)=[628.00] depth=468, \n0.5212(3.07)=[0.00] depth=626, \n0.5949(102.32)=[0.00] depth=20592, \n0.5949(102.32)=[0.00] depth=20592, \n162.8233(1.99)=[322.61] depth=405, \n",
"weight 256000.00": 49679.76461805556,
"total_required 256000.00": 1299031
}
On a side note, I put in a deadlock preventer for the next release; we will get it out if we hear any more reports of a freeze after a block is solved. In the mean time though, your 0% cpu usage is because you have low abn weight. Once the ABN is spent, your miners stop running until you replenish your abn weight. |
|
|
|
linux binary also freezing, it is responding but it takes looooong time
Please ensure you have minersleep=-1 in the config also, and lower threads to 20, and see if it still is not using 100%? |
|
|
|
What do you mean sync for first time?
It has synced, it was working and CPU load OK (I had genproclimit=80 to have about 70-80% CPU load) but after block solve it froze.
Could you please try running on less threads temporarily, til we resolve all issues? I think if you are running > 20 threads, its doing a lot of work trying to create the ABNs in the background - and maybe we have discovered that we need to stop a deadlock. Please reboot, try less threads and also try this: minersleep=-1 In the config file. See if that rises your proc up to 100%? Ill work through any others issues and see if we have evidence that solving a block with multiple threads creates a deadlock condition. |
|
|
|
linux binary also freezing, it is responding but it takes looooong time
Are you syncing for the first time? I have seen this behaviour you mention in MacOS and Linux the first time it syncs, but after that, it works fine. I have seen this in QT during initial sync; Evolution seems to do much more in the background in the new block sync model. |
|
|
|
|
When we designed POG rewards, we deliberately focused on the free balance rewarding the small staker (IE the people who didn't own sanctuaries or balances of those that are not invested in sanctuaries).
I am disturbed to hear that some people are trying to unlock sanctuary funds to capture the POG stake reward and then re-lock them.
IMHO, this is unfair, because the rich are exploiting the poor in this case.
There is currently no penalty for doing this in this version (In the version in testnet we have prevented that).
Nevertheless, could someone please volunteer for the auditing position, and keep an eye on these stakes and create a weekly report of CPKs that use up Sanctuary coin-age?
I'm considering either an emergency release that prevents this behavior; or a penalty for those who do this.
Now that this information is out, please stop doing this.
|
|
|
|
|
Show Posts
