Need some Help - Bitcoin Mining - ASIC - tweaks

[Marco4613]

Hello All,

I hope you are doing well, I am in need of some assistance.

We are running a pool Solo for Bitcoin Mining, but everytime we connect a bunch of miners in excess of 20k we notice a bunch of rejected shares (duplicate & Job not found)

the rejected issue looks something like this for Job not found:

[2022-12-08 10:12:22.4439] [I] [pool-id-here] [workerid] Share rejected: job not found [cgminer/1.0.0]

and for duplicate share rejected similar:

[2022-12-08 10:12:22.4439] [I] [pool-id-here] [workerid] Share rejected: duplicate share [cgminer/1.0.0]

Duplicate share:
for a small amount of miners I can limit this issue by using static diff (essentially disabling vardiff) but increasing the amount of miners duplicate share rejected appears again.

If I have vardiff enabled:
When using vardiff with a small amount of miners, I have managed to limit it, but not fully getting to where I want it to be. When increasing the miners this again also starts flooding me with duplicate share rejected.

Job not found:
Cant seem to shake this bugger, by playing around with the config I manage to limit it, but increasing the amount of miners I am also again stuck with a lot of these.

The config is correct and structured in the way that its supposed to be.

With the above information, my questions would be the following:
1 - Is there a specific way that you can calculate the blockrefresh time and job rebroadcast time
Or is it just a matter of playing around and seeing what works and what does not?

2 - Is there a way to calculate vardiff variables that would be best?
Or is it also just a matter of playing around and seeing what works and what does not to see if we can decrease the duplicate share rejected issue when having that active?

3 - I have read that unix kernels can only support a certain amount of connections at the same time, would this be accurate and if it is, is this something that I can increase, and how do it increase it?

4 - Is there something else that I need to tweak in order to get the expected result, maybe in the BTC node itself?

5 - Is there a way to calculate the share difficulty that you need to use based on your amount of miners?

Would love to get some feedback, I think somewhere there is something that I need to change I am just not sure what thus the questions.

If anyone would be so kind if they are bitcoin mining as well on miningcore to share their config so that I can see where i can improve.

Have a wonderful day ya'll

Cheers

[jon4hz]

Hi,

While tinkering on whalesburg.com, we experienced some similar issues and I think I can give you some hints.
Obligatory disclaimer though, I'm still rather new in the mining field, so there might be some misconceptions. Please correct me if I'm wrong.

1. Not that I am aware of. It's mainly a combination of common sense and some testing.
   The jobRebroadcastTimeout isn't always needed. It's main purpose is to support miners which would consider the pool as "offline" if the pool doesn't send new jobs within X time.

2. Also no (If you figure something out, please let me know). From what I understand, the sharetime doesn't matter thaaaaat much on blockchains like bitcoin, where the blocktime is pretty high anyway. If you have a chain with a blocktime of 2sec for example, the sharetime should probably be lower than that value.
   A lower sharetime allows the pool to calculate a miners hashrate more accurate, but that also means that your shares table in the db will grow pretty fast, which can slow other parts of the pool down.

3. https://stackoverflow.com/questions/2332741/what-is-the-theoretical-maximum-number-of-open-tcp-connections-that-a-modern-lin

4. I never setup a bitcoin pool but miningcore has an option to get block templates over a ZMQ subscription. This might be a bit more efficient that polling.
   Also make sure to checkout the extra nonce provider for bitcoin, maybe that helps you to eliminate the duplicated shares issue.
   As for the "Job not found" error: if I get it right, this error appears, when the jobRebroadcastTimeout or blockRefreshInterval is too low, while the sharetime is too high. Miningcore tracks by default only 4 jobs per worker on bitcoin, so if the pool sends e.g. 5 new jobs while the miner is still working on job 1, you'll get the "job not found" message.

5. Imo it's more important to choose the difficulty based on the hashing power of a miner and not the amount of miners connected.