BIBLEPAY - RANDOMX INTEGRATION

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?

Sure thing. I will try Windows version today and tomorrow evening hopefully i will have a new rig for linux to test on aswell.

Hey Rob.

Im testing new miner now.
Quick question, i changed the : rxtest.biblepay.org:3008 to rxtest.biblepay.org:3256

to change difficulty. Monero and charity monero seems fine from output but i havent seens any bbp solved or rejected.

Should i switch back to starting difficulty ?
Also can say that i have been running miner for 30 minutes so i figured should have gotten some bbp shares solved atleast.

Hey Rob.

Im testing new miner now.
Quick question, i changed the : rxtest.biblepay.org:3008 to rxtest.biblepay.org:3256

to change difficulty. Monero and charity monero seems fine from output but i havent seens any bbp solved or rejected.

Should i switch back to starting difficulty ?
Also can say that i have been running miner for 30 minutes so i figured should have gotten some bbp shares solved atleast.

Yeah, I think 256 is way too hard for randomx, let me go in and edit the pool settings and change two settings.  Just a wild guess but we might be able to get away with 2 and 5, Ill let you test those.  Theoretically the payments will work fine with the new settings - but Ill post when these are changed.

Btw, I have been debugging the GCC version now, trying to get to the source of that machine language error and I believe I finally found it.
(This Randomx algo is very interesting in that hashes have to be done in order.  Basically the problem was the original monero devs make it like this:
first hash -> next Hash -> . . . -> Test hash from a separate VM
BBP was like this:
First hash -> next Hash -> Test hash from the 'same' virtual machine.
(Sounds innoculous but the problem is it corrupts the scratchpad, and I wouldnt have known that except through this trial and error (that took about 3 days of debugging).

I just hope this is behind us!

So, I need to issue a new release.  Thanks!

Hey Rob.

Im testing new miner now.
Quick question, i changed the : rxtest.biblepay.org:3008 to rxtest.biblepay.org:3256

to change difficulty. Monero and charity monero seems fine from output but i havent seens any bbp solved or rejected.

Should i switch back to starting difficulty ?
Also can say that i have been running miner for 30 minutes so i figured should have gotten some bbp shares solved atleast.

On the pool, I changed the 3 difficulties, please try these:

port 3008:  Diff = 2

Port 3032:  Diff = VarDiff (range:  1-10)

Port 3256:  Diff = 10

Thanks!

XMRig - 5.5.9


Please upgrade to 5.5.9 everyone as this version has the new code to prevent out of order execution.

5.5.9 i got up and running.
Im testing out the  3256 port.

after 5 minutes i got 2 biblepay shares so seems working better now with lower difficulty.

Positive the terminal got less cluttered. 

ill let it run 12 hours atleast.

5.5.9 i got up and running.
Im testing out the  3256 port.

after 5 minutes i got 2 biblepay shares so seems working better now with lower difficulty.

Positive the terminal got less cluttered. 

ill let it run 12 hours atleast.

Thanks, but unfortunately I added a new bug!

Re-releasing now (Ill increase the version).

XMRig - 5.6.0

- Fix share submission bug

On the pool, I changed the 3 difficulties, please try these:

port 3008:  Diff = 2

Port 3032:  Diff = VarDiff (range:  1-10)

Port 3256:  Diff = 10

I just added two more ports:


port 3008:  Diff = 2
port 3007:  Diff = 7
Port 3005:  Diff = 5
Port 3032:  Diff = VarDiff (range:  1-10)
Port 3256:  Diff = 10

Ill remove the non corresponding ports later once we work the kinks out.

EDIT:  I see we also need to pass the correct nomp difficulty through to the client (it always says 1).  Ill add to todo.

Looks like this latest release was real solid! I ran one rig for over 12 hours and only a few bbp share rejects, also

Currently installed ubuntu etc on another rig and fiddling with activating 1 gb huge pages.
Then im gonna see how it works.

Looks like this latest release was real solid! I ran one rig for over 12 hours and only a few bbp share rejects, also

Currently installed ubuntu etc on another rig and fiddling with activating 1 gb huge pages.
Then im gonna see how it works.

Thats great!  Yeah, on an unrelated note, I probably spent 24 hours of my life doing some debugging that was unecessary.
I have been debugging xmrig in a virtual machine, and some of the changes I released were in response to believing I introduced a bug.
So just out of curiosity this morning I downloaded xmrig in the vm and ran it in debug mode and sure enough it crashed.  So the whole time Ive been dealing with something that is already part of the environment.  So basically I believe the way I need to summarize this is :  RandomX creates machine language in JIT for execution on various processors.  We cannot debug this in a vm 'normally'. 

This is pretty wild, so now I rebooted and Im testing the last version in windows again (this thing gave me so many false positives, I think after setting the MSR registers, the machine asked me to reboot, then the miner started dissapearing (silent exit) on my dev machine) - but as a strange coincinence (not related to something we added recently). 

Oh well anyway long story short it appears the GCC version is working on my windows dev machine now after a reboot, and its not exiting.

I guess I had some locked ram pages or something...

Ill try to burn this version in and confirm.

This morning I added the passthrough difficulty onto the users display.

Sounds nice! 

Yeah i was wondering before why only saw 1 difficulty  when changing bbp difficulty..

Pinning this for the future in case anyone else has this issue (a silent exit by the miner after a random amount of time, especially on ryzen 1700s):
https://www.reddit.com/r/MoneroMining/comments/e4k7cq/xmrig_ryzen_7_1700_fix/f9e676q/

So there is a workaround, (Im experiencing this myself), we can make a loop in a batch file like this (pretend this is miner5.bat):

:miningloop
xmrig.exe --params
goto miningloop

I will probably be doing this myself.

And just to give a little background on the problem, first of all there is a CPU setting on some motherboards called 'opcache' that might fix the underlying issue.
But the reason we aren't trying to handle this inside the program is since the JIT machine language is generated on the fly, the actual error signal is a segfault, but in a machine language area that can't have an error catch around it - and - segfaults cause program instability if you try to program around them.  Another words the only safe way to handle this is to let the process die and restart the process at the OS level.

Hopefully not many of our users will have to do this - but I appear to be one in this category with my early version of the 1700, etc. 

I havent tried the bios change yet but Ill post if it works later.

Please all, lets remember to test English, Russian and Ukraine during the next release:

https://forum.biblepay.org/index.php?topic=494.new#new

Just ensure the English behavior of the wallet is OK, for one (IE all menus are still captioned).  And if we have any Russian speaking testers, we can use your help testing Ukraine and Russian also.

Never mind, it looks like we will need a core wallet release anyway for a couple more reasons.

Ill try to get this ready within 24 hours.