FAQ

Frequently Asked Questions

How to configure CPU intensity for the Aeternity / Cuckaroo29 / Cuckatoo31 algorithm?

The Cuckoo-style algorithms (e.g., Aeternity, Cuckaroo29 and Cuckatoo31) require more CPU powers to solve. The computation power of the CPU instead of the number of cards might be the bottlneck of the performance. The problem is more evident on mining servers that have low-end CPUs.

if there is a symptom that Bminer constantly dies on your GPU or if you run multiple GPUs together but the average hashrate is lower than the hashrate when you test on just one GPU. then you should add -intensity 0.

The range of -intensity is between 0 and 12, you need some test to see what's the best intensity for your rig and test from 0.

To achieve the best performance on machines that have low-end GPUs, you can experiment with the value of the -intensity parameter. The lower the parameter is, the more workloads are shifted towards the GPUs.

How to specify special characters in the user and worker names?

Bminer uses URIs to identify both the user names and the mining pools. You can follow RFC 1738 to escape special characters (e.g., @, /) in the URI. This is useful when the mining pool requires you to specify email address as part of the username.

For example, the following command asks sparkpool to send email notifications to [email protected]:

bminer -uri cuckaroo29://foo%40gmail.com%2Fwoker:[email protected]:6666

Bminer won't start because Windows cannot find vcruntime140.dll.

This usually means the system needs a new version of Microsoft Visual C++. Please download it at Microsoft Visual C++ 2015 Redistributable.

Why does Windows Defender report Bminer as virus / malicious software?

Bminer uses DRM techniques to prevent itself to be tampered. Anti-virus softwares sometimes classify them as viruses because the techniques are used to obfuscate malicious software.

Bminer is not a piece of malicious software. You do have to add an exception in Windows Defender to use it. However, we strongly recommend to check the hash signatures when you download the releases to ensure the software has not been tampered.

Bminer crashed and it cannot be restarted until rebooting the machine.

The problem happens more often when there are hardware failures (e.g., loose cables, insufficient powers) during mining. It can be difficult for operating systems and drivers to recover from these cases. Therefore you will have to reboot the system or even press the Reset button instead of just restarting Bminer.

Why does Bminer take so long to get up to speed?

Bminer reports Exponentially Weighted Moving Average of the speed and takes the last couple minutes of the speed into account.

While the number of speed shown by bminer for the first few minutes is smaller, there is no differences on actual speed. The reported speed will converge to the real speed in several minutes.

Why the reported hashrate of Bminer is higher than the reported hashrate from mining pools?

Bminer reports hashrate generated by your hardware, while a mining pool estimates the hashrate based on the number of submitted shares. The Bminer hashrate is different from the pool hashrate because:

1. The Bminer reported hashrate includes the devfee.

2. A small portion of the generated shares may get rejected or become stale due to network delay and transmission problems. Bminer reported hashrate will include such shares, but such shares will not contribute to the pool estimated hashrate.

3. Your pool hashrate is an estimate based on received shares, therefore it will vary a lot unless you control a significant amount of hashpower and you run it over a long period of time.

4. Some pools may calculate the estimated hashrate incorrectly.

Specially, if you turn on nofee option. You will see the same number of hashrate but the underlying computation is slowed down due to disabled optimizations.

Why I see rejected shares when using Bminer?

There are many reasons for rejected shares. Two primary reasons for rejected shares are:

1. Network latency: If your latency to the connected pool is too long, then a valid share may become stale and invalid during the transmission. This will cause the share being rejected. The solution to this problem is to choose a pool server that has low latency connection to your rig.

2. Overclocking: Aggressive overclocking setting may cause GPU to produce incorrect results and therefore generates invalid shares being rejected.

Software bugs in Bminer may also cause a small portion of rejected shares. We will keep improving bminer and reduce the number of rejected shares.

Why Bminer starts private connections to bminer.me

The first communication checks the update and receives license information, including for example where to mine devfee. Note that in this communication bminer does not send out any information, it only receives information from bminer.me.

The follow-up communications only send runtime information of bminer, like the mining speed of each card and performance status. This may enable bminer to choose better optimization strategies. Starting from version 6.0.0, these follow-up communications will become transparent.

What’s fidelity？

Fidelity is a measure of the luck/miner correctness. I.e. assuming you have a good nonce how probable it is you will turn it into a solution(share).

Overtime, the number should be close to one. For miners running over two hours, the fidelity should be at least greater than 0.95.

How to adjust the CPU usage with the -intensity flag?

Both Aeternity / Grin requires significant CPU power to aid the mining. You might have sub-optimal performance if the machine is running on a low-end CPU (e.g. Intel Celeron) with multiple GPUs. Optionally, you can experiment the CPU usage with the -intensity flag:

bminer -uri cuckaroo29://bminergrin.worker:[email protected]:13654 -intensity 6

The intensity is between 0 and 12. Lower intensity has lower CPU usage but potentially slower on mining.