search

xmrig / xmrig-proxy

Monero (XMR) Stratum protocol proxy
https://xmrig.com/proxy
GNU General Public License v3.0
605 stars 330 forks source link

Mining algorithm negotiation #168

Open xmrig opened 6 years ago

xmrig commented 6 years ago

I have plan to extend stratum protocol to make possible algorithm negotiation between miner and pool/proxy. Current working draft. Any feedback welcome.

Checklist

Wave 1

Wave 2

Wave 3

el00ruobuob commented 6 years ago

For cn-heavy variant, i believe it should support it with only variant 0 (or -1) at the moment. It allows evolutions.

el00ruobuob commented 6 years ago

And why the proxy shouldn't send the variant? It could tell the miner which one to use. IMO it's up to the job requester to choose it.

xmrig commented 6 years ago

Your are right about cn-heavy, I changed docs to better clarify this moment.

Variant=-1 same as missing variant, works fine for Monero and Aeon, all miners will detect proper variant from block version, manual variant required only for coins where used non standard block header version, sad but other coins authors don't like to change version to 7 to make it work without variant.

Miner never request job from pool, pool always send job, it completely up to pool. In protocol has method getjob, but miners not use it and no useful reason to use it, also I found this method is buggy. Thank you.

el00ruobuob commented 6 years ago

I mean pool/proxy could impose variant when sending the job.

mpkogli commented 6 years ago

I agree that pool should be able to "suggest" the algorithm to the miner via the proxy. Perhaps this will require re-jiggering on the miner side, but would help with the current algo war.

MoneroOcean commented 6 years ago

Good proposal. I will support it in MO pool and MO xmr-node-proxy.

NicNull commented 6 years ago

Woohoo, this is awesome. How about handling of the different GPU configuration for optimal performance when going from cn to cn-heavy or cn-lite? cn-heavy require lower "intensity" settings even to start on same GPU compared to cn or cn-lite. If GPU need to be adjusted to lowest working denominator then a lot of H/s is lost on cn.

mpkogli commented 6 years ago

@NicNull Yup, but this would be handled on the miner side. Theoretically...

aleqx commented 6 years ago

I support this. Also, let's forget about pools for now (I also don't think they will ever support this extension).

I also agree with @NicNull -- triggering a change of the algo is pointless if you can't trigger a reconfig of the GPU parameters (threads, blocks). All miners would crash if you co from cn-lite to cn-heavy without reducing threads (not enough memory).

This extension could be massively helpful: many of us have multiple miners. It's much, much easier and time effective to change the settings only in the proxy without touching the miners. It's even more awesome that we don't have to stop the proxy either since the new xmrig-proxy versions autodetect config file changes and reload it. I would love to be able to switch between any coin by changing only the xmrig-proxy config (right now I can only switch variants).

The set of algos and variants in the xmrig-proxy should match those supported by xmrig, and the config for both should be identical so that folks can easily use them.

I don't think it matters too much how you do it in json-rpc, because I don't think any pool will ever implement this extension.

However, it would be of interest to make the extension compatible with current imeplementations,so that xmrig-proxy can be used with other miners too, and not just xmrig (e.g. xmr-stak). I see you changed params from an array to an object ... that would break compatibility. Why not keep it as an array but add 3 values at the end, regardless of the length of params:[]. I'd make the last value in params always equal to "xmrig-proxy-ext.v1" (or some other identifier for the protocol extension), and then the next to last and next next to last values equal to the algo name and variant number.

Keep up the good work.

p.s. Personally I don't see the point in having two parameters algo and variant when there could be just one ... the Cryptonight landscape is getting out of hand.

xmrig commented 6 years ago

I don't change params from an array to an object, in stratum protocol always used an object. All changes compatible with exists miners including xmr-stak.

aleqx commented 6 years ago

All the params I see on https://github.com/xmrig/xmrig-proxy/blob/dev/doc/STRATUM_EXT.md#mining-algorithm-negotiation are objects params:{} instead of arrays params:[] ... but maybe I'm missing something.

xmrig commented 6 years ago

I added cryptonight-ipbc to specification. @aleqx params:{} it correct and current protocol, all extensions is backward compatible with all exists miners.

aleqx commented 6 years ago

@xmrig I stand corrected ... I worked too much with non-cryptonote protocols, where params is an array, not an object. Stratum implementations are an absolute jungle ...

armin884 commented 6 years ago

I'm mining haven (cn-heavy) with xmrig-proxy/2.5.3 and miner is XMRig/2.6.0-beta3 . How do i get auto algorithm negotiation working? If i don't specify algo on miner with -a cryptonight-heavy it always uses cryptonight and i get Low difficulty share error

aleqx commented 6 years ago

@xmrig does master for xmrig-proxy and xmrig-nvidia now support changing both algo and variant? Concretely, if I connect xmrig miners to xmrig-proxy, and I change both the algo and variant in the xmrig-proxy config, will those be pushed to the miner as well (i.e. I don't have to restart miners with a different config)?

What about pushing different threads, blocks, bfactor, bsleep parameters from xmrig-proxy to xmrig to avoid restarting xmrig with different configs?

mpkogli commented 6 years ago

@xmrig I'm wondering the same thing as @aleqx. How do GPU configurations figure into the mix? Does any miner support automatically changing GPU threads/blocks/intensity without restarting the miner? Thanks!

desynenugroho commented 6 years ago

Dikirim dari iPhone Nugroho Wiharjo

Pada 19 Apr 2018, pukul 00.18, Kogs notifications@github.com menulis:

@NicNull Yup, but this would be handled on the miner side. Theoretically...

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

hesido commented 5 years ago

@aleqx Algo details should be abstracted totally on the miner side, for full extensibility and inter-operability. A coin switching miner that advertises itself as such should let you define configuration -per- algo, right on the miner side. Even if extensibility and interoperability is not something you want, there are too many intricacies to optimizing a miner, with mixed GPU's, driver differences and a myriad other stuff that only relates to miner configuration, so pushing those details from the proxy is not a feasible idea.

The miner does not even need to employ run-time switching, if it's not able to switch without a restart, it can still restart upon receiving that workload, and restart GPU's using configuration for that algo. All it would do would be to close connection and re-connect to the proxy with the proper config, the result is the same, although with added latency.

A run-time switch would be sweet though, but it is not in the proxy's interest to know how it will be handled, some miners may switch between variants without restart, some may want to restart miner, and even provide the users with a --restartbatchfile option that may apply different OC settings, for the ultimate hands-off optimized approach to different algo coin switching. The proxy may just signal that miner the new algo, and the rest would be up to the miner (and disconnecting / reconnecting is not a big deal)

I am also assuming, the miner would advertise the active algo as the first algo in the algo array, I'm not sure if this is mentioned in spec but it's common sense to declare it at index 0, so the proxy would send the appropriate work upon first contact.

unsocial-bleach commented 2 years ago

Is there any plan to finish the last item on this list:

Multi algorithm mode in proxy (router).

This feature would be very helpful for me, and would allow us to close this issue.