From Vultr staff regarding CPU utilization abuse:
Hello,
If you're setting maximum usage to 60% per core, you shouldn't encounter any issues -- when we check for abusive CPU usage, we're generally looking for CPU usage that's pegged at maximum (100% on a single-core instance, or some multiple of 100% for multi-core instances). You can use the 'uptime' tool to see system load averages -- this is the same kind of data that we get on the hypervisor side when monitoring VPS resource utilization.
If you have any further questions, please let us know!
Lloyd W. Slade
System Administrator
Topic: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes) - page 617. (Read 243376 times)
March 06, 2018, 02:10:13 PM
March 06, 2018, 02:08:04 PM
Guys my hashrate fell like 80-90%. Is this supposed to happen? Am I gonna get that much less BBP's or is it gonna sort itself out somehow? 
After block 33400, with PODC it is better to just lower your hashrate and increase your Rosetta cancer intensity.
But between now and 33400, you can go ahead and increase your genproclimit as high as you want - if you want to expend more for POW.
The reason for the difference is we have a 250ms sleep in the new miner by default, its easier to just increase your genproclimit than to disable it. Or you can set the 'minersleep=0' parameter if you wish.
March 06, 2018, 02:00:10 PM
Guys my hashrate fell like 80-90%. Is this supposed to happen? Am I gonna get that much less BBP's or is it gonna sort itself out somehow?
Yes this is normal with new version.We haven't reached the cut-off block for PODC yet, so rewards are still the same, but there is some unexpected behavior going on with our blockchain, so everyone: please prepare to upgrade your wallets soon.
March 06, 2018, 01:46:06 PM
Hello everyone,
it seems I'm having trouble with my CPID association in prod. I tried PODC in testnet couple of weeks ago and it worked perfectly. Yesterday I associated my CPID to my main wallet, the transaction was completed and the wallet said "successful".
However it doesn't seem to have worked. My exec getboincinfo still looks like this:
I tried to just associate again, but the wallet just returns "Unable to sign CPID 7c9264559fef3c1c689ee9fc3ff42494". Usually it should take about 6 blocks only to let the CPID show up, correct? Could it be I associated it on a fork, since yesterday I think I still used 1.0.9.x?
it seems I'm having trouble with my CPID association in prod. I tried PODC in testnet couple of weeks ago and it worked perfectly. Yesterday I associated my CPID to my main wallet, the transaction was completed and the wallet said "successful".
However it doesn't seem to have worked. My exec getboincinfo still looks like this:
I tried to just associate again, but the wallet just returns "Unable to sign CPID 7c9264559fef3c1c689ee9fc3ff42494". Usually it should take about 6 blocks only to let the CPID show up, correct? Could it be I associated it on a fork, since yesterday I think I still used 1.0.9.x?
Just wait those 6 blocks. If it was successful than it might be OK.
March 06, 2018, 01:40:25 PM
Hello everyone,
it seems I'm having trouble with my CPID association in prod. I tried PODC in testnet couple of weeks ago and it worked perfectly. Yesterday I associated my CPID to my main wallet, the transaction was completed and the wallet said "successful".
However it doesn't seem to have worked. My exec getboincinfo still looks like this:
I tried to just associate again, but the wallet just returns "Unable to sign CPID 7c9264559fef3c1c689ee9fc3ff42494". Usually it should take about 6 blocks only to let the CPID show up, correct? Could it be I associated it on a fork, since yesterday I think I still used 1.0.9.x?
it seems I'm having trouble with my CPID association in prod. I tried PODC in testnet couple of weeks ago and it worked perfectly. Yesterday I associated my CPID to my main wallet, the transaction was completed and the wallet said "successful".
However it doesn't seem to have worked. My exec getboincinfo still looks like this:
Code:
{
"Command": "getboincinfo",
"CPID": "",
"Address": "",
"CPIDS": "",
"CPID-Age (hours)": 422322,
"NextSuperblockHeight": 33620,
"NextSuperblockBudget": 760165,
"Total Payments (One Day)": 0,
"Total Payments (One Week)": 0,
"Total Budget (One Day)": 0,
"Total Budget (One Week)": 0,
"Superblock Count (One Week)": 0,
"Superblock Hit Count (One Week)": 0,
"Superblock List": "",
"Last Superblock Height": 0,
"Last Superblock Budget": 0,
"Last Superblock Payment": -2,
"Magnitude (One-Day)": 0,
"Magnitude (One-Week)": 0
}
"Command": "getboincinfo",
"CPID": "",
"Address": "",
"CPIDS": "",
"CPID-Age (hours)": 422322,
"NextSuperblockHeight": 33620,
"NextSuperblockBudget": 760165,
"Total Payments (One Day)": 0,
"Total Payments (One Week)": 0,
"Total Budget (One Day)": 0,
"Total Budget (One Week)": 0,
"Superblock Count (One Week)": 0,
"Superblock Hit Count (One Week)": 0,
"Superblock List": "",
"Last Superblock Height": 0,
"Last Superblock Budget": 0,
"Last Superblock Payment": -2,
"Magnitude (One-Day)": 0,
"Magnitude (One-Week)": 0
}
I tried to just associate again, but the wallet just returns "Unable to sign CPID 7c9264559fef3c1c689ee9fc3ff42494". Usually it should take about 6 blocks only to let the CPID show up, correct? Could it be I associated it on a fork, since yesterday I think I still used 1.0.9.x?
March 06, 2018, 01:36:51 PM
Guys my hashrate fell like 80-90%. Is this supposed to happen? Am I gonna get that much less BBP's or is it gonna sort itself out somehow?
Yes this is normal with new version. March 06, 2018, 12:53:47 PM
Guys my hashrate fell like 80-90%. Is this supposed to happen? Am I gonna get that much less BBP's or is it gonna sort itself out somehow?
March 06, 2018, 12:44:27 PM
Launchpad is building Ubuntu packages for 1.1.0.2c right now
March 06, 2018, 11:57:18 AM
Mhh, there still is a difference between the 1.1.0.1+ chain and the older clients.
My 1.0.8.6 system shows a height of 33275, the explorer does the same. But the main pool, purepool and my 1.1.0.1 client show 33272 as height
I just saw it in my logs, I get a lot of invalid heights (invalid from the point of view of the purepool), as 33275 is highter then the allowed 33272 (height of the purepool)
Maybe not all is fine. But with the new release near, we will survive it
My 1.0.8.6 system shows a height of 33275, the explorer does the same. But the main pool, purepool and my 1.1.0.1 client show 33272 as height
I just saw it in my logs, I get a lot of invalid heights (invalid from the point of view of the purepool), as 33275 is highter then the allowed 33272 (height of the purepool)
Maybe not all is fine. But with the new release near, we will survive it
Thats normal, the 1101+ is not accepting the 1086 blocks right away, but after it has no choice then it pulls it in.
March 06, 2018, 11:24:58 AM
Mhh, there still is a difference between the 1.1.0.1+ chain and the older clients.
My 1.0.8.6 system shows a height of 33275, the explorer does the same. But the main pool, purepool and my 1.1.0.1 client show 33272 as height
I just saw it in my logs, I get a lot of invalid heights (invalid from the point of view of the purepool), as 33275 is highter then the allowed 33272 (height of the purepool)
Maybe not all is fine. But with the new release near, we will survive it
My 1.0.8.6 system shows a height of 33275, the explorer does the same. But the main pool, purepool and my 1.1.0.1 client show 33272 as height
I just saw it in my logs, I get a lot of invalid heights (invalid from the point of view of the purepool), as 33275 is highter then the allowed 33272 (height of the purepool)
Maybe not all is fine. But with the new release near, we will survive it
March 06, 2018, 11:22:20 AM
One little surprise tidbit of info we have coming in the future- since Biblepays future relies on a lot of cancer transactions, due to the new
PODC integrity feature (where an unspent coin is tied to a cancer task) we will most likely raise the average transaction fee from milliBBP to centBBP or maybe even BBP in some cases. This means even though mining revenue is dropping by 90%, there will be a lot more fees collected by miners per block in a few months (after we have about 2500 CPIDs cancer researching constantly).
Meaning that I expect a block to be 600 in payment for the heat side, plus 100 or so BBP in fees. So we will not have complete famine for the heat miners.
PODC integrity feature (where an unspent coin is tied to a cancer task) we will most likely raise the average transaction fee from milliBBP to centBBP or maybe even BBP in some cases. This means even though mining revenue is dropping by 90%, there will be a lot more fees collected by miners per block in a few months (after we have about 2500 CPIDs cancer researching constantly).
Meaning that I expect a block to be 600 in payment for the heat side, plus 100 or so BBP in fees. So we will not have complete famine for the heat miners.
March 06, 2018, 11:19:41 AM
Sorry about that, we had the best intentions.
Better do hard changes now then later, the coin is still small enough.
And big changes are sometimes raw at the start.
Nobody will remember such problems in a month when everything is working good again
March 06, 2018, 11:17:59 AM
The chain seems to be joined again, right? ^^
1.1.0.1 System from the post above:
biblepay-cli getblockhash 33268
80447526670309ff730eb64c81e8c1ef4a67a2f7a173aa351fba338eee5ce4eb
Same system now (nothing changes, simply executed the command again)
biblepay-cli getblockhash 33268
550699009b14fe33f79be164dbba0ac063e4423d7a0fa75f119738704c7388d1
The main pool is also on the same height again
1.1.0.1 System from the post above:
biblepay-cli getblockhash 33268
80447526670309ff730eb64c81e8c1ef4a67a2f7a173aa351fba338eee5ce4eb
Same system now (nothing changes, simply executed the command again)
biblepay-cli getblockhash 33268
550699009b14fe33f79be164dbba0ac063e4423d7a0fa75f119738704c7388d1
The main pool is also on the same height again
Its very possible this happened, because we usually have at least one "hobbyist" out there who lowers the protocol version to try to get their solutions on the new chain. The hard fork does not occur til 33400. The code is programmed to reorganize to the chain with the most work.
So we probably bucked all the CPIDs off the new chain (1101), and they probably need to re-associate those cpids all over again.
Oh well, thats the life of a cancer researcher
.After 33400 however yes we need to expect full reliability and trace all missing transactions and pay them.
March 06, 2018, 11:15:44 AM
Its not really quite bad, since the exchanges are down, all coins sent on either version will either be orphaned or live on the 1101+ chain.
Its to be expected, because starting on 1101, we require the higher protocol version in order to communicate.
The fork is not a hard fork (related to block cutover) its just network segmentation.
So Im not quite ready to say its time for a mandatory because were not actually done testing. We'll hurry.
Its to be expected, because starting on 1101, we require the higher protocol version in order to communicate.
The fork is not a hard fork (related to block cutover) its just network segmentation.
So Im not quite ready to say its time for a mandatory because were not actually done testing. We'll hurry.
Then I will update the purepool to the current version now, too.
Sorry about that, we had the best intentions.
March 06, 2018, 11:14:47 AM
The chain seems to be joined again, right? ^^
1.1.0.1 System from the post above:
biblepay-cli getblockhash 33268
80447526670309ff730eb64c81e8c1ef4a67a2f7a173aa351fba338eee5ce4eb
Same system now (nothing changes, simply executed the command again)
biblepay-cli getblockhash 33268
550699009b14fe33f79be164dbba0ac063e4423d7a0fa75f119738704c7388d1
The main pool is also on the same height again
1.1.0.1 System from the post above:
biblepay-cli getblockhash 33268
80447526670309ff730eb64c81e8c1ef4a67a2f7a173aa351fba338eee5ce4eb
Same system now (nothing changes, simply executed the command again)
biblepay-cli getblockhash 33268
550699009b14fe33f79be164dbba0ac063e4423d7a0fa75f119738704c7388d1
The main pool is also on the same height again
March 06, 2018, 11:01:54 AM
Its not really quite bad, since the exchanges are down, all coins sent on either version will either be orphaned or live on the 1101+ chain.
Its to be expected, because starting on 1101, we require the higher protocol version in order to communicate.
The fork is not a hard fork (related to block cutover) its just network segmentation.
So Im not quite ready to say its time for a mandatory because were not actually done testing. We'll hurry.
Its to be expected, because starting on 1101, we require the higher protocol version in order to communicate.
The fork is not a hard fork (related to block cutover) its just network segmentation.
So Im not quite ready to say its time for a mandatory because were not actually done testing. We'll hurry.
Then I will update the purepool to the current version now, too.
March 06, 2018, 10:54:55 AM
Anyone who is having trouble mining: please upgrade to 1.1.0.1+.
It appears we have a fork, and the pool is running the newest version, so we need to have the miners mine on the same chain as the pool is on.
It appears we have a fork, and the pool is running the newest version, so we need to have the miners mine on the same chain as the pool is on.
Isn't that quite bad?
1.1.0.1 shows:
biblepay-cli getblockhash 33268
80447526670309ff730eb64c81e8c1ef4a67a2f7a173aa351fba338eee5ce4eb
1.0.8.6 shows:
biblepay-cli getblockhash 33268
550699009b14fe33f79be164dbba0ac063e4423d7a0fa75f119738704c7388d1
All my servers with < 1.1.01 agree on "550699009b14fe33..." for block 33268, as do both explorers:
https://biblepay-explorer.org/block/33268
http://explorer.biblepay.org:3001/block/550699009b14fe33f79be164dbba0ac063e4423d7a0fa75f119738704c7388d1
Edit: The second link doesn't work anymore. mhh
Does that mean hat 1.1.0.1+ is now definitly mandatory for all others?
Its not really quite bad, since the exchanges are down, all coins sent on either version will either be orphaned or live on the 1101+ chain.
Its to be expected, because starting on 1101, we require the higher protocol version in order to communicate.
The fork is not a hard fork (related to block cutover) its just network segmentation.
As far as doing this early and forcing an upgrade, were trying to ensure this latest client is the RC. We had to start having some sancs upgrade in order to finish testing.
So Im not quite ready to say its time for a mandatory because were not actually done testing. We'll hurry.
March 06, 2018, 10:46:23 AM
Anyone who is having trouble mining: please upgrade to 1.1.0.1+.
It appears we have a fork, and the pool is running the newest version, so we need to have the miners mine on the same chain as the pool is on.
It appears we have a fork, and the pool is running the newest version, so we need to have the miners mine on the same chain as the pool is on.
Isn't that quite bad?
1.1.0.1 shows:
biblepay-cli getblockhash 33268
80447526670309ff730eb64c81e8c1ef4a67a2f7a173aa351fba338eee5ce4eb
1.0.8.6 shows:
biblepay-cli getblockhash 33268
550699009b14fe33f79be164dbba0ac063e4423d7a0fa75f119738704c7388d1
All my servers with < 1.1.01 agree on "550699009b14fe33..." for block 33268, as do both explorers:
https://biblepay-explorer.org/block/33268
http://explorer.biblepay.org:3001/block/550699009b14fe33f79be164dbba0ac063e4423d7a0fa75f119738704c7388d1
Edit: The second link doesn't work anymore. mhh
Does that mean hat 1.1.0.1+ is now definitly mandatory for all others?
March 06, 2018, 10:38:37 AM
Rob, please help! I made a withdraw from the pool to my wallet yesterday as usual, but until now nothing has appeared in the wallet (ver. 1.0.8.6)!
The amount of money on the pool has decreased. The info from transaction history:
withdrawal BCD2eNowB8Hw9WNFYACD3U3diGzP9tfniR 4950.0000 105.4955 3/5/2018 5:26:45 PM 33162
There is also no entry for this transfer in the blockchain explorer !!! Where could the transfer be lost?
Thx, Hardijs
The amount of money on the pool has decreased. The info from transaction history:
withdrawal BCD2eNowB8Hw9WNFYACD3U3diGzP9tfniR 4950.0000 105.4955 3/5/2018 5:26:45 PM 33162
There is also no entry for this transfer in the blockchain explorer !!! Where could the transfer be lost?
Thx, Hardijs
Pool wallet is on 1.1.0.2, please upgrade to 1.1.0.2 and let me know if you see the balance?
March 06, 2018, 10:37:38 AM
Anyone who is having trouble mining: please upgrade to 1.1.0.1+.
It appears we have a fork, and the pool is running the newest version, so we need to have the miners mine on the same chain as the pool is on.
It appears we have a fork, and the pool is running the newest version, so we need to have the miners mine on the same chain as the pool is on.
Jump to: