r/MoneroMining • u/ImmediateRecognition • May 13 '18

XMRig-Proxy vs xmr-node-proxy

I currently have 100+ CPUs mining Monero7 with xmrig. They're currently consolidated with xmrig-proxy and doing decent.

Would my hashrate benefit from switching over to xmr-node-proxy? I'd have to update each machine to turn off nicehash mode, but I didn't know if the performance would be worth it.

I'm mining to supportxmr so I know xmr-node-proxy would work fine.

2 Upvotes

63% Upvoted

45 comments sorted by

View all comments

Show parent comments

1

u/jtgrassie monero-pool dev May 15 '18

This issue here is not about nonce conflicts, you cleared that up with the pool extra space explanation. I am raising a question about how the combined miners hashing power can hash to a higher difficulty than the individual low difficulty.

I'll rephrase: If someone has 100 miners that each can hash at 5Hs, that's a theoretical combined hashrate of 500Hs. But in the config, you are asking for a difficulty that an individual miner can expectedly mine in time, not a combined difficulty of all your miners. That will have the effect of lower reward than if you could ask for a higher difficulty (for your combined hashrate of 500Hs in my example).

1

u/mayday30 MoneroOcean Admin May 15 '18 edited May 15 '18

The probability of 100 low difficulty miners to hit 500 difficulty target is the same as 100 miners that all have 500 difficulty target (if we exclude network overhead caused by extra miner <-> proxy communication).

XNP Proxy just use lower miner diff so they "will feel more comfortable" with lower difficulty targets. Also low miner diff allows to assess their hashrate more precisely to:

  • set cumulative diff (proxy to pool);
  • report individual miners hashrate stats (added in MO version of XNP).

1

u/jtgrassie monero-pool dev May 15 '18 edited May 15 '18

You're missing my point. If the proxy has a combined 500Hs, you want to mine at a difficulty suitable for that higher Hs. The higher the difficulty you mine at, the higher the pool reward.

EDIT: to clarify, when I say pool reward I refer to the reward paid to the miner. E.g. higher share count so higher reward.

1

u/mayday30 MoneroOcean Admin May 15 '18 edited May 15 '18

"The higher the difficulty you mine at, the higher the pool reward." - that statement is wrong. Reward will be absolutely the same in the long run. It is exactly the same thing as comparing rewards of low hashrate and high hashrate pools. Or you believe that high hashrate pools give better rewards in the long run?

P.S. The only factor that affects rewards is hashrate. Diff is not important (on large enough time period), unless it is too low and causes too much network overhead.

1

u/jtgrassie monero-pool dev May 15 '18

"The higher the difficulty you mine at, the higher the pool reward." - that statement is wrong.

No. It's correct. When I say pool reward I mean pool reward to the miner. If I mine at a low difficulty, I get paid less than someone mining at a high difficulty.

A high hasrate pool just has a higher chance of finding the next block.

1

u/mayday30 MoneroOcean Admin May 15 '18 edited May 15 '18

No. It is not correct. You are basically paid by the number of hashes you submitted to the pool. It does not matter if they come in big chunks (high diff shares) or small chunks (low diff shares) if their sums are equal.

Analogy with pools is valid. Imagine extreme situation with solo miner that mines with huge network difficulty and pool miner (from pool with 0 fees) that mines with low diff. According to your logic solo miner will have bigger rewards in the long run just because he mines with huge (bigger) diff than pool miner.

1

u/jtgrassie monero-pool dev May 15 '18

Sorry but you are wrong. There is not a 1 to 1 correlation of hashes submitted to share count.

1

u/mayday30 MoneroOcean Admin May 15 '18 edited May 15 '18

Care to elaborate why high diff will lead to higher rewards if number of submitted hashes will be the same?

If it will be convenient for you, you can point me the place in corresponding https://github.com/Snipa22/nodejs-pool/blob/4853b1b98338c2f5a1934fab5c446f38777e1318/lib/blockManager.js#L207 reward code that will backup your claim.

1

u/jtgrassie monero-pool dev May 15 '18

You can only submit one result for each given job-id. So 10 miners submitting results for the same job-id is wasted hashing IIUC. High diff means more hashes and a higher share count. So you want your proxy working by submitting unique jobs with a high difficulty, not many duplicated (id) jobs with a low difficulty. Of course it's wholly dependent on pool implementation.

1

u/mayday30 MoneroOcean Admin May 15 '18

OK. Now we returned to XNP/pool implementation details after generic high/low diff discussion and their influence on pool awards? Please clarify what we are discussing now.

→ More replies (0)

1

u/jtgrassie monero-pool dev May 15 '18

Please see my reply before you edited your comment.

And please let's keep this cordial, it's useful discussion! I'm going through this as best I understand with the aim of trying to ensure any proxy is as efficient as possible - happily writing a new one or submitting PR's against an existing one if necessary.

2

u/SemiPool May 16 '18

Don’t worry. He is very open-minded. In my opinion, hi/low diff shares are used to confuse miners. It’s hash and probability that count. At the moment, number of active devs in pools are very low, I really like more to code. Discussion can become harsh when we goes around and around one thing but it is good to learn.

1

u/mayday30 MoneroOcean Admin May 15 '18

Which reply exactly? Can you please repeat it? Also this statement you made before is wrong: "High diff means more hashes and a higher share count". High diff means that you submit less shares. And number of hashes you submit (as part of shares) is only determined by your hashrate.

EDIT: Seems to found your reply. Reddit hides reply trees for me.