Nicehash high pool rejection rate

[climbing-panda]

Description

Using the latest version to run a small pool. A few people use Nicehash under a single worker, so sometimes the worker has 50 ~ 100 times hash power than a real miner. They got high pool rejection rate (10 ~ 20%) from Nicehash's connection report.

I'm planning to set up a dedicated port for Nicehash connections. In such case, what would be the good values for parameters like:

• "blockRefreshInterval": 1000,
• "jobRebroadcastTimeout": 60,
• "clientConnectionTimeout": 600,
• "varDiff": { "minDiff": 1, "targetTime": 15, "retargetTime": 30, "variancePercent": 30 }

Any suggestions or thoughts would be appreciated.

[calebcall]

Couple things I've noticed that seems to help/cause this is the further from your stratum the connection is, the higher the rejection rate. So if you can setup additional stratums geolocated, it should help. I've moved everything over to using zeromq so the blockRefreshInterval gets set to 0. Having a port for the higher difficulty helps as well, on their tester, they fail your connection if the initial diff is less than 100.

[fathusband]

I found this link from nicehash, I think this might be useful for you.

https://www.nicehash.com/pool-operators

[seperatis]

@climbing-panda According to NiceHash the problem usually comes from the Difficulty, (Diff, VarDiff, MinDiff) not being set correctly. You are correct in that you will have to use a seperate port for NiceHash. I have setup a DGB-scrypt pool in a similar setup. I've used port 3333 for miners in general then a dedicated port (3334) for hash power rentals. This setup works well for DGB, you will probably have to play around with the minDiff depending on what coin you're doing. Here is my config for DGB-Scrypt:

PS - Be sure to make use of NiceHash's "Test Connection" feature also to make sure there are no errors there.

}, "ports": { "3333": { "listenAddress": "0.0.0.0", "difficulty": 1024.0, "varDiff": { "minDiff": 512.0, "targetTime": 15.0, "retargetTime": 90.0, "variancePercent": 30.0 }, "tls": false }, "3334": { "listenAddress": "0.0.0.0", "difficulty": 1000000.0, "varDiff": { "minDiff": 1000000.0, "targetTime": 15.0, "retargetTime": 90.0, "variancePercent": 30.0 }, "tls": false }

[calebcall]

Mine's setup that exact same way. For most algos, I have a normal port and a high difficulty port.

[climbing-panda]

@calebcall @fathusband @seperatis I've set up a high difficulty port that does reduce the rejection rate for NiceHash. Thanks guys!

Now I notice the log has many "Share rejected: low difficulty share" warnings.

After reviewing the code in BitcoinJob.cs (ProcessShareInternal), I'm thinking if it's because NiceHash 'redirects' many physical miners to the pool under the same worker, and Miningcore thinks it's dealing with one miner only, so Miningcore may increase difficulty based on the faster miners, but then rejects the low-diff shares from the slower miners?

[seperatis]

@climbing-panda the high difficulty port is going to reject "low shares", that's the point of having it.

This is why you have a normal port and a high Difficulty port.

A typical NiceHash rental has incredibly more power than say a single Antminer S9, so it needs a higher diff setting to recieve harder work from the pool. If it gets any low "easy work" it'll reject shares b/c it's been set to look for "harder work".

Yes, I believe nice hash turns all your rentals into a single stratum connection.

This is my understanding of how it works, if I've made any mistake someone feel free to jump in and correct me.

A last though: you will probably have some rejected /weird shares when miners first join as the pools VarDiff feature is trying to do its job by adjusting the difficulty based on your setting in config. After some time the variance in diff of the work it's sending to your miners will begin to stabilize. I'd be most concerned about rejected/bad shares during this "stabilized period" rather than bad share count by y itself. Also keep in mind, rejected shares are normal part of a running pool. The danger is when they get higher than they should be, or abnormal to say.

[climbing-panda]

@seperatis Thanks Seperatis.

I examined the miningcore log, and found when the hash power is high, nicehash runs multiple stratum connections under the same worker.

@oliverw From my quick look into the code in BitcoinJob.cs (ProcessShareInternal), difficulty seems to be adjusted by worker, not by stratum connection? If that's the case, miningcore may be confused by multiple stratum connections under the same worker, e.g. after connection A is adjusted to high diff, connection B comes in with the previous diff, therefore is rejected as too low diff?

[oliverw]

@climbing-panda No, the worker-name is purely used for statistics. Difficulty is adjusted on a per-connection basis.

[calebcall]

That’s easily tested, just get two miners using the same address and no worker name, you’ll see each one’s difficulty is still adjusted independently.

[climbing-panda]

@oliverw @calebcall Thanks guys!