-
Notifications
You must be signed in to change notification settings - Fork 338
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mining algorithm negotiation #168
Comments
For cn-heavy variant, i believe it should support it with only variant 0 (or -1) at the moment. It allows evolutions. |
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. |
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 |
I mean pool/proxy could impose variant when sending the job. |
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. |
Good proposal. I will support it in MO pool and MO xmr-node-proxy. |
Woohoo, this is awesome. |
@NicNull Yup, but this would be handled on the miner side. Theoretically... |
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 Keep up the good work. p.s. Personally I don't see the point in having two parameters |
I don't change |
All the |
I added |
@xmrig I stand corrected ... I worked too much with non-cryptonote protocols, where |
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 |
@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 |
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.
|
@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. |
Is there any plan to finish the last item on this list:
This feature would be very helpful for me, and would allow us to close this issue. |
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
The text was updated successfully, but these errors were encountered: