xmrig Monero Dwarfpool Image Testing
- Thread starter Patrick
- Start date
Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.
Blue in HTOP and what it means:
"There are two modes for CPU metrics reporting: the default one, and a "detailed CPU time" which can be enabled from the Setup screen (Display Options / Detailed CPU time). All of them show the percentage of time spent in different processes:
Default mode
So I stumbled upon a way to force xmrig threads to run in a low priority, which means that if the system needs resources for threads that are higher priority then the xmrig threads will be force to give up cpu cycles.
Which is GREAT for a desktop use because you can keep mining and not have the system so unresponsive, of course the hash rate takes a hit but only when your doing stuff.
It makes xmrig kind of like a background task so you don't have to make a choice to run or not to run xmrig.
In the config.json file:
You change this from:
"cpu-priority": null,
To this:
"cpu-priority": "0x",
Im not really sure how useful it is in most cases, but its worth a try to see if it work for you.
With xmrig running on all 32 cores, yes I have enought L3 for that, it was not the most responsive desktop it was not completely useless but changing it from null to 0x made it more responsive.
EDIT: This is on a dual Xeon system and I have not tried it on a single cpu system. So your results may be different.
Also it might be useful for a moderately used server with some spare cpu cycles so you can still use it as a server instead of just dedicated for mining only.
"There are two modes for CPU metrics reporting: the default one, and a "detailed CPU time" which can be enabled from the Setup screen (Display Options / Detailed CPU time). All of them show the percentage of time spent in different processes:
Default mode
- Blue: low priority processes (nice > 0)
- Green: normal (user) processes
- Red: kernel time (kernel, iowait, irqs...)
- Orange: virt time (steal time + guest time)"
So I stumbled upon a way to force xmrig threads to run in a low priority, which means that if the system needs resources for threads that are higher priority then the xmrig threads will be force to give up cpu cycles.
Which is GREAT for a desktop use because you can keep mining and not have the system so unresponsive, of course the hash rate takes a hit but only when your doing stuff.
It makes xmrig kind of like a background task so you don't have to make a choice to run or not to run xmrig.
In the config.json file:
You change this from:
"cpu-priority": null,
To this:
"cpu-priority": "0x",
Im not really sure how useful it is in most cases, but its worth a try to see if it work for you.
With xmrig running on all 32 cores, yes I have enought L3 for that, it was not the most responsive desktop it was not completely useless but changing it from null to 0x made it more responsive.
EDIT: This is on a dual Xeon system and I have not tried it on a single cpu system. So your results may be different.
Also it might be useful for a moderately used server with some spare cpu cycles so you can still use it as a server instead of just dedicated for mining only.
Last edited:
I've noticed the same thing, but it seems to average out fairly closely over time.
using 2x stak for each socket 2x E5-2699 V4 2100H/s
using cores 0-21, 44,45,46
and 22-43,66,67,68
dual xmr-stack again here 1710H/s
and i'm using two processes only because xmr-stak has limitation to 32 cores with nicehash...
will try that trick soon also on Epyc.7551
regards
A
drop me an info what You want to test
i've got also some interesting observations on dual mining with aeon on purley's
regards
A
I have attempted to run the image on the BSMC, which runs a Docker swarm that I manage using Portainer, yet when I look at the status of individual nodes in the swarm, it appears the service runs for a short period of time, then it "completes". I am running a local registry, but this is highly unlikely to be the cause of the problem, as I have used it successfully to host Wolf's mining image in the past.
I note from @Patrick's first post that hugepages need to be enabled on the host. To do this, I have modified /etc/default/grub to include the line:
GRUB_CMDLINE_LINUX_DEFAULT="transparent_hugepage=always"
then run "update_grub". After a reboot, running the command:
$ cat /sys/kernel/mm/transparent_hugepage/enabled
returns
[always] madvise never
Is there another step that I have missed out?
Edit: Reading the config.txt file of xmr-stak.cpu I note that there is a section that explains how to modify /etc/security/limits.conf to configure large page support. Is there a similar procedure for xmrig? Not sure if the fact that xmrig is being run in a Docker container changes things or not...
I note from @Patrick's first post that hugepages need to be enabled on the host. To do this, I have modified /etc/default/grub to include the line:
GRUB_CMDLINE_LINUX_DEFAULT="transparent_hugepage=always"
then run "update_grub". After a reboot, running the command:
$ cat /sys/kernel/mm/transparent_hugepage/enabled
returns
[always] madvise never
Is there another step that I have missed out?
Edit: Reading the config.txt file of xmr-stak.cpu I note that there is a section that explains how to modify /etc/security/limits.conf to configure large page support. Is there a similar procedure for xmrig? Not sure if the fact that xmrig is being run in a Docker container changes things or not...
Last edited:
Log file attached. I am not quite sure what I am looking for, but there does not seem to be anything amiss that I can see. After piping the Docker log to a file however, there was one more entry that appeared on the command line:
./xmrig: unsupported non-option argument '20'
Which I daresay refers to the optional argument 'numthreads' I passed, along with 'startport'. Creating a service that uses nothing but the required wallet address and no optional arguments acts the same however - the container runs for a very short period of time, then is listed as complete. Rinse, repeat...
./xmrig: unsupported non-option argument '20'
Which I daresay refers to the optional argument 'numthreads' I passed, along with 'startport'. Creating a service that uses nothing but the required wallet address and no optional arguments acts the same however - the container runs for a very short period of time, then is listed as complete. Rinse, repeat...
That would be pretty hilarious. I pulled the image per your first post in this thread @Patrick:
docker pull servethehome/monero_dwarfpool:xmrig
Which, incidentally, is not listed on your official repository page. I might be suffering from caffeine-induced brain-melt here of course....
docker pull servethehome/monero_dwarfpool:xmrig
Which, incidentally, is not listed on your official repository page. I might be suffering from caffeine-induced brain-melt here of course....