Xmrig is a faster XMR miner in some use cases

Klee

Well-Known Member
Jun 2, 2016
1,292
395
83
I think the inconstancy i'm getting with xmring is because I am using dual cpu's systems.

This seems to be a issue with NUMA, the dev is supposed to fix it in the next update.

Anybody willing to try this on a high end single cpu machine that they are already running xmr-stak-cpu and post the results?


Xmring-nvidia is now my goto program for mining on Nvidia cards because it is much easier to install and config plus its faster than xmr-stak-nvidia.
 
  • Like
Reactions: pgh5278

jims2321

Active Member
Jul 7, 2013
184
44
28
I think the inconstancy i'm getting with xmring is because I am using dual cpu's systems.

This seems to be a issue with NUMA, the dev is supposed to fix it in the next update.

Anybody willing to try this on a high end single cpu machine that they are already running xmr-stak-cpu and post the results?


Xmring-nvidia is now my goto program for mining on Nvidia cards because it is much easier to install and config plus its faster than xmr-stak-nvidia.

Klee,

what you experiencing is typical of NUMA based systems. When enabled, all of the system memory space is visible and thus you have cpu processes crossing between memory spaces, that slows stuff down.. Here is a great write up on NUMA and multi cpu systems. We have to disable it for all of our db servers at work or we take upwards of 20% performance hit on our Dell's

NUMA, VNUMA and CPU Scheduling

By disabling it you limit what memory spaces are visible to the individual cpus thus eliminate that latency during remote memory access.

And a good starting point if you want to work on tuning your linux systems.

Performance Analysis - How to analyze and optimize Linux performance
 

Klee

Well-Known Member
Jun 2, 2016
1,292
395
83
Klee,

what you experiencing is typical of NUMA based systems. When enabled, all of the system memory space is visible and thus you have cpu processes crossing between memory spaces, that slows stuff down.. Here is a great write up on NUMA and multi cpu systems. We have to disable it for all of our db servers at work or we take upwards of 20% performance hit on our Dell's

NUMA, VNUMA and CPU Scheduling

By disabling it you limit what memory spaces are visible to the individual cpus thus eliminate that latency during remote memory access.

And a good starting point if you want to work on tuning your linux systems.

Performance Analysis - How to analyze and optimize Linux performance

I've only read a little about NUMA and have a basic understanding, I just have not dove in all the way yet.

Thanks for the links.
 

MiniKnight

Well-Known Member
Mar 30, 2012
3,001
911
113
NYC
@Klee I thought stak and wolf's let you set donation level to 0. xmrig does not.

I wanted to leave it on and have a true number at the pool without having donated shares - and I think 1% is too much
 

Klee

Well-Known Member
Jun 2, 2016
1,292
395
83
@Klee I thought stak and wolf's let you set donation level to 0. xmrig does not.

I wanted to leave it on and have a true number at the pool without having donated shares - and I think 1% is too much

You have to edit the donate.h file *before* you compile the program.

I have not done that, i'm ok with donating %1 to the dev for now.

From the donate.h file:

"/*
* Dev donation.
*
* Percentage of your hashing power that you want to donate to the developer, can be 0 if you don't want to do that.
* Example of how it works for the default setting of 1:
* You miner will mine into your usual pool for 99 minutes, then switch to the developer's pool for 1 minute.
* Switching is instant, and only happens after a successful connection, so you never loose any hashes.
*
* If you plan on changing this setting to 0 please consider making a one off donation to my wallet:
* XMR: 48edfHu7V9Z84YzzMa6fUueoELZ9ZRXq9VetWzYGzKt52XU5xvqgzYnDK9URnRoJMk1j8nLwEVsaSWJ4fhdUyZijBGUicoD
* BTC: 1P7ujsXeX7GxQwHNnJsRMgAdNkFZmNVqJT
*/
constexpr const int kDonateLevel = 5;


#endif /* __DONATE_H__ */"

Change the 5 to 0 then compile as usual.
 
Last edited:

Klee

Well-Known Member
Jun 2, 2016
1,292
395
83
Tweaked the config file a little. Peak is a little less but the average higher.

 

Klee

Well-Known Member
Jun 2, 2016
1,292
395
83
@Klee what's doing 4.3khps?

Changed xmrig from mining xmr to mining aeon on my Dual E5-2667 V3 ES main pc.

Super easy to do, all you have to do is edit the config file to use cryptonight-light and edit your mining pool info.

Of course after installing Aeon in order to install your simplewallet, then running aeond then let it download the blockchain thats less than 2 gigs then run simplewallet to get your wallet address to mine on a pool.

Aeon is only worth $2.50 each now and not nearly as popular as Monero but its based off Monero also it only has a simplewallet that lets you recieve and to sent you have go through a couple hoops to do it, but im holding not selling so thats ok.

So if you think of Monero being the "gold" anonymous cryptocoin think of Aeon as the "Silver" one.

I'm just playing around because Monero's difficulty is really starting to go up and i'm thinking of mining something else in a few months.

 
Last edited:
  • Like
Reactions: Marsh

Marsh

Moderator
May 12, 2013
2,368
1,201
113
Hardware: Asrock X99 WS board with E5-2673 v3 , all-core-turbo-bios , L3 is 30MB

xmr-stak-cpu produced 657 H/s

Seeing Partick's other thread about xmrig docker testing , xmrig dual instance: 1265H/s or 632 H/s for single CPU.

Hoping to see some improvement from xmr-stak-cpu to xmrig.
I am not seeing real improvement yet.

Any thoughts about my config.json
{
"algo": "cryptonight",
"av": 0,
"background": false,
"colors": true,
"cpu-affinity": null,
"cpu-priority": 5,
"donate-level": 1,
"log-file": null,
"max-cpu-usage": 100,
"print-time": 60,
"retries": 5,
"retry-pause": 5,
"safe": false,
"syslog": false,
"threads": 15,
"pools": [

* VERSIONS: XMRig/2.3.1 libuv/1.8.0 gcc/5.4.0
* HUGE PAGES: available, enabled
* CPU: Intel(R) Xeon(R) CPU E5-2673 v3 @ 2.40GHz (0) x64 AES-NI
* CPU L2/L3: 0.0 MB/0.0 MB
* THREADS: 15, cryptonight, av=1, donate=1%
* POOL #1: pool.minexmr.com:3333
* COMMANDS: hashrate, pause, resume
[2017-10-07 21:03:55] use pool pool.minexmr.com:3333 176.31.117.82
[2017-10-07 21:03:55] new job from pool.minexmr.com:3333 diff 200007
[2017-10-07 21:04:23] speed 2.5s/60s/15m 664.7 n/a n/a H/s max: 665.4 H/s
[2017-10-07 21:04:25] speed 2.5s/60s/15m 662.7 n/a n/a H/s max: 665.4 H/s
[2017-10-07 21:04:25] speed 2.5s/60s/15m 658.1 n/a n/a H/s max: 665.4 H/s
[2017-10-07 21:04:59] speed 2.5s/60s/15m 662.2 662.0 n/a H/s max: 665.4 H/s

Model name: Intel(R) Xeon(R) CPU E5-2673 v3 @ 2.40GHz
Stepping: 2
CPU MHz: 3099.937
CPU max MHz: 3100.0000
CPU min MHz: 1200.0000
 

Klee

Well-Known Member
Jun 2, 2016
1,292
395
83
Hardware: Asrock X99 WS board with E5-2673 v3 , all-core-turbo-bios , L3 is 30MB

xmr-stak-cpu produced 657 H/s

Seeing Partick's other thread about xmrig docker testing , xmrig dual instance: 1265H/s or 632 H/s for single CPU.

Hoping to see some improvement from xmr-stak-cpu to xmrig.
I am not seeing real improvement yet.

Any thoughts about my config.json
{
"algo": "cryptonight",
"av": 0,
"background": false,
"colors": true,
"cpu-affinity": null,
"cpu-priority": 5,
"donate-level": 1,
"log-file": null,
"max-cpu-usage": 100,
"print-time": 60,
"retries": 5,
"retry-pause": 5,
"safe": false,
"syslog": false,
"threads": 15,
"pools": [

* VERSIONS: XMRig/2.3.1 libuv/1.8.0 gcc/5.4.0
* HUGE PAGES: available, enabled
* CPU: Intel(R) Xeon(R) CPU E5-2673 v3 @ 2.40GHz (0) x64 AES-NI
* CPU L2/L3: 0.0 MB/0.0 MB
* THREADS: 15, cryptonight, av=1, donate=1%
* POOL #1: pool.minexmr.com:3333
* COMMANDS: hashrate, pause, resume
[2017-10-07 21:03:55] use pool pool.minexmr.com:3333 176.31.117.82
[2017-10-07 21:03:55] new job from pool.minexmr.com:3333 diff 200007
[2017-10-07 21:04:23] speed 2.5s/60s/15m 664.7 n/a n/a H/s max: 665.4 H/s
[2017-10-07 21:04:25] speed 2.5s/60s/15m 662.7 n/a n/a H/s max: 665.4 H/s
[2017-10-07 21:04:25] speed 2.5s/60s/15m 658.1 n/a n/a H/s max: 665.4 H/s
[2017-10-07 21:04:59] speed 2.5s/60s/15m 662.2 662.0 n/a H/s max: 665.4 H/s

Model name: Intel(R) Xeon(R) CPU E5-2673 v3 @ 2.40GHz
Stepping: 2
CPU MHz: 3099.937
CPU max MHz: 3100.0000
CPU min MHz: 1200.0000


"Xmrig is a faster XMR miner in some use cases" :p



 

Klee

Well-Known Member
Jun 2, 2016
1,292
395
83
Xmrig performance optimization is quirky at times especially when your dealing with numa nodes.

Mining Aeon the performance is inconsistent on dual cpu boards but its MUCH faster than aeon-stak-cpu.

On my dual 2667 V3 box mining aeon with aeon-stak with 32 threads I get ~2800 H/s with Xmrig I get ~4200 - 4500 H/s.
 

Marsh

Moderator
May 12, 2013
2,368
1,201
113
Seeing Partick's other thread about xmrig docker testing , xmrig dual instance: 1265H/s or 632 H/s for single CPU.
He increased hashrate from 58x H/s to 63x H/s without overclock the CPU.

When I "overclock" the CPU to achieve 657 H/s with xmr-stak, I was hoping to a similar bump like Patrick.

Last month, I tried xmrig , there was not much difference between xmr-stak and xmrig, therefore I went with overclock to bump hashrate up.

Patrick , I am not using docker version of xmrig.
 
  • Like
Reactions: Patrick

Patrick

Administrator
Staff member
Dec 21, 2010
12,113
5,133
113
@Marsh I think a major component is Wolf's to xmrig then splitting to one miner per NUMA node.
 

Klee

Well-Known Member
Jun 2, 2016
1,292
395
83
Update of xmrig for the soon to be Monero fork.

Xmrig 2.5.0 in Ubuntu 17.10 server, running the precompiled binary vs compiling it yourself.

Open Compute server w/ Dual E5-2665 v1 cpu's with 16 gigs of ram.

Binary:
~/monero-xmrig-2.5.0$ ./xmrig
* VERSIONS: XMRig/2.5.0 libuv/1.19.2 gcc/5.4.0
* HUGE PAGES: available, enabled
* CPU: Intel(R) Xeon(R) CPU E5-2665 0 @ 2.40GHz (2) x64 AES-NI
* CPU L2/L3: 8.0 MB/40.0 MB
* THREADS: 20, cryptonight, av=1, donate=1%
* POOL #1: xmr-usa.dwarfpool.com:8005

[2018-03-21 20:19:59] speed 2.5s/60s/15m 903.1 898.8 n/a H/s max: 903.1 H/s
[2018-03-21 20:20:14] speed 2.5s/60s/15m 901.2 898.9 n/a H/s max: 903.1 H/s
[2018-03-21 20:20:29] speed 2.5s/60s/15m 901.2 900.0 n/a H/s max: 903.1 H/s


Compiled on the Oc server:
~/xmrig/build$ ./xmrig
* VERSIONS: XMRig/2.5.0 libuv/1.9.1 gcc/7.2.0
* HUGE PAGES: available, enabled
* CPU: Intel(R) Xeon(R) CPU E5-2665 0 @ 2.40GHz (2) x64 AES-NI
* CPU L2/L3: 8.0 MB/40.0 MB
* THREADS: 20, cryptonight, av=1, donate=1%
* POOL #1: xmr-usa.dwarfpool.com:8005

[2018-03-21 20:18:03] speed 2.5s/60s/15m 901.1 901.2 n/a H/s max: 902.9 H/s
[2018-03-21 20:18:18] speed 2.5s/60s/15m 902.4 901.3 n/a H/s max: 902.9 H/s
[2018-03-21 20:18:20] speed 2.5s/60s/15m 902.4 901.3 n/a H/s max: 902.9 H/s
[2018-03-21 20:18:22] speed 2.5s/60s/15m 902.4 901.3 n/a H/s max: 902.9 H/s
[2018-03-21 20:18:22] speed 2.5s/60s/15m 902.4 901.4 n/a H/s max: 902.9 H/s

The precompiled binary is a tiny bit faster, I thought xmrig being compiled with a newer version of gcc would make it a little bit faster.

EDIT: I did zero tweaking and used the identical config.json file for both.
 

Patrick

Administrator
Staff member
Dec 21, 2010
12,113
5,133
113
@Klee It looks like the version you compiled is a bit faster over the minute if I am reading that right.