Social media

Investigating monero mining on a notebook

Author: LB 2021-04-30 1806

The growing adoption of cryptocurrencies has triggered new directions in software development and the cryptocurrency community is constantly working on optimizing mining tools. Monero with its mind blowing 7.3 billion market capitalization has become a cryptocurrency of interest in recent years. The mining of Monero is mainly performed on CPUs, and this makes the currency very attractive to less experienced miners too. In the following few lines I’m going to shed light upon the subtleties of Monero mining to find out the optimal number of threads on a commodity laptop shipped with an Intel(R) Core(TM) i5-8265U CPU.

XMRIG is one of the most popular mining softwares utilized by cryptocurrency miners to mine Monero and I’m going to use this tool in the current guide. Its source code can be downloaded from Github and compiling xmrig consists of the following steps:

$ sudo apt-get install git build-essential cmake libuv1-dev libssl-dev libhwloc-dev
$ git clone
$ mkdir xmrig/build && cd xmrig/build
$ cmake ..
$ make -j$(nproc)

As soon as we have an xmrig executable ready in the directory, we can start mining monero by setting our wallet address and a mining pool address in the configuration file. A config.ini sample can be found under ./src.

This time, I wanted to find out the most optimal configuration to mine Monero on my notebook with an Intel(R) Core(TM) i5-8265U CPU. In order to find out some information about my CPU I used the following command:

$ lscpu

And I got the following output:

Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
Address sizes: 39 bits physical, 48 bits virtual
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 2
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 142
Model name: Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz
Stepping: 12
CPU MHz: 800.201
CPU max MHz: 3900,0000
CPU min MHz: 400,0000
BogoMIPS: 3600.00
Virtualization: VT-x
L1d cache: 128 KiB
L1i cache: 128 KiB
L2 cache: 1 MiB
L3 cache: 6 MiB

We can see that the processor has one socket, 4 cores and it supports two threads on a single core. So virtually there are 8 cores in my notebook and I tried to set the number of threads for monero mining to 8. This can be achieved by extending the following line:

"rx/0": [0],

To get this:

"rx/0": [0, 1, 2, 3, 4, 5, 6, 7],

By doing so, my hashrate was around 1085.6 Hs/s, but I had no idea whether this is an ideal setup or not. So the next step was to measure the hashrate with respect to the number of threads and I got the following graph:

Hashrate vs. number of threads

Clearly, the optimal hashrate is not where the number of threads equals 8. The hashrate seems to grow linearly from 1 thread to 4 threads and then it deteriorates significantly.

I was wondering why this all happens, and having done some research on the Internet, I found that the hashrate is influenced by the size of the L3 cache and the DDR RAM’s speed as well. If you don’t want to meticulously analyze your hardware, you can set the number of threads to be equal to the number of physical cores you have for monero mining, because the mining process itself is not too memory heavy, so you wouldn’t get much speed up by making use of the fact that multithreading on a physical core can increase efficiency by letting one thread progress some data while the other one is working on data transfer to and from the memory. So in my case, as you can see from the lscpu output, the optimal number of threads would be 4 and increasing the number of threads over 4 would not result in any speed up, it would rather lower the performance.

The inefficiencies of multithreading can be measured by creating statistics on the cache-miss events. Whenever the CPU doesn’t find something in its cache it has to reference the system memory and this takes time. If the number of these events grow, performance brakes down. In order to make this easier to comprehend, I used perf to find out the number of cache-miss events for a certain number of threads, based on an idea I found in the following scientific article: Detecting Covert Cryptomining using HPC. The command I was using for 4 threads to profile xmrig is the following:

$ sudo perf stat -e cache-misses -a -I 1000 -o thread_4 -x, ./xmrig

This recorded the number of cache-miss events in an output file in every second and I did the same thing for 1-8 threads. This is the result I got:

Monero mining with xmrig and cache-miss events

The trend is clear from the graph. The number of cache-miss events stays the same if we change the number of threads from 1 to 2. It increases slightly if we change the number of threads to 3.

If we increase the number of threads, the number of cache-miss events grows significantly and this is the reason for the degrading mining performance. On one hand it’s true that mining in parallel should increase the hashrate in theory. On the other hand though, if there are two many concurrent threads trying to work on data that doesn’t exist in the CPU cache, they end up referring to the system memory very frequently instead of doing meaningful calculation. That’s why the hashrate saturates in my case in the vicinity of 4 threads.

If you really want to optimize your monero miner, you have to consider at least two things. One is the number of physical cores you have in your mining rig and the second thing is the size of the L3 cache in your CPUs. If you have many physical cores, but your L3 caches are small, your hasrate will be low even if you are allocating one single thread for each core. You might have to do a short benchmark on your system, or refer to the benchmarks on the official mining site:

Have fun with mining monero! Reach out on Whatsapp (+36 30 8316972) if you want to know more on cryptos.

Interesting entries


Best GPUs to mine ethereum in 2022


Dual mining ethereum and toncoin on RTX 3060Ti and RTX 3070Ti LHR


Profiling the RTX 3060 Ti and its memory transfer rate


Core clock settings for RTX 3060 Ti when mining Ethereum


Core clock settings for RTX 3070 Ti Founders Edition when mining ethereum