Bible Pay

Read 45568 times

  • oncoapop
  • Full Member

    • 171


    • 17
    • October 23, 2018, 12:31:17 PM
    more
Re: BIBLEPAY - RANDOMX INTEGRATION
« Reply #45 on: February 15, 2020, 10:21:52 PM »
XMR miner on same hardware:
Code: [Select]
Model name:          Intel(R) Xeon(R) CPU E5-2650L v3 @ 1.80GHz
Stepping:            2
CPU MHz:             1797.916
BogoMIPS:            3595.83
Virtualization:      VT-x
Hypervisor vendor:   KVM
Virtualization type: full
L1d cache:           32K
L1i cache:           32K
L2 cache:            256K
L3 cache:            30720K
NUMA node0 CPU(s):   0-5
- Compile xmrig for XMR only
Validation of hash rate from pool:
Code: [Select]
2.35 KH/s 0.00 H/s 374925243 114492 0 about a minute ago paladin
Xmrig console output:
Code: [Select]
[2020-02-15 05:48:32.798]  net  new job from us-west.minexmr.com:443 diff 117786 algo rx/0 height 2034184
[2020-02-15 05:49:05.115] speed 10s/60s/15m 2077.5 2063.7 2011.9 H/s max 2164.9 H/s
[2020-02-15 05:49:28.820]  cpu  accepted (3383/0) diff 117786 (72 ms)
[2020-02-15 05:49:32.828]  net  new job from us-west.minexmr.com:443 diff 117750 algo rx/0 height 2034185
[2020-02-15 05:50:05.168] speed 10s/60s/15m 2065.7 2054.3 2012.8 H/s max 2164.9 H/s
[2020-02-15 05:50:05.777]  net  new job from us-west.minexmr.com:443 diff 117770 algo rx/0 height 2034186
[2020-02-15 05:51:05.220] speed 10s/60s/15m 2092.0 2082.8 2018.5 H/s max 2164.9 H/s
[2020-02-15 05:51:57.700]  cpu  accepted (3384/0) diff 117770 (72 ms)
[2020-02-15 05:52:05.275] speed 10s/60s/15m 2033.7 2085.6 2025.9 H/s max 2164.9 H/s
[2020-02-15 05:52:46.657]  cpu  accepted (3385/0) diff 117770 (72 ms)
[2020-02-15 05:53:05.333] speed 10s/60s/15m 2090.6 2094.7 2033.8 H/s max 2164.9 H/s
[2020-02-15 05:53:43.143]  net  new job from us-west.minexmr.com:443 diff 117692 algo rx/0 height 2034187
[2020-02-15 05:54:05.390] speed 10s/60s/15m 2111.2 2103.9 2039.1 H/s max 2164.9 H/s
[2020-02-15 05:54:14.771]  cpu  accepted (3386/0) diff 117692 (72 ms)

Compile BBP version
>cli -version
BiblePay Core RPC client version 1.5.0.2

Compile xmrig (BBP+XMR)

Code: [Select]
* ABOUT        XMRig/5.5.6 gcc/7.4.0
 * BBP + XMR - Welcome to the future of orphan charity
 * LIBS         libuv/1.18.0 OpenSSL/1.1.1 hwloc/1.11.9
 * HUGE PAGES   supported
 * 1GB PAGES    disabled
 * CPU          Intel(R) Xeon(R) CPU E5-2650L v3 @ 1.80GHz (6) x64 AES
                L2:0.8 MB L3:30.0 MB 6C/6T NUMA:1
 * MEMORY       8.5/15.7 GB (54%)
 * DONATE       10%
 * ASSEMBLY     auto:intel
 * POOL #1      rxtest.biblepay.org:3008 algo auto
 * COMMANDS     hashrate, pause, resume
 * OPENCL       disabled
 * CUDA         disabled
[2020-02-15 18:24:31.011]  net  use pool rxtest.biblepay.org  Orphan Charity
[2020-02-15 18:24:31.011]  net  new job from rxtest.biblepay.org diff 75000 algo rx/0 height 2034566
[2020-02-15 18:24:31.016]  msr  msr kernel module is not available

BBP pool
Biblepay
Code: [Select]
Address BBP Shares BBP Invalid XMR Shares XMR Invalid XMR Charity Shares Efficiency Hashrate
yLnVyHJxEdVVLQSmafTPsQhaeomNV96gWu 19 5 34 0 0 79.16% 102.01 KH
XMR pool
Code: [Select]
2.94 KH/s 0.00 H/s 39041199 40000 0 less than a minute ago *base address*
XMR/BBP miner console
Code: [Select]
020-02-15 19:57:54.291]  net  new job from rxtest.biblepay.org diff 120621 algo rx/0 height 2034613
[2020-02-15 19:58:01.819] speed 10s/60s/15m 4106.8 4146.3 4165.3 H/s max 4319.6 H/s
[2020-02-15 19:58:54.263]  cpu  accepted (277/20) diff 1 BBP (0 ms)
[2020-02-15 19:59:01.868] speed 10s/60s/15m 4094.9 4103.8 4156.6 H/s max 4319.6 H/s
[2020-02-15 19:59:03.058]  net  new job from rxtest.biblepay.org diff 119971 algo rx/0 height 2034614
[2020-02-15 19:59:37.747]  net  new job from rxtest.biblepay.org diff 119321 algo rx/0 height 2034615
[2020-02-15 19:59:42.731]  net  new job from rxtest.biblepay.org diff 118678 algo rx/0 height 2034616
[2020-02-15 19:59:50.170]  cpu  rejected (277/21) diff 1 BBP "Stale" (0 ms)
[2020-02-15 20:00:01.925] speed 10s/60s/15m 4018.6 4080.5 4148.4 H/s max 4319.6 H/s
[2020-02-15 20:00:11.184]  cpu  accepted (278/21) diff 1 BBP (0 ms)
[2020-02-15 20:00:32.179]  cpu  accepted (279/21) diff 1 BBP (0 ms)
[2020-02-15 20:00:35.175]  cpu  accepted (280/21) diff 1 BBP (0 ms)
[2020-02-15 20:00:56.401]  net  new job from rxtest.biblepay.org diff 117412 algo rx/0 height 2034617
[2020-02-15 20:00:58.185]  cpu  rejected (280/22) diff 1 BBP "Stale" (0 ms)
[2020-02-15 20:01:01.984] speed 10s/60s/15m 3990.0 4023.2 4136.7 H/s max 4319.6 H/s


  • sunk818
  • Global Moderator

    • 521


    • 36
    • April 24, 2018, 02:02:20 PM
    more
Re: BIBLEPAY - RANDOMX INTEGRATION
« Reply #46 on: February 15, 2020, 11:55:27 PM »
I think it'd be a worthwhile experiment to see how much one would earn on a monero pool with the same hardware. Reason being is that 10% hash rate does not equal to 10% miner reward because you would need your hashes to go toward a successful monero block. What is the monero hash rate and how realistic is that bbp + xmr pool would be able to solve a monero block? the monero only pool mining would be a test to see how much would be earned from monero alone. same hardware can be pointed to bbp + xmr pool and see what results occur.


the other idea is to upstream xmr hashes to a xmr pool and get pool payments from the larger pool. when bbp + xmr pool gets large enough to contend as a pool that can hold its own, then it certainly makes sense to be its own pool.


just some random thoughts... i'm not married to either idea, just looking out for the orphans and how best to create a stable revenue stream for them.
BH6oxjLkyz3z8FYpvU3ZR7PTZ31Xt9DkXZ


  • earlzmoade
  • Super Developer

    • 311


    • 48
    • August 02, 2018, 03:22:01 AM
    more
Re: BIBLEPAY - RANDOMX INTEGRATION
« Reply #47 on: February 16, 2020, 02:42:28 AM »
I think it'd be a worthwhile experiment to see how much one would earn on a monero pool with the same hardware. Reason being is that 10% hash rate does not equal to 10% miner reward because you would need your hashes to go toward a successful monero block. What is the monero hash rate and how realistic is that bbp + xmr pool would be able to solve a monero block? the monero only pool mining would be a test to see how much would be earned from monero alone. same hardware can be pointed to bbp + xmr pool and see what results occur.


the other idea is to upstream xmr hashes to a xmr pool and get pool payments from the larger pool. when bbp + xmr pool gets large enough to contend as a pool that can hold its own, then it certainly makes sense to be its own pool.


just some random thoughts... i'm not married to either idea, just looking out for the orphans and how best to create a stable revenue stream for them.

We are already mining the monero part via minexmr, one of the biggest monero pools.
And ofc its about more than just pool hashrate, ddos protection pool uptime and what not.

Another topic are you guys getting 10%  rejected stale BBP shares?

i have 2541/283 accepted bbp shares seems alot rejected ones.
Joshua 1:9
Have i not commanded you?
Be strong and courageous. Do not be afraid;
do not be discouraged, for the Lord your God
will be with you wherever you go.


  • Rob Andrews
  • Administrator

    • 4090


    • 97
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Re: BIBLEPAY - RANDOMX INTEGRATION
« Reply #48 on: February 16, 2020, 09:01:57 AM »
We are already mining the monero part via minexmr, one of the biggest monero pools.
And ofc its about more than just pool hashrate, ddos protection pool uptime and what not.

Another topic are you guys getting 10%  rejected stale BBP shares?

i have 2541/283 accepted bbp shares seems alot rejected ones.

So before I answer let me give a background from my perspective on the BBP rejected shares:
On version 5.5.5, I was debugging for a couple days and I noticed repetetive behavior on the xmrig side - that about after 8 hours of mining, my BBP side would drop out.  It has something to do with an expiration (which I thought I fixed in 5.5.6).  But at that time, the BBP share would be rejected in every post but it was not a stale share.

So now moving along to 5.5.6, in this version, we reconnect to the pool and reauthorize the miner automatically after a certain amount of time - and I thought that fixed it.  However it appears this actually permutated the same error into stale shares instead of connectivity issues.

So before I went to sleep last night I rebooted the pool; and this confirms that the problem is definitely inside our xmrig (not in the pool).

So for now in summary:  If you restart the xmrig miner, you can mine perfectly for about 8 hours then we start to get stale shares on every share.
I just restarted mine and now its working again.

I'll look at this today.



  • Rob Andrews
  • Administrator

    • 4090


    • 97
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Re: BIBLEPAY - RANDOMX INTEGRATION
« Reply #49 on: February 16, 2020, 09:09:26 AM »
XMR miner on same hardware:
Code: [Select]
Model name:          Intel(R) Xeon(R) CPU E5-2650L v3 @ 1.80GHz
Stepping:            2
CPU MHz:             1797.916
BogoMIPS:            3595.83
Virtualization:      VT-x
Hypervisor vendor:   KVM
Virtualization type: full
L1d cache:           32K
L1i cache:           32K
L2 cache:            256K
L3 cache:            30720K
NUMA node0 CPU(s):   0-5
- Compile xmrig for XMR only
Validation of hash rate from pool:
Code: [Select]
2.35 KH/s 0.00 H/s 374925243 114492 0 about a minute ago paladin
Xmrig console output:
Code: [Select]
[2020-02-15 05:48:32.798]  net  new job from us-west.minexmr.com:443 diff 117786 algo rx/0 height 2034184
[2020-02-15 05:49:05.115] speed 10s/60s/15m 2077.5 2063.7 2011.9 H/s max 2164.9 H/s
[2020-02-15 05:49:28.820]  cpu  accepted (3383/0) diff 117786 (72 ms)
[2020-02-15 05:49:32.828]  net  new job from us-west.minexmr.com:443 diff 117750 algo rx/0 height 2034185
[2020-02-15 05:50:05.168] speed 10s/60s/15m 2065.7 2054.3 2012.8 H/s max 2164.9 H/s
[2020-02-15 05:50:05.777]  net  new job from us-west.minexmr.com:443 diff 117770 algo rx/0 height 2034186
[2020-02-15 05:51:05.220] speed 10s/60s/15m 2092.0 2082.8 2018.5 H/s max 2164.9 H/s
[2020-02-15 05:51:57.700]  cpu  accepted (3384/0) diff 117770 (72 ms)
[2020-02-15 05:52:05.275] speed 10s/60s/15m 2033.7 2085.6 2025.9 H/s max 2164.9 H/s
[2020-02-15 05:52:46.657]  cpu  accepted (3385/0) diff 117770 (72 ms)
[2020-02-15 05:53:05.333] speed 10s/60s/15m 2090.6 2094.7 2033.8 H/s max 2164.9 H/s
[2020-02-15 05:53:43.143]  net  new job from us-west.minexmr.com:443 diff 117692 algo rx/0 height 2034187
[2020-02-15 05:54:05.390] speed 10s/60s/15m 2111.2 2103.9 2039.1 H/s max 2164.9 H/s
[2020-02-15 05:54:14.771]  cpu  accepted (3386/0) diff 117692 (72 ms)

Compile BBP version
>cli -version
BiblePay Core RPC client version 1.5.0.2

Compile xmrig (BBP+XMR)

Code: [Select]
* ABOUT        XMRig/5.5.6 gcc/7.4.0
 * BBP + XMR - Welcome to the future of orphan charity
 * LIBS         libuv/1.18.0 OpenSSL/1.1.1 hwloc/1.11.9
 * HUGE PAGES   supported
 * 1GB PAGES    disabled
 * CPU          Intel(R) Xeon(R) CPU E5-2650L v3 @ 1.80GHz (6) x64 AES
                L2:0.8 MB L3:30.0 MB 6C/6T NUMA:1
 * MEMORY       8.5/15.7 GB (54%)
 * DONATE       10%
 * ASSEMBLY     auto:intel
 * POOL #1      rxtest.biblepay.org:3008 algo auto
 * COMMANDS     hashrate, pause, resume
 * OPENCL       disabled
 * CUDA         disabled
[2020-02-15 18:24:31.011]  net  use pool rxtest.biblepay.org  Orphan Charity
[2020-02-15 18:24:31.011]  net  new job from rxtest.biblepay.org diff 75000 algo rx/0 height 2034566
[2020-02-15 18:24:31.016]  msr  msr kernel module is not available

BBP pool
Biblepay
Code: [Select]
Address BBP Shares BBP Invalid XMR Shares XMR Invalid XMR Charity Shares Efficiency Hashrate
yLnVyHJxEdVVLQSmafTPsQhaeomNV96gWu 19 5 34 0 0 79.16% 102.01 KH
XMR pool
Code: [Select]
2.94 KH/s 0.00 H/s 39041199 40000 0 less than a minute ago *base address*
XMR/BBP miner console
Code: [Select]
020-02-15 19:57:54.291]  net  new job from rxtest.biblepay.org diff 120621 algo rx/0 height 2034613
[2020-02-15 19:58:01.819] speed 10s/60s/15m 4106.8 4146.3 4165.3 H/s max 4319.6 H/s
[2020-02-15 19:58:54.263]  cpu  accepted (277/20) diff 1 BBP (0 ms)
[2020-02-15 19:59:01.868] speed 10s/60s/15m 4094.9 4103.8 4156.6 H/s max 4319.6 H/s
[2020-02-15 19:59:03.058]  net  new job from rxtest.biblepay.org diff 119971 algo rx/0 height 2034614
[2020-02-15 19:59:37.747]  net  new job from rxtest.biblepay.org diff 119321 algo rx/0 height 2034615
[2020-02-15 19:59:42.731]  net  new job from rxtest.biblepay.org diff 118678 algo rx/0 height 2034616
[2020-02-15 19:59:50.170]  cpu  rejected (277/21) diff 1 BBP "Stale" (0 ms)
[2020-02-15 20:00:01.925] speed 10s/60s/15m 4018.6 4080.5 4148.4 H/s max 4319.6 H/s
[2020-02-15 20:00:11.184]  cpu  accepted (278/21) diff 1 BBP (0 ms)
[2020-02-15 20:00:32.179]  cpu  accepted (279/21) diff 1 BBP (0 ms)
[2020-02-15 20:00:35.175]  cpu  accepted (280/21) diff 1 BBP (0 ms)
[2020-02-15 20:00:56.401]  net  new job from rxtest.biblepay.org diff 117412 algo rx/0 height 2034617
[2020-02-15 20:00:58.185]  cpu  rejected (280/22) diff 1 BBP "Stale" (0 ms)
[2020-02-15 20:01:01.984] speed 10s/60s/15m 3990.0 4023.2 4136.7 H/s max 4319.6 H/s

Thanks!
So it is very nice that your console(s) confirm that you receive 2070/4023 hps (confirming roughly 195% increase is consistent with earlz's results also) - I will add this result to the wiki page.

This also confirms that you will receive almost exactly the same XMR reward if you mine against minexmr as you would against the biblepay/xmr side.  If anyone wants to switch for a couple days feel free to as you will easily see on the minexmr earnings page the results earned.

As far as our Nomp pools hash/ps readout, I do realize that is completely wrong.  Its because no multiplier exists yet for randomx.  Ill create one asap.  I believe its just a matter of changing the multiple from 256 to something like 2.5  - (randomx hashes take a massive amount of time compared to x11 hashes - something like 2000:200000).

Edit:  Ill fix the getting started guide along with the multiplier right after we release this next bug fix.
« Last Edit: February 16, 2020, 09:18:09 AM by Rob Andrews »


  • Rob Andrews
  • Administrator

    • 4090


    • 97
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Re: BIBLEPAY - RANDOMX INTEGRATION
« Reply #50 on: February 16, 2020, 02:09:49 PM »
Ok, I updated the rxtest pool algorithm properties to be much closer to randomx.  So now the worker hashrate speed should be "closer".

Also the graph should come down to earth over the next 4 hours.

I also updated the getting started tab with the proper starting instructions.

Let me burn in the new version of xmrig before I deploy it.  If it lasts over the next 4 hours Ill preliminarily release it so we can all test it.



  • earlzmoade
  • Super Developer

    • 311


    • 48
    • August 02, 2018, 03:22:01 AM
    more
Re: BIBLEPAY - RANDOMX INTEGRATION
« Reply #51 on: February 17, 2020, 09:31:32 AM »
Did Another comparison with 8 threads and higher Clocks.

  • Ryzen 5 1600 (14nm)@3.3ghz, Asus b350 rog strix,  8 threads, --cpu-affinity 0xD75, 1x8gb 3200mhz cl16
  • BBP+Xmr-8740 HPS, 70 watts
  • Ryzen 5 1600 (14nm)@3.3ghz, Asus b350 rog strix,  8 threads, --cpu-affinity 0xD75, 1x8gb 3200mhz cl16
  • Xmr only - 4375HPS, 70 watts

Conclusion 10.6% increase in hashrate but 27% increase in power
Joshua 1:9
Have i not commanded you?
Be strong and courageous. Do not be afraid;
do not be discouraged, for the Lord your God
will be with you wherever you go.


  • earlzmoade
  • Super Developer

    • 311


    • 48
    • August 02, 2018, 03:22:01 AM
    more
Re: BIBLEPAY - RANDOMX INTEGRATION
« Reply #52 on: February 17, 2020, 09:36:02 AM »
Did Another comparison with 8 threads and higher Clocks.

  • Ryzen 5 1600 (14nm)@3.8ghz, 1.15v vcore, Asus b350 rog strix,  8 threads, --cpu-affinity 0xD75, 1x8gb 3200mhz cl16
  • BBP+Xmr-8740 HPS, 70 watts
  • Ryzen 5 1600 (14nm)@3.8ghz, 1.15v vcore, Asus b350 rog strix,  8 threads, --cpu-affinity 0xD75, 1x8gb 3200mhz cl16
  • Xmr only - 4375HPS, 70 watts

Conclusion 10.6% increase in hashrate but 27% increase in Power over the 6 thread config.
Joshua 1:9
Have i not commanded you?
Be strong and courageous. Do not be afraid;
do not be discouraged, for the Lord your God
will be with you wherever you go.


  • Rob Andrews
  • Administrator

    • 4090


    • 97
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Re: BIBLEPAY - RANDOMX INTEGRATION
« Reply #53 on: February 17, 2020, 09:42:36 AM »
Did Another comparison with 8 threads and higher Clocks.

  • Ryzen 5 1600 (14nm)@3.3ghz, Asus b350 rog strix,  8 threads, --cpu-affinity 0xD75, 1x8gb 3200mhz cl16
  • BBP+Xmr-8740 HPS, 70 watts
  • Ryzen 5 1600 (14nm)@3.3ghz, Asus b350 rog strix,  8 threads, --cpu-affinity 0xD75, 1x8gb 3200mhz cl16
  • Xmr only - 4375HPS, 70 watts

Conclusion 10.6% increase in hashrate but 27% increase in power

Thats interesting that the 11% increase pulls 27% more watts (probably 14 more watts or so).
But it also makes me wonder about total system power consumption to break even with XMR.  I remember seeing something like 10,000 hps required to breakeven at 8 cents a kwh, but I believe I was using 500 watts for the power supply.

So out of curiosity do you know if any of these industrial miners can pack 10 ryzen procs in a single machine using some type of board, so the total system power supply is only 1500 watts?  Similar to how they chain asics together?

Im seeing that the casual gamer will pretty much receive their stipend back in the form of xmr while the household pays the electricity (plus they get bbp of course in our case which is a pro).

Im almost ready to release the new miner.



  • Rob Andrews
  • Administrator

    • 4090


    • 97
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Re: BIBLEPAY - RANDOMX INTEGRATION
« Reply #54 on: February 17, 2020, 09:55:33 AM »
BBP Xmrig 5.5.7e - Leisure Upgrade



Ok, this version theoretically stops the dropouts, let us please test it. 



  • earlzmoade
  • Super Developer

    • 311


    • 48
    • August 02, 2018, 03:22:01 AM
    more
Re: BIBLEPAY - RANDOMX INTEGRATION
« Reply #55 on: February 17, 2020, 10:53:09 AM »
Thats interesting that the 11% increase pulls 27% more watts (probably 14 more watts or so).
But it also makes me wonder about total system power consumption to break even with XMR.  I remember seeing something like 10,000 hps required to breakeven at 8 cents a kwh, but I believe I was using 500 watts for the power supply.

So out of curiosity do you know if any of these industrial miners can pack 10 ryzen procs in a single machine using some type of board, so the total system power supply is only 1500 watts?  Similar to how they chain asics together?

Im seeing that the casual gamer will pretty much receive their stipend back in the form of xmr while the household pays the electricity (plus they get bbp of course in our case which is a pro).

Im almost ready to release the new miner.



For sure its intresting idea daisy chain cpus.  Atleast i dont think there is that for ryzen processors, closest would be to get some dual socket epyc processors i belive.
Myself i just get asus boards so i can setup OS  and miner remote access and all then remove gpu and just run the machine headless.  Saves a few watts not having to think of the gpu.


something like the intel xeon phi but for ryzen would be sweet.

However we think about it its intresting years ahead with 3d stacking cpus, ddr5 coming to zen 4 i belive it was, intels forevos and so on.
Joshua 1:9
Have i not commanded you?
Be strong and courageous. Do not be afraid;
do not be discouraged, for the Lord your God
will be with you wherever you go.


  • Rob Andrews
  • Administrator

    • 4090


    • 97
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Re: BIBLEPAY - RANDOMX INTEGRATION
« Reply #56 on: February 18, 2020, 08:48:34 AM »
So I'm going through the code today in an attempt to merge the latest randomx changes into xmrig, and also to harden the build to prevent crashes.
This algorithm is huge, it's a monster when considering how much machine language is generated.
I've exploited some conditions where the bytecode that is generated crashes about 10 stack frames ahead of the last hash (another words the actual crash occurs in the rx virtual machine, in machine language).  Ive been trying to isolate this as it appears to actually be in the jit code on the rx side (last night I removed all the possible biblepay code around it and it still points to the jit code, so Im merging in the latest from XMRig now to see if its something they fixed recently).

But anyway, Id like to find out each OS version that is running out there.  Im using windows 7.  Can each of you please post if you are primarily using the windows exe or the linux version?

After the next build we will need a volunteer to run the linux version for a few days straight, to ensure the jit issue is fixed.  The windows version will probably be OK, as we have a compiler flag we can  set that will overcome any machine language exceptions and let it recover (and keep mining).


  • earlzmoade
  • Super Developer

    • 311


    • 48
    • August 02, 2018, 03:22:01 AM
    more
Re: BIBLEPAY - RANDOMX INTEGRATION
« Reply #57 on: February 18, 2020, 09:17:36 AM »
So I'm going through the code today in an attempt to merge the latest randomx changes into xmrig, and also to harden the build to prevent crashes.
This algorithm is huge, it's a monster when considering how much machine language is generated.
I've exploited some conditions where the bytecode that is generated crashes about 10 stack frames ahead of the last hash (another words the actual crash occurs in the rx virtual machine, in machine language).  Ive been trying to isolate this as it appears to actually be in the jit code on the rx side (last night I removed all the possible biblepay code around it and it still points to the jit code, so Im merging in the latest from XMRig now to see if its something they fixed recently).

But anyway, Id like to find out each OS version that is running out there.  Im using windows 7.  Can each of you please post if you are primarily using the windows exe or the linux version?

After the next build we will need a volunteer to run the linux version for a few days straight, to ensure the jit issue is fixed.  The windows version will probably be OK, as we have a compiler flag we can  set that will overcome any machine language exceptions and let it recover (and keep mining).

Im using windows 10 on my machines.
Gonna move over my headless systems to ubuntu.  Also im no linux guru so  yeah.....

Also i have been running almost 24 hours now i belive this latest miner and it seems to me it works pretty nice.

I have  3.99%  rejected shares for bbp.
Perhaps i can get less rejected shares by changing difficulty to 256 for bbp ?

Joshua 1:9
Have i not commanded you?
Be strong and courageous. Do not be afraid;
do not be discouraged, for the Lord your God
will be with you wherever you go.


  • Rob Andrews
  • Administrator

    • 4090


    • 97
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Re: BIBLEPAY - RANDOMX INTEGRATION
« Reply #58 on: February 18, 2020, 10:39:27 AM »
Im using windows 10 on my machines.
Gonna move over my headless systems to ubuntu.  Also im no linux guru so  yeah.....

Also i have been running almost 24 hours now i belive this latest miner and it seems to me it works pretty nice.

I have  3.99%  rejected shares for bbp.
Perhaps i can get less rejected shares by changing difficulty to 256 for bbp ?
Oh ok, good to know that you have a headless linux to test on also.
Yes, please let me make a post first for the next release so you can test with the newest version as Im seeing now that monero actually doesnt recommend people to debug in MSVS as some devs are complaining about crashes, so Im building a windows version now in mingw64, to see if the problem the whole time has been the way VS2017 compiles the code.  I also see XMRig no longer supports VS.

Uh, as far as rejects, I don't think we have to worry much as let me explain something on those - and since we are such as "niche" this is actually slightly different info than POBH, or RX in prod.  Since bbp-rx solves for an algorithm, our stales mean any hash that was submitted after the block changes (or a client really was solving for the wrong prior block hash).

So, in our case our hashes will really be minimized when the difficulty increases.
Another words:  With tiny diff (we have a .005 diff in testnet), if any miners share solves the block, there is a very high propensity for stale shares over the next 30 seconds (while the clients abort the current shares and get new ones).

However, when diff is say 10 in prod, since we do support multiple solutions per round (this is in contrast to the way bbp in prod works, which will be a big pro).  Another words, you can have 20 threads running, and if 10 solve shares, they will all be accepted (because all 10 had a chance to solve that block for that round).

So basically, its more on my end - I will try increasing the pools latency for block scanning in testnet.  But in testnet, if we can get diff to increase, stale shares should drop even more to a miniscule number (ie < 1%).



  • Rob Andrews
  • Administrator

    • 4090


    • 97
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Re: BIBLEPAY - RANDOMX INTEGRATION
« Reply #59 on: February 18, 2020, 11:08:46 AM »
XMRig - 5.5.8 - Leisure Upgrade
GCC Version



This release is the GCC version for both windows and linux.
May we please test this new version on both platforms to ensure long term stability?