BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)

[capulo]

i just found that lscpu is not always showing real frequency. when turbo is controlled by bios itself (not os) then it is showing wrong numbers - like turbo is not working ... but turbo was on

so i recheck and here is updated list. ~2.90 means that it was not stable at this freq. but avg was somewhere there

1. Lenovo C30
Dual Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz
32 threads running @ 2.90GHz
Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-154-generic x86_64)
128GB (8x 16GB @ 1600MHz)
Total: 391.81 khash/s

2. Lenovo C30
Dual Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz
32 threads running @ 2.90GHz
Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-31-generic x86_64)
96GB (6x 16GB @ 1600MHz)
Total: 390.72 khash/s

3. Lenovo C30
Dual Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
40 threads running @ 3.10GHz
Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-164-generic x86_64)
128GB (8x 16GB @ 1600MHz)
Total: 574.62 khash/s

4. Lenovo C30
Dual Intel(R) Xeon(R) CPU E5-2650L v2 @ 1.70GHz
40 threads running @ 1.70GHz
Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-142-generic x86_64)
32GB (8x 4GB @ 1333MHz)
Total: 318.01 khash/s

5. HP DL160 G6
Dual Intel(R) Xeon(R) CPU L5520  @ 2.27GHz
16 threads running @ 2.40GHz
Ubuntu 16.04.1 LTS (GNU/Linux 4.4.0-154-generic x86_64)
8GB (2x 4GB @ 1066MHz)
Total: 161.14 khash/s

6. Intel SR1625URSAS
Dual Intel(R) Xeon(R) CPU X5650  @ 2.67GHz
24 threads running @ ~2.75GHz
Ubuntu 16.04.4 LTS (GNU/Linux 4.4.0-116-generic x86_64)
8GB (2x 4GB @ 1333MHz)
Total: 274.16 khash/s

7. IBM System x3550 M3
Dual Intel(R) Xeon(R) CPU X5660  @ 2.80GHz
24 threads running @ ~2.90GHz
Ubuntu 17.10 (GNU/Linux 4.13.0-16-generic x86_64)
8GB (2x 4GB @ 1333MHz)
Total: 288.88 khash/s

8. HP DL360e G8
Dual Intel(R) Xeon(R) CPU E5-2420 v2 @ 2.20GHz
24 threads running @ 2.50Ghz
Ubuntu 16.04.4 LTS (GNU/Linux 4.4.0-116-generic x86_64)
24GB (12x 2GB @ 1333Mhz)
Total: 281.21 khash/s

seems that memory speed or configuration (dual/quad channel...) does not have big effect

bonus:
9. laptop Thinkpad P52s
Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz
8 threads running somewhere @ 2.5-2.8GHz
Win10 Enterprise
16GB (2x 8GB @ 2400MHz)
Total: 133.21 khash/s

[sunk818]

- POOM could be reduced in total size to reestablish/cap our *governance charity* emissions at 10%
...
- The increase in sanc payout coming soon is OK - because they lock the coins and hold them usually

POOM: I wrote about the sustainability of POOM: https://whitewalr.us/2019/biblepay-poom-sustainable.html - I'll have to revisit this if the percentages change.

Sanc payout: With the rise in difficulty, sanc reward dips below 1000 BBP. You mentioned turning off Quantitative Tightening (QT). Can you expound on what  the impact of QT off, external miner release, changing sanc payout percentage will do overall to profitability for sanctuary holders?  This means subsidy (miner) and sanctuary_reward values will diverge in the future?

On the potential proposed changes, let me see if I can generate the data (for the forum thread) and attempt to create the thread before the weekend is over, and Ill include the above in that post.

Right now, I finally was able to get NOMP running in my dev environment with the external miner hashing against it, and there are some issues with ABN, so Im trying to address these today, then I can clear out some normal time to focus on that asap.

Did this block miss a sanctuary payment?

height   subsidy
145076   2752

I noticed the subsidy values and sanctuary_reward in raw block don't match up. are these rewards (for miner & sanctuary) forfeited and the daily superblock takes priority? Or do the rewards get rolled into the daily superblock reward amount?

145160   2764
145365   2738
...
151720   2063
151925   2114

[sunk818]

#3 is v2 xeon, #1-2 is v1 thats all magic
and also it has 40 threads, 1-2 have 32 threads

You can change governance on CPU to high performance if you don't mind the extra heat and electricity use.
https://askubuntu.com/questions/604720/setting-to-high-performance

[bible_pay]

- POOM could be reduced in total size to reestablish/cap our *governance charity* emissions at 10%
...
- The increase in sanc payout coming soon is OK - because they lock the coins and hold them usually

POOM: I wrote about the sustainability of POOM: https://whitewalr.us/2019/biblepay-poom-sustainable.html - I'll have to revisit this if the percentages change.

Sanc payout: With the rise in difficulty, sanc reward dips below 1000 BBP. You mentioned turning off Quantitative Tightening (QT). Can you expound on what  the impact of QT off, external miner release, changing sanc payout percentage will do overall to profitability for sanctuary holders?  This means subsidy (miner) and sanctuary_reward values will diverge in the future?

On the potential proposed changes, let me see if I can generate the data (for the forum thread) and attempt to create the thread before the weekend is over, and Ill include the above in that post.

Right now, I finally was able to get NOMP running in my dev environment with the external miner hashing against it, and there are some issues with ABN, so Im trying to address these today, then I can clear out some normal time to focus on that asap.

Did this block miss a sanctuary payment?

height   subsidy
145076   2752

I noticed the subsidy values and sanctuary_reward in raw block don't match up. are these rewards (for miner & sanctuary) forfeited and the daily superblock takes priority? Or do the rewards get rolled into the daily superblock reward amount?

145160   2764
145365   2738
...
151720   2063
151925   2114

Since the beginning, Dash does not pay the sanctuary during the monthly superblock budget.

Only the heat miner gets paid.

No, the sanc payment does not get added to the governance budget  - the gov budget cap is accurate.

(I.E. This is the way it is in the dash community also).

[sunk818]

I wrote a new post on why mining rewards change:

Why does BiblePay’s mining reward amount change?

[capulo]

is external miner also power saving when abn is low?
i'm not sure, because everytime i checked miner, it goes at full speed
it drops to 0 only when it crashed

Yes, it stops mining when ABN is out; and - it doesn't crash anymore.

is this idle?

Erroring out
[2019-10-17 08:55:57] json_rpc_call failed, retry after 30 seconds
[2019-10-17 08:56:27] BBP Core Mining Error:  Wallet Locked/ABN Required

it seems so, but miner is still consuming two cores... sometimes 3 cores
11263 capo      20   0 3125160  17060   9344 S 200.0  0.0  21825:34 bbpminer_linux

Yes - thats idle on that particular thread.  And of course, erroring out is not a crash (We can take that message out).

Each thread takes a certain amount of seconds to quit hashing the current best block if its still a valid block to hash and has not asked for new work.

Has your processor utilization gone to zero after waiting for a block to pass while you have an invalid ABN?  

Yes, you can set gen=0 now, as long as you don't need to send GSCs out.

i know this is not crash, when it was crash there was some libraries dump or what, not remember. but it does not happens again..

and it does not goes to zero, it using 1-3 cores at 100% so 100 or 200 or 300% when abn is low

Oh, I wasn't aware of that. 
Do me a favor, since Im working on some other things, please type 'getmininginfo' and when you see your ABN is out for sure, and the miner is still running more than 5 mins after the abn is out, type 'getblockforstratum' into the console of biblepay and tell me if it shows an Error: ABN weight low (or not).

This will point me in the right direction if its the biblepay client or the miner.

i started more wallets and more bbp miners to see better behaviour and after day i stopped completely all wallets and some miners goes to 0%, some stayed on 50% or 100% or 200%... etc, but max i see 300% (3 cores). same as i had when abn was low

all miners just saying: [2019-10-19 23:51:45] HTTP request failed: Failed to connect to 192.168.0.50 port 39003: Connection refused
[2019-10-19 23:51:45] json_rpc_call failed, retry after 30 seconds

i dont have idea what they are doing...

anyone else experiencing same behaviour?


ps: is it possible somehow allow whole subnet? like rpcallowip=192.168.0.*

[MIP]

Android mobile app update (1.4.5.0)

Bug fixes:
- bug in showing send-to or receive-from addresses
- bug when switching from manual node to automatic mode (keeps manual mode until app restart).
- amount overflow bug when sweeping paper key

[bible_pay]

is external miner also power saving when abn is low?
i'm not sure, because everytime i checked miner, it goes at full speed
it drops to 0 only when it crashed

Yes, it stops mining when ABN is out; and - it doesn't crash anymore.

is this idle?

Erroring out
[2019-10-17 08:55:57] json_rpc_call failed, retry after 30 seconds
[2019-10-17 08:56:27] BBP Core Mining Error:  Wallet Locked/ABN Required

it seems so, but miner is still consuming two cores... sometimes 3 cores
11263 capo      20   0 3125160  17060   9344 S 200.0  0.0  21825:34 bbpminer_linux

Yes - thats idle on that particular thread.  And of course, erroring out is not a crash (We can take that message out).

Each thread takes a certain amount of seconds to quit hashing the current best block if its still a valid block to hash and has not asked for new work.

Has your processor utilization gone to zero after waiting for a block to pass while you have an invalid ABN?  

Yes, you can set gen=0 now, as long as you don't need to send GSCs out.

i know this is not crash, when it was crash there was some libraries dump or what, not remember. but it does not happens again..

and it does not goes to zero, it using 1-3 cores at 100% so 100 or 200 or 300% when abn is low

Oh, I wasn't aware of that. 
Do me a favor, since Im working on some other things, please type 'getmininginfo' and when you see your ABN is out for sure, and the miner is still running more than 5 mins after the abn is out, type 'getblockforstratum' into the console of biblepay and tell me if it shows an Error: ABN weight low (or not).

This will point me in the right direction if its the biblepay client or the miner.

i started more wallets and more bbp miners to see better behaviour and after day i stopped completely all wallets and some miners goes to 0%, some stayed on 50% or 100% or 200%... etc, but max i see 300% (3 cores). same as i had when abn was low

all miners just saying: [2019-10-19 23:51:45] HTTP request failed: Failed to connect to 192.168.0.50 port 39003: Connection refused
[2019-10-19 23:51:45] json_rpc_call failed, retry after 30 seconds

i dont have idea what they are doing...

anyone else experiencing same behaviour?


ps: is it possible somehow allow whole subnet? like rpcallowip=192.168.0.*

"
ps: is it possible somehow allow whole subnet? like rpcallowip=192.168.0.*"

->  They used to allow wildcards.  It looks like bitcoin upgraded the code to require subnet-mask notation.  Try this: rpcallowip=192.168.0.0/24

As far as the latent mining after a pause, I did notice an issue yesterday while testing the pool.  I added a sleep in there (only when its not hashing) and this might fix it.
It should be checked in within a couple days; give me a chance to check in the pool first and ill make a post on that.

[bible_pay]

** SANCTUARIES **
(and community members):

Please read the new proposals:
DSS proposed changes:
https://forum.biblepay.org/index.php?topic=461.msg6381#msg6381

Coinsbit Exchange proposal:
https://forum.biblepay.org/index.php?topic=460.new#new

[talkshi]

I think charity and crypto is bad to mix together. Using crypto to give is ok but making it an actual project your just trashing btc. Please show us proof of these orphans you are helping thanks.

[sunk818]

I think charity and crypto is bad to mix together. Using crypto to give is ok but making it an actual project your just trashing btc. Please show us proof of these orphans you are helping thanks.

Are you reaching a foolish conclusion before you researched even a little bit and have the facts?

Over $200k USD has been donated to charity thus far.

pool.biblepay.org under accountability (registration required)

[sunk818]

Rob, also external miner is showing ABN low but getmininginfo and exec getabnweight 125000 1 says there is enough

https://imgur.com/a/77GKYac

[capulo]

Rob, also external miner is showing ABN low but getmininginfo and exec getabnweight 125000 1 says there is enough

https://imgur.com/a/77GKYac

rpc call failed, seems you have some conectivity issue from miner to wallet

[Nipar]

Rob, also external miner is showing ABN low but getmininginfo and exec getabnweight 125000 1 says there is enough

https://imgur.com/a/77GKYac

rpc call failed, seems you have some conectivity issue from miner to wallet

You will also get that issue if the wallet is locked. If unlocked and ABN weight is enough it will resolve itself.

[sunk818]

Rob, also external miner is showing ABN low but getmininginfo and exec getabnweight 125000 1 says there is enough

https://imgur.com/a/77GKYac

rpc call failed, seems you have some conectivity issue from miner to wallet

wallet and miner same computer. maybe I'll reboot. wallet is unlocked and enough abn. mining internally works okay as I tested

[bible_pay]

The book of Micah provides one of the most significant prophecies of Jesus Christ’s birth in all the Old Testament, pointing some seven hundred years before Christ’s birth to His birthplace of Bethlehem and to His eternal nature (Micah 5:2).

Proverbs (30:4):
     Who has ascended to heaven and come down? Who has gathered the wind in His hands? Who has bound up the waters in His cloak? Who has established all the ends of the earth? What is His name, and what is the name of His Son— surely you know!


Many examples in the Old Testament show clear evidence that Jesus is the Messiah, and existed with God, before he was born in the flesh.

[capulo]

hmm few minutes ago, all miners on all wallets on all PCs crashed... also on wallet copies... so it must have something to do with data from wallets

few logs from misc pcs:
[2042803.452824] traps: bbpminer_linux[7947] trap stack segment ip:7fa3781c245b sp:7fa378142ad0 error:0 in libc-2.23.so[7fa378144000+1c0000]
[159775.469343] traps: bbpminer_linux[1710] trap stack segment ip:7f9a2aee345b sp:7f9a2ae63ad0 error:0 in libc-2.23.so[7f9a2ae65000+1c0000]
[159780.299285] traps: bbpminer_linux[1801] trap stack segment ip:7ff438eea45b sp:7ff438e696e0 error:0 in libc-2.23.so[7ff438e6c000+1c0000]
[159792.120281] traps: bbpminer_linux[1711] general protection ip:7f0b6c6ab512 sp:7f0b6c625bd0 error:0 in libc-2.23.so[7f0b6c627000+1c0000]

Bus error               (core dumped) ./bbpminer_linux ...
Segmentation fault      (core dumped) ./bbpminer_linux ...
Bus error               (core dumped) ./bbpminer_linux ...

[1613129.400148] biblepay-miner[8442]: segfault at 50370 ip 00007f9639a72d44 sp 00007f9509efacd0 error 4 in libpthread-2.23.so[7f9639a69000+18000]
[2042899.987031] traps: bbpminer_linux[17172] general protection ip:7fccc235b512 sp:7fccc22d5bd0 error:0 in libc-2.23.so[7fccc22d7000+1c0000]
...
btw wallets are still running and all have ok abn

edit: i cant start miners, they crash immediately...
getblockforstratum showing some long hex and no error

mining info showing on two wallets:
  "abninfo": "ABN: OK; ",
  "gsc_errors": "low abn weight 124936",

  "abninfo": "ABN: OK; ",
  "gsc_errors": "low abn weight 0",

but abn is ok
  "weight": 560430.9543402777,
and
  "weight": 1419968.982430556,

edit2: now i can start miners again, maybe chain moved to another block or what... maybe there was some weird block around 152537

[togoshigekata]

My windows wallet v1.4.5.0 has crashed twice the past 2-3 days,
just checked log and nothing popped out to me,
Ill add debug=1 this time and report back if it happens again
Config file only has disablegsctransmission=1

[eternalenvoy]

hmm few minutes ago, all miners on all wallets on all PCs crashed... also on wallet copies... so it must have something to do with data from wallets

few logs from misc pcs:
[2042803.452824] traps: bbpminer_linux[7947] trap stack segment ip:7fa3781c245b sp:7fa378142ad0 error:0 in libc-2.23.so[7fa378144000+1c0000]
[159775.469343] traps: bbpminer_linux[1710] trap stack segment ip:7f9a2aee345b sp:7f9a2ae63ad0 error:0 in libc-2.23.so[7f9a2ae65000+1c0000]
[159780.299285] traps: bbpminer_linux[1801] trap stack segment ip:7ff438eea45b sp:7ff438e696e0 error:0 in libc-2.23.so[7ff438e6c000+1c0000]
[159792.120281] traps: bbpminer_linux[1711] general protection ip:7f0b6c6ab512 sp:7f0b6c625bd0 error:0 in libc-2.23.so[7f0b6c627000+1c0000]

Bus error               (core dumped) ./bbpminer_linux ...
Segmentation fault      (core dumped) ./bbpminer_linux ...
Bus error               (core dumped) ./bbpminer_linux ...

[1613129.400148] biblepay-miner[8442]: segfault at 50370 ip 00007f9639a72d44 sp 00007f9509efacd0 error 4 in libpthread-2.23.so[7f9639a69000+18000]
[2042899.987031] traps: bbpminer_linux[17172] general protection ip:7fccc235b512 sp:7fccc22d5bd0 error:0 in libc-2.23.so[7fccc22d7000+1c0000]
...
btw wallets are still running and all have ok abn

edit: i cant start miners, they crash immediately...
getblockforstratum showing some long hex and no error

mining info showing on two wallets:
  "abninfo": "ABN: OK; ",
  "gsc_errors": "low abn weight 124936",

  "abninfo": "ABN: OK; ",
  "gsc_errors": "low abn weight 0",

but abn is ok
  "weight": 560430.9543402777,
and
  "weight": 1419968.982430556,

edit2: now i can start miners again, maybe chain moved to another block or what... maybe there was some weird block around 152537

same case...
look like is the "gsc_errors" problem ? Even disable GSC transaction in biblepay.conf still have problem

[capulo]

added khash/W and khash/GHz
all x5650 line and v1 xeons have same khash/ghz = about 4.2
all v2 xeons same about 4.65
does not matter if it is 24xx or 26xx line

so you can easily compute hashrate for any cpu . best v2 xeon e5 2697v2 will have ~670khash/s and 2.57 khash/W
v1(or x5650) vs v2 xeons is only 10% difference, so if you have cheap or free electricity, you can save money and buy g6/g7 servers, they are really cheap, dual x5650 machine for ~100$


1. Lenovo C30
Dual Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz
2x 135W
32 threads @ 2.90GHz
Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-154-generic x86_64)
128GB (8x 16GB @ 1600MHz)
Total: 391.81 khash/s
khash/W = 1.45
khash/GHz = 4.22

2. Lenovo C30
Dual Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz
2x 135W
32 threads @ 2.90GHz
Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-31-generic x86_64)
96GB (6x 16GB @ 1600MHz)
Total: 390.72 khash/s
khash/W = 1.45
khash/GHz = 4.21

3. Lenovo C30
Dual Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
2x 115W
40 threads @ 3.10GHz
Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-164-generic x86_64)
128GB (8x 16GB @ 1600MHz)
Total: 574.62 khash/s
khash/W = 2.50
khash/GHz = 4.63

4. Lenovo C30
Dual Intel(R) Xeon(R) CPU E5-2650L v2 @ 1.70GHz
2x 70W
40 threads @ 1.90GHz
Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-142-generic x86_64)
32GB (8x 4GB @ 1333MHz)
Total: 355.55 khash/s
khash/W = 2.54
khash/GHz = 4.68

5. HP DL160 G6
Dual Intel(R) Xeon(R) CPU L5520  @ 2.27GHz
2x 60W
16 threads @ 2.40GHz
Ubuntu 16.04.1 LTS (GNU/Linux 4.4.0-154-generic x86_64)
8GB (2x 4GB @ 1066MHz)
Total: 161.14 khash/s
khash/W = 1.34
khash/GHz = 4.20

6. Intel SR1625URSAS
Dual Intel(R) Xeon(R) CPU X5650  @ 2.67GHz
2x 95W
24 threads @ ~2.75GHz
Ubuntu 16.04.4 LTS (GNU/Linux 4.4.0-116-generic x86_64)
8GB (2x 4GB @ 1333MHz)
Total: 274.16 khash/s
khash/W = 1.44
khash/GHz = 4.15

7. IBM System x3550 M3
Dual Intel(R) Xeon(R) CPU X5660  @ 2.80GHz
2x 95W
24 threads @ ~2.90GHz
Ubuntu 17.10 (GNU/Linux 4.13.0-16-generic x86_64)
8GB (2x 4GB @ 1333MHz)
Total: 288.88 khash/s
khash/W = 1.52
khash/GHz = 4.15

8. HP DL360e G8
Dual Intel(R) Xeon(R) CPU E5-2420 v2 @ 2.20GHz
2x 80W
running @ 2.50Ghz
Ubuntu 16.04.4 LTS (GNU/Linux 4.4.0-116-generic x86_64)
24GB (12x 2GB @ 1333Mhz)
Total: 281.21 khash/s
khash/W = 1.76
khash/GHz = 4.69

9. laptop Thinkpad P52s
Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz
15W
8 threads somewhere @ 2.5-2.8GHz
Win10 Enterprise
16GB (2x 8GB @ 2400MHz)
Total: 133.21 khash/s
khash/W = 8.88
khash/GHz = ~6.28

10. HP DL360e G8
Dual Intel(R) Xeon(R) CPU E5-2450L 0 @ 1.80GHz
2x 70W
32 threads running @ 2.00GHz
Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-142-generic x86_64)
32GB (8x 4GB @ 1333MHz)
Total: 267.78 khash/s
khash/W = 1.91
khash/GHz = 4.18

11. HP DL380p G8
Dual Intel(R) Xeon(R) CPU E5-2650L v2 @ 1.70GHz
2x 70W
40 threads running @ 1.90GHz
Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-142-generic x86_64)
48GB (12x 4GB @ 1333MHz)
Total: 353.54 khash/s
khash/W = 2.53
khash/GHz = 4.65

12. Dell T3600
Intel(R) Xeon(R) CPU E5-1620 0 @ 3.60GHz
130W
8 threads running @ 3.67GHz
Win10 Pro
16GB (4x 4GB @ 1333MHz)
Total: 120.24 khash/s
khash/W = 0.92
khash/GHz = 4.09

more machines coming soon...
also i will do test linux vs win on same machine