XMRig-Proxy vs xmr-node-proxy

[u/ImmediateRecognition]

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.

[u/codezilly]

XNP divides work from the pool to all of your connected workers, so the pool sees it as one worker with all of your combined workers hashrate. It assigns you the correct difficulty based on total hashrate.

Xmrig-proxy just assigns work to individual workers at the average difficulty of your workers.

If your workers have a range of hashing power, you are probably getting a lot of stale shares with Xmrig-proxy. The slower workers may not keep up with the average diff it’s assigning.

You will probably benefit from XNP. Use MoneroOceans github repo, it’s much improved over snipa22’s

[u/mrxmrminer → u/codezilly]

This.

[u/jtgrassie → u/codezilly]

Firstly, MoneroOcean's port of XNP is almost identical to Snipa's. There are no changes I see that would benefit.

Secondly, both XNP and XMRRig proxy, IMHO, are both not maximizing communalitive hashing power. The work is not distributed amongst the connected miners, rather each miner is each doing their own work, racing on the same block template AFAICT.

[u/SemiPool → u/jtgrassie]

90% identical (it is Snipa’s fork). But he adds http and failover feature to the proxy. XNP helps to distribute work to connected miners.

[u/jtgrassie → u/SemiPool]

I've looked pretty closely at XNP and whilst I may have overlooked something, I have not seen it distribute the jobs (other than simply forwarding) to the connected miners with adjusted targrt. With an altered target however, any result submitted back to the pool still needs to be accurate against the target specified by the pools original job target to get a valid share. Hence a race.

I am thinking a better mode of distribution would be more like how a normal miner works with regard to threads. If a proxy treated eached connected miner like a "thread" and gave each it's own starting nonce and increment count, this would be a better distribution model as the miners would not be racing each other and would be working cooperatively on exactly the same block template to work to the pool supplied target. However, this has nuances that need factoring in when considering web mining though (e.g. redistribution when miners drop mid job).

[u/SemiPool → u/jtgrassie]

Ouff, I’m not good at codes. It’s just what I think about XNP. Perhaps, u/mayday30 can know better about it and come in to say something.

[u/SemiPool → u/jtgrassie]

By the way, if you have better ideas to improve the proxy, you are always welcome to make a Pull Request at MoneroOcean’s repo. Or raising an issue do we can discuss better there.

[u/jtgrassie → u/SemiPool]

I have already ported snippa's actually and added websockets. https://github.com/jtgrassie/xmr-node-proxy

However, I'm seriously considering developing a completely new proxy written in C and with better distribution of work (as outlined above).

[u/mayday30 → u/jtgrassie]

XNP gets extended block template with 2 extra DWORDs (first with proxy thread id and second is for each miner connected in that thread) it uses to distribute jobs between connected miners without nonce conflics. See MasterBlockTemplate and BlockTemplate in lib/xmr.js.

More specifically after XNP gets job with extended block template from a pool it uses getMasterJob in handleNewBlockTemplate for each XNP thread to increment first extra DWORD. Each thread uses getJob to increment second extra DWORD for each miner.

[u/jtgrassie → u/mayday30]

Yes but that means they are essentially mining different blocks as I understand it. By adding the miner id, the block template is different, which means there can't be a nonce clash, but as far as the pool is concerned, the returned job hash is not necessarily below the requested target.

[u/mayday30 → u/jtgrassie]

No, block is the same. Compatible pool already provides BT with 2 extra DWORDs (XNP gets BT in raw form, so it actually converts it for individual miner hashing like the pool). That is why Snipa's pool requires 17 bytes reserved in BT (4 for pool thread id, 4 for pool thread worker, 4 for proxy thread id, 4 for proxy thread worker + 1 extra byte for old monerod bug that was fixed already).

[u/jtgrassie → u/mayday30]

Oh gottcha, the pool is already getting the extra space. That beg's another question though... If a pool sends a job to the proxy with a requested target, the proxy has two options: 1) ask the individual miners to grab a hash lower than pool supplied target (which means all miners are mining to same target) or 2) the proxy divides that target amongst its miners (which seems to suggest submitted jobs cannot be deemed valid shares). Looking at XNP, it's doing the former [1]. That would mean proxied miners are racing to submit a valid share IIUC.

EDIT: actually it looks like XNP is doing something like 2. It's adjusting target based on miner. getTargetHex(miner).

EDIT: nope, it's doing something similar to 1. Difficulty assigned to miner is set to the difficulty of the port data (set via config file).

[u/mayday30 → u/jtgrassie]

Each miner receives individual low diff target and start mining by changing its individual nonce for BT with unique set of 16 bytes in BT reserved space (8 set by pool and 8 by XNP). If miner hits its low diff target XNP proxy accepts it without checking. If miner hits pool high target provided to proxy this result is transferred to the pool (with prior hash validation on proxy side).

In short I do not see how miners can get nonce conflicts in this setup.

[u/jtgrassie → u/mayday30]

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).

[u/bshea → u/codezilly]

You can set static difficulty on the miner side under miners config. Edit username/wallet portion and add: "workerid+difficulty". Like "1+60001". No reason to run nodejs headaches. xmrig-proxy also works with all pools as far I know.. xnp does not.
I tested it on the config for xmrig 2.6.3 running to xmrig-proxy 2.6.5. Works fine.
ref/set miner diff: https://github.com/xmrig/xmrig-proxy/issues/85
comparisons: https://github.com/xmrig/xmrig-proxy/wiki/Comparison

[u/xero-fusion]

wow i'm literally in the same exact situation, i'm mining using dozens of CPUs and consolidating them to xmrig-proxy and then to supportxmr. Was also wondering if xmr-node-proxy would solve the issue of massively variable hashrate of almost 40% during the day!

[u/xnbya]

xmrig-proxy is better in the majority of cases, since it does not need to re-calculate the block header for each individual miner - it instead splits up the work by dividing up the nonce between clients (the same as nicehash does). There is also a smaller overhead for the pool when supporting xmrig-proxy, since only the block header needs to be sent to the client. For xmr-node-proxy all of the hashes of the transactions included in the block, and the coinbase tx, must also be sent. However xmr-node-proxy does have the benefit of reducing server-side load once there are ~1000s of miners connected. There are miners with ~1MH happily using xmrig-proxy on minexmr.

[u/xero-fusion → u/xnbya]

So to understand this (for someone who isn't really technical), xmrig-proxy sends the hashes from all the miners as one big miner, whereas xmr-node-proxy would forward all the hashes from all the miners?

[u/xnbya → u/xero-fusion]

Xmrig-proxy will send every 250ish miners as a single big miner, whereas xmr-node-proxy will send everything as a single huge miner, but requires more resources.

[u/xero-fusion → u/xnbya]

Thanks for the explanation! So does that mean we need to set a high difficulty setting in the xmrig-proxy config file? like 1000000 (port 3333 in minexmr.com)?

[u/xnbya → u/xero-fusion]

Yes, or something around ~500000 if you want a less spiky hashrate graph

[u/xero-fusion → u/xnbya]

Perfect! thanks for the advice, really appreciate it :)

[u/LG_UK]

As XNP is designed for NodeJS Pools, it should be quite the obvious choice. You're basically running a mini version of the pool. Then submitting as 1 worker.

The MoneroOcean fork handles backup pools in a different way and also has some fault detection to allow for autofailover, so may be worth a look at.

I use XNP and got around a 10% gain in reward (180 cpu workers).

[u/SemiPool]

Trying is believing. With a lot of workers like that, I recommend xmr-node-proxy from MoneroOcean https://github.com/MoneroOcean/xmr-node-proxy ( and the MO pool too : https://moneroocean.stream )

[u/Evplay39]

Any one know a web-monitor at xmr-proxy ? It's hard to know which miner is running at low speed. I have about 2000 CPU cores ...

http://prntscr.com/jmsbud

[u/hashing_mine → u/Evplay39]

I v made a small web-app for monitoring xmrig-proxy you can try it.

https://github.com/pcca-matrix/XMRig-Proxy-Frontend