Messages

1996

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« 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.

1997

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« 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.

1998

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« on: February 15, 2020, 02:34:13 PM »

Ok, thank you for reporting the processMessages issue, and also starting to recreate your sancs.  I haven't gotten around to the sancs yet (I turned off chainlocks in testnet temporarily so we can run free of sancs for a while).  But yes we can get back to that as soon as we prove RX is running reliably.

I will check out the process messages very soon - hopefully today.

In the mean time I have a new version of the pool to be released and a new miner (that adresses the shutoff bug after N hours).

Let me explain how these features work and then we can get back to checking the core client messages.

So I debugged the processMessages (FAIL) error, and the great news is it is a harmless error and has something to do with the way we are checking the minimum peer governance version, and the message in the log is harmless.  I fixed this for the next version; but no rush in releasing it til we have a new testnet release.

I also discovered while testing your reported bug that we have an inefficiency to fix while scanning randomx headers - it turns out we can speed up the process for assessing GSCs and memorizing the prayers ; Ill let this wait also til the next release also.

1999

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« on: February 15, 2020, 12:43:58 PM »

** XMRIG 5.5.6 - Leisure Upgrade for TestNet **


Xmrig 5.5.6 is ready.  In this version we solved the issue where the bbp side mining drops out after N hours. 

Also, the rxtest pool has been upgraded.
Now you can see your XMR and BBP shares in the worker stats, and I have extended the round time to 15 minutes so we can see a clearer picture of orphan charity vs bbp mining in the worker stats.

As far as XMR transparency, we have added a new tab to the nomp pool:  XMR Inquiry.
From here you can click it and type in your XMR address and click search.  The minexmr pool will show you what you are owed on the xmr side.
To adjust your reward threshhold you can decrease it from there or request an immediate withdrawal.

So as you can see, we pass all RandomX XMR shares directly through to minexmr, hence the reason we are leveraging their website for XMR payments.

In the near future I will expose a BX link for the pools XMR charity address also - so users can click on that address and also see the BX transactions (IE what the pool generated for charity).

2000

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« on: February 15, 2020, 09:39:51 AM »

So looking at this processMessages issue, yes, I confirm this is something new that has been introduced into the RandomX core version (develop) and all of our nodes are doing it for some reason when they send the version message.  So far it has not been affecting us actually connecting with each other but yet this is something that needs fixed.

Ill just put this on the todo list for now as my goal today is to:
- Fix the bug where we drop the bbp mining after hours in xmrig
- Expose the monero shares in the pool

Ok, thank you for reporting the processMessages issue, and also starting to recreate your sancs.  I haven't gotten around to the sancs yet (I turned off chainlocks in testnet temporarily so we can run free of sancs for a while).  But yes we can get back to that as soon as we prove RX is running reliably.

I will check out the process messages very soon - hopefully today.

In the mean time I have a new version of the pool to be released and a new miner (that adresses the shutoff bug after N hours).

Let me explain how these features work and then we can get back to checking the core client messages.

2001

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« on: February 15, 2020, 09:34:30 AM »

I noticed how the some cycles are donated to charity for both BBP and XMR. The donation appears to be identified by the "-Charity" to be transparent.

Code: [Select]

[2020-02-14 12:04:46.623]  net  orphan donations started
[2020-02-14 12:04:46.624]  net  new job from rxtest.biblepay.org-Charity diff 75000 algo rx/0 height 2033630
[2020-02-14 12:04:46.774]  net  new job from rxtest.biblepay.org-Charity diff 75000 algo rx/0 height 2033631
[2020-02-14 12:05:08.887]  cpu  accepted (1/0) diff 75000 XMR-Charity (0 ms)
[2020-02-14 12:05:23.498]  net  new job from rxtest.biblepay.org-Charity diff 75000 algo rx/0 height 2033632
[2020-02-14 12:05:24.817] speed 10s/60s/15m 118.2 240.9 n/a H/s max 351.7 H/s
[2020-02-14 12:05:28.819]  net  new job from rxtest.biblepay.org-Charity diff 75000 algo rx/0 height 2033633
[2020-02-14 12:06:24.977] speed 10s/60s/15m 164.8 164.5 n/a H/s max 351.7 H/s
[2020-02-14 12:07:25.180] speed 10s/60s/15m 163.5 160.8 n/a H/s max 351.7 H/s
[2020-02-14 12:08:25.328] speed 10s/60s/15m 180.7 176.4 n/a H/s max 351.7 H/s
[2020-02-14 12:09:25.543] speed 10s/60s/15m 143.6 154.2 n/a H/s max 351.7 H/s
[2020-02-14 12:10:25.847] speed 10s/60s/15m 149.0 146.0 n/a H/s max 351.7 H/s
[2020-02-14 12:10:28.868]  net  new job from rxtest.biblepay.org-Charity diff 14249 algo rx/0 height 2033633
[2020-02-14 12:11:05.134]  net  new job from rxtest.biblepay.org-Charity diff 11974 algo rx/0 height 2033634
[2020-02-14 12:11:15.687]  cpu  accepted (2/0) diff 11974 XMR-Charity (0 ms)
[2020-02-14 12:11:19.910]  net  new job from rxtest.biblepay.org-Charity diff 11974 algo rx/0 height 2033635
[2020-02-14 12:11:26.076] speed 10s/60s/15m 157.2 155.5 n/a H/s max 351.7 H/s
[2020-02-14 12:12:26.316] speed 10s/60s/15m 168.9 190.3 n/a H/s max 351.7 H/s
[2020-02-14 12:13:26.569] speed 10s/60s/15m 170.8 170.9 n/a H/s max 351.7 H/s
[2020-02-14 12:13:39.624]  net  new job from rxtest.biblepay.org-Charity diff 10000 algo rx/0 height 2033636
[2020-02-14 12:14:26.781] speed 10s/60s/15m 252.3 183.5 n/a H/s max 351.7 H/s
[2020-02-14 12:14:39.043]  net  new job from rxtest.biblepay.org-Charity diff 10000 algo rx/0 height 2033637
[2020-02-14 12:14:46.625]  net  orphan donations finished

I can see the start and end of the orphan donations and then afterward I can see that I am now mining to my wallet, I presume.

Code: [Select]

[2020-02-14 12:14:46.628]  net  new job from rxtest.biblepay.org diff 10000 algo rx/0 height 2033637
[2020-02-14 12:14:50.578]  cpu  accepted (3/0) diff 10000 XMR (91 ms)
[2020-02-14 12:14:57.340]  cpu  accepted (4/0) diff 10000 XMR (90 ms)
[2020-02-14 12:14:57.568]  cpu  accepted (5/0) diff 10000 XMR (90 ms)
[2020-02-14 12:15:01.172]  net  new job from rxtest.biblepay.org diff 10000 algo rx/0 height 2033638


Yes, exactly.  Over a longer period, say overnight, it should spend roughly 10% of its time donating to the pools XMR address.
I'm about to release the new pool version which computes the randomx share count and exposes it on the page also, so hopefully this will make it completely transparent.

We will also expose the pools charity address somewhere on the page, so they can click a tab and see the donations that have been mined in a given month.  I think one way we can work around Moneros anonymity features, is we can train people to look at 'the last 4 weeks of revenue mined to the XMR charity address for the pool'.  That should roughly match the monthly pool charity expenses and give a pretty close idea they are in compliance.  The script that checks the pool can work over a longer period etc.

Also, I just realized, we can make an api available to people who want to scrape the shares.  This would allow anyone to see that the pool is actually hashing 10% to orphan charity shares.  I know in the future we will need to enforce that so eventually we can release the plan that will spork-check the pools adresses, but in the launch phase, anyone can scrape the orphan share count once per hour off the pool api, and log the charity shares solved and the total pools share solved.  This should show 10% of our hashes are going to charity.

So, I think this idea is actually viable from what I can tell from a high level.

2002

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« on: February 15, 2020, 08:50:00 AM »

Here comes some numbers from my part without fiddling to much with threads and affinity settings.  Large pages and MSR mod is active on all tests.

Ryzen 5 3600@4ghz, msi b450m Gaming plus, 1.2v vcore, 12 threads, 2x4gb 2666 cl16

• Bbp+xmr=13900-14000HPS
• 70watts (package powerdraw)

• xmrig 5.3.0, monero hashrate = 6900-7050HPS
• 69-70watts (package powerdraw)

Ryzen 5 1600 (14nm)@3.3ghz, Asus b350 rog strix, 1,05v vcore, 6 threads, --cpu-affinity 0x555 1x8gb 3200mhz cl16

• Bbp+xmr= 7863-7900HPS
• 55 watts (package powerdraw)

• xmrig 5.3.0 , monero hashrate=3911-3950HPS
• 55watts (package powerdraw)

[email protected], msi x399 gaming pro carbon ac, 1,15v vcore, 16 threads --cpu-affinity 0x5D75D7, 4x4gb 3200mhz cl16

• Bbp+xmr=16100-16300HPS
• 140-145watts (package powerdraw)

• xmrig 5.3.0, monero hashrate= 8050-8400HPS
• 140-145 watts (package powerdraw)

This is really excellent.

Thank you very much.

I'll put this in a spreadsheet right now, and attach it to the op post.

What this points to is a 99% efficiency level, (or truly a 198% hashpower increase without much overhead at all).  This is great, because our mission is being accomplished without any compromises.  We are not compromising blockchain security, because each solution must be based on the last block in our equation.  The miners receive two sources of income.

Its very interesting.  It appears to have the potential to be 'the cpu worlds' version of merged mining.

So yes, mining XMR alone is actually barely profitable, but the way we can look at this is our miner gets the electric bill covered from the XMR side and the BBP side is potentially pure profit.  BBP receives a revenue stream for orphan sponsorships that doesn't add sell pressure.  I feel this has the potential to take off.

Btw everyone, I spoke to Steven from SAI.ngo and he confirmed that we can sponsor Venezuelan orphans for the wholesale rate of $20.  Ill post more on that topic on the main thread.

Ok, I made a wiki page for it:
https://wiki.biblepay.org/RandomX_Hashing_Speed_Comparison

I will post it in the op.

2003

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« on: February 15, 2020, 08:38:15 AM »

Ok, I must have read the xmrig console text wrong then.


Initially, it took 15 minutes last night for me to get a share... then started being more consistent. So, that's what lead me to believe it was set at a high diff.

Yeah there are large swings sometimes, I solved 5 bbp for 1 randomx, then the opposite later.

I look forward to this next version will be more transparent.

2004

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« on: February 14, 2020, 11:03:33 AM »

Code: [Select]

2020-02-14 14:55:50 ProcessMessages(version, 141 bytes) FAILED peer=2115
2020-02-14 14:55:59 ProcessMessages(version, 141 bytes) FAILED peer=2116
2020-02-14 14:57:05 ProcessMessages(version, 141 bytes) FAILED peer=2117
2020-02-14 14:57:10 ProcessMessages(version, 141 bytes) FAILED peer=2118
2020-02-14 14:57:28 ProcessMessages(version, 141 bytes) FAILED peer=2119
2020-02-14 14:57:31 ProcessMessages(version, 141 bytes) FAILED peer=2120
2020-02-14 14:57:41 ProcessMessages(version, 141 bytes) FAILED peer=2121
2020-02-14 14:57:42 ProcessMessages(version, 141 bytes) FAILED peer=2122
2020-02-14 14:57:55 CGovernanceObject::RequestOrphanObjects -- number objects = 0
2020-02-14 14:58:00 ProcessMessages(version, 141 bytes) FAILED peer=2123
2020-02-14 14:58:00 ProcessMessages(version, 141 bytes) FAILED peer=2124
2020-02-14 14:58:01 ProcessMessages(version, 141 bytes) FAILED peer=2125
2020-02-14 14:58:12 ProcessMessages(version, 141 bytes) FAILED peer=2126
2020-02-14 14:59:02 AdvertiseLocal: advertising address 45.62.240.90:40001


So looking at this processMessages issue, yes, I confirm this is something new that has been introduced into the RandomX core version (develop) and all of our nodes are doing it for some reason when they send the version message.  So far it has not been affecting us actually connecting with each other but yet this is something that needs fixed.

Ill just put this on the todo list for now as my goal today is to:
- Fix the bug where we drop the bbp mining after hours in xmrig
- Expose the monero shares in the pool

2005

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« on: February 14, 2020, 10:06:52 AM »

Could you perhaps start the pool at 10k difficulty then go up? 75k is too high for my little single 4c/4t machine.

75k is the monero diff for the current block, but the actual pool difficulty is only 1 (for both XMR or BBP).

2006

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« on: February 14, 2020, 10:04:46 AM »

Thank you, I have now got it the external and wallet set up and am mining on testnet

http://rxtest.biblepay.org/workers (BBP)
ygsYVjsR5RamCuiXyHUAoZb7nq8aM1WDUP   1   0   100%   21.47 KH

https://minexmr.com/#worker_stats (XMR pool to test)
16.67 H/s   0.00 H/s   410000   0   0   4 minutes ago   *base address*

Code: [Select]

vm.nr_hugepages = 4
1GB pages successfully enabled
 * CPU          Intel(R) Xeon(R) CPU X7560 @ 2.27GHz (2) x64 -AES
                L2:0.5 MB L3:48.0 MB 4C/4T NUMA:1
 * MEMORY       1.4/3.9 GB (37%)
 * DONATE       10%
 * ASSEMBLY     auto:none
 * POOL #1      rxtest.biblepay.org:3008 algo auto
 * COMMANDS     hashrate, pause, resume
 * OPENCL       disabled
 * CUDA         disabled
[2020-02-14 06:49:37.424]  net  use pool rxtest.biblepay.org  Orphan Charity
[2020-02-14 06:49:37.424]  net  new job from rxtest.biblepay.org diff 75000 algo rx/0 height 2033499
[2020-02-14 06:49:37.424]  rx   init dataset algo rx/0 (4 threads) seed 154eb7a21cd32a59...
[2020-02-14 06:49:37.426]  rx   allocated 2336 MB (2080+256) huge pages 0% 0/1168 +JIT (1 ms)
[2020-02-14 06:50:26.275]  rx   dataset ready (48850 ms)
[2020-02-14 06:50:26.276]  cpu  use profile  *  (2 threads) scratchpad 2048 KB
[2020-02-14 06:50:26.309]  cpu  READY threads 2/2 (2) huge pages 100% 2/2 memory 4096 KB (33 ms)
[2020-02-14 06:50:52.508]  cpu  accepted (1/0) diff 1 BBP (0 ms)
[2020-02-14 06:51:26.459] speed 10s/60s/15m 135.1 134.1 n/a H/s max 183.3 H/s
[2020-02-14 06:51:35.559]  net  new job from rxtest.biblepay.org diff 54217 algo rx/0 height 2033500
[2020-02-14 06:52:26.599] speed 10s/60s/15m 131.6 137.5 n/a H/s max 183.3 H/s
[2020-02-14 06:53:11.739] [rxtest.biblepay.org:3008] read error: "end of file"
[2020-02-14 06:53:12.776]  net  orphan donations started
[2020-02-14 06:53:12.776]  net  new job from rxtest.biblepay.org-Charity diff 75000 algo rx/0 height 2033500
[2020-02-14 06:53:20.105]  net  new job from rxtest.biblepay.org-Charity diff 75000 algo rx/0 height 2033501
[2020-02-14 06:53:26.833] speed 10s/60s/15m 138.0 125.3 n/a H/s max 183.3 H/s
[2020-02-14 06:53:33.432]  net  new job from rxtest.biblepay.org-Charity diff 75000 algo rx/0 height 2033502
[2020-02-14 06:54:27.094] speed 10s/60s/15m 123.8 117.0 n/a H/s max 183.3 H/s
[2020-02-14 06:55:27.334] speed 10s/60s/15m 113.1 113.6 n/a H/s max 183.3 H/s
[2020-02-14 06:55:31.757] [rxtest.biblepay.org:3008] read error: "end of file"
[2020-02-14 06:56:27.530] speed 10s/60s/15m 155.6 147.5 n/a H/s max 200.6 H/s
[2020-02-14 06:57:27.724] speed 10s/60s/15m 117.2 148.3 n/a H/s max 220.5 H/s
[2020-02-14 06:58:27.906] speed 10s/60s/15m 135.9 151.8 n/a H/s max 236.7 H/s
[2020-02-14 06:58:33.536]  net  new job from rxtest.biblepay.org-Charity diff 50000 algo rx/0 height 2033502
[2020-02-14 06:59:01.798] [rxtest.biblepay.org:3008] read error: "end of file"
[2020-02-14 06:59:28.023] speed 10s/60s/15m 140.9 170.6 n/a H/s max 236.7 H/s
[2020-02-14 06:59:37.751]  net  new job from rxtest.biblepay.org-Charity diff 33333 algo rx/0 height 2033503

note the errors
[2020-02-14 06:55:31.757] [rxtest.biblepay.org:3008] read error: "end of file"

debug.log (tail)

Code: [Select]

2020-02-14 14:54:36 ProcessMessages(version, 141 bytes) FAILED peer=2111
2020-02-14 14:54:41 Flushed 49 addresses to peers.dat  11ms
2020-02-14 14:54:52 ProcessMessages(version, 141 bytes) FAILED peer=2112
2020-02-14 14:55:10 ProcessMessages(version, 141 bytes) FAILED peer=2113
2020-02-14 14:55:36 CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 28764 fInitialDownload=0
2020-02-14 14:55:36 ConnectBlock(BIBLEPAY): spork is off, skipping transaction locking checks
2020-02-14 14:55:36 UpdateTip: new best=7394ea2f327ddbd1bbbb865412bb2106a20249d63455c894351c3ed5ef0844cf height=28764 version=0x50000010 log2_work=48.51122856 tx=46915 date='2020-02-14 14:54:42' progress=0.999988 cache=11.7MiB(63827txo) evodb_cache=1.5MiB
2020-02-14 14:55:36 {PNB}: ACC  ProcessMessages(version, 141 bytes) FAILED peer=2114
2020-02-14 14:55:50 ProcessMessages(version, 141 bytes) FAILED peer=2115
2020-02-14 14:55:59 ProcessMessages(version, 141 bytes) FAILED peer=2116
2020-02-14 14:57:05 ProcessMessages(version, 141 bytes) FAILED peer=2117
2020-02-14 14:57:10 ProcessMessages(version, 141 bytes) FAILED peer=2118
2020-02-14 14:57:28 ProcessMessages(version, 141 bytes) FAILED peer=2119
2020-02-14 14:57:31 ProcessMessages(version, 141 bytes) FAILED peer=2120
2020-02-14 14:57:41 ProcessMessages(version, 141 bytes) FAILED peer=2121
2020-02-14 14:57:42 ProcessMessages(version, 141 bytes) FAILED peer=2122
2020-02-14 14:57:55 CGovernanceObject::RequestOrphanObjects -- number objects = 0
2020-02-14 14:58:00 ProcessMessages(version, 141 bytes) FAILED peer=2123
2020-02-14 14:58:00 ProcessMessages(version, 141 bytes) FAILED peer=2124
2020-02-14 14:58:01 ProcessMessages(version, 141 bytes) FAILED peer=2125
2020-02-14 14:58:12 ProcessMessages(version, 141 bytes) FAILED peer=2126
2020-02-14 14:59:02 AdvertiseLocal: advertising address 45.62.240.90:40001


Let me know if the processMessages have gone away once you synced to the top.
The end of file error is pretty normal; that happens ocasionally and the miner recovers from it.
But Ill try to trap that today and see what the root cause is while Im looking for the timeout issue.

EDIT:
Ok I see you are synced to the top.  Ok, after I look into the xmrig timeout, I will look into my dev nodes log and see if I have the same process messages errors.

2007

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« on: February 14, 2020, 10:02:17 AM »

    Yeah i was getting the same error this morning but on windows10.

I think you were in the pool actually, you can see in block history that you were mining for hours.

2008

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« on: February 14, 2020, 10:01:20 AM »

i sent some accepted hashes but my yf address is not showing up on pool workers. is that to be expected?


http://rxtest.biblepay.org/workers

Yes, its to be expected if you hash a couple and let the block go by, yes (as you probably know from experience of running nomp pool, that the round changes when blocks change).

EDIT: Btw, the nomp in its current state only registers the BBP solved shares - the XMR shares pass through to the monero side which is not exposed in the pool yet.  Im going to add metrics for that asap.  So you must also ensure the solved hashes are solving BBP shares as XMR dont register.

2009

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« on: February 14, 2020, 09:59:14 AM »

Have been running cense last evening the bbp-xmrig dual miner.  Theres no diffrence in wattage from just mining monero to this dual miner  from what i can tell.

Came home from part time work and i see that the miner is still running, the monero "part" of it anyway but the BBP shares stopped like 5 hours ago, ill link the log file:

Thats great, yeah on the bbp part dropping out, I see the same behavior.  What I have discovered is I can dual mine for about 8-14 hours or so, then the monero side keeps working and the bbp side stops.  I have a feeling that something in the code has a timeout (on the bbp side in xmrig) that I need to fix. 

In the mean time, all, please just restart the miner after a few hours if the bbp drops out and you will see yourself in the pool again.

You can clearly see the problem btw on the xmrig side by looking in the console window and seeing no "BBP 1" shares solved.

But anyway I wanted to ask you the most crucial question (Im glad to hear the wattage is the same).  Could you please do a side by side baseline between pure XMR mining from their xmrig, vs biblepay dual mining using our xmrig?  That is show us your hashrate for XMR alone vs dual XMR-BBP?  Id like to see the efficiency drop % that our blakehashes take away from the total?

Thanks!

2010

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« on: February 13, 2020, 02:40:04 PM »

I logged latest attempt and seems pretty high hashrate jump for me gonna play abit with threads and cores for my ryzen 5 1600.

gonna try a ryzen 5 3600 and a 1920x in the coming days aswell.

Looks like 8-10% increase for me in hashrate with the MSR mod Active.

Thats great!

Yeah, Ill post my HPS when I finally reboot.  I remember seeing about 5,000 hps when my memory is in use, but around 9,000 on a fresh reboot when the large pages are available.