Added support for Yada (rx/yada algorithm)#2411
Conversation
|
This is some kind of testnet? network hashrate is below 10 kH/s. |
@xmrig However, for this PR, is there any additional information you need from us? Test command: Getting about 2.5 kH/s |
0196618 to
d6aa2d4
Compare
|
We fixed our hashrate reporting issue. Our network hashrate is now properly reported. |
|
I can add my vote for this - I'm currently mining Yada, network hash rate is good, and listed on SafeTrade/ |
d6aa2d4 to
148b920
Compare
|
Yadacoin is nothing like a "testnet"... the hashrate is fine and it's one of the VERY RARE projects with a REAL usecase that solves a REAL problem using a very SMART way. Definitely deserves being merged. |
|
Wow, rx/yada in GPU's version of xmrig? I saw this only in XmrigCC, but it's for CPU: Bendr0id#343 I see this pull-request have a some unresolved conflicts, |
Yadacoin uses rx/yada for about two years. Is supported by XmrigCC and SRB. What is needed to add its support to Xmrig? |
148b920 to
238ef1a
Compare
|
@xmrig Very simple merge. Already being used in another fork of xmrig. Think we can move forward? |
|
|
|
Wow! I see conflicts was been resolved, in this pull-request. |
|
@username1565 I have implemented everything required for CUDA and OpenCL. I'll provide a screenshot when I'm able to test. If someone else is able to test either of those in the meantime, I would appreciate it. |
|
@pdxwebdev Please rebase on |
|
@pdxwebdev Consult my branch |
|
@pdxwebdev Also check over in my xmrig-cuda/pdx-addRXYADA where I wired up maybe-working other half of the CUDA support UPDATE: seems to work I guess, difficulty far too high for ~335H/s to catch an accept as validation... |
|
@Spudz76 Awesome! Thanks for doing that. It may not be getting an accepted share because the RandomX Yada configuration modifications for CUDA / OpenCL. Do these variables need to be set elsewhere? |
|
I set those in the CUDA plugin side, should be valid if I happened to find a share above the diff. I didn't have CPU enabled the combination of the two should find something but doesn't exactly prove out the CUDA (accepts would likely be just from cpu) If there were any pools with selectable diff or autodiff it would help. GPUs just won't crank much hash with rx/anything. Testing the OpenCL next... |
|
OpenCL seems to work; although same as CUDA the diff is too high to catch a validation accept (or reject). Diff would need to be ~9150 to see something. 69905 is good for ~2330H/s |
|
@Spudz76 Let's make the following modification. And then use this pool: 18.214.218.185:3333 |
|
Yes that pool is nice diff, now I can see CUDA doesn't actually work yet (compute error always, when a result should occur) |
|
Same deal with OpenCL. hmmmm. CPU does work, still. Tried all with or without that m_target patch. |
|
@Spudz76 I can get it working if I drop the pool diff to 1. What appears to be happening is: CheckHash is immediately called after a hash is calculated CheckHash compares the hash to the target. It sees that the hash is above the target so it logs a compute error. Shouldn't it simply throw out the hash and keep trying to find a hash that is less than the target instead of logging an error? |
|
Interesting, and what I suspected. The GPU backend thinks it found a result above target or it wouldn't have sent it up to be rechecked. But it wasn't actually above target. Or it was and the verification is incorrect... I get almost no compute errors when the diff is gigantic, because no results are found. I think the results are valid but the verification is wrong. |
|
@Spudz76 I agree, and I also checked the hashes being received by the pool. They are valid. |
4a5960d to
2d40ded
Compare
This contradicts direct feedback from my mining community. They are actually telling me to dump RandomX and go with GR. Clearly, it is still a concern and influences their decision on where to allocate their hashrate. However, that is immaterial. The point is that we have followed the documented instructions to modify the RX config for our project, and it would take little effort on your part to review and merge our code. |
Ok, so it's about money; that's fine. However, my main contention is that our emission would be substantially higher if we were added to this repo. We've had countless miners come and go because they would have to change 50+ rigs to accommodate a new XMRig fork. If you want an upfront "listing fee," just name your price. I'm sure we could gather the funds to get this across the finish line. |
|
There's no listing fee, we don't do that. |
Ok, how about this. Merge us and give us 6 months. In the meantime, we can supplement any fees related to the support of our coin should it fall short of the break-even point. If we cannot demonstrate any growth in that time period, simply remove us along with KevaCoin. |
|
@pdxwebdev We considered giving you a chance. Please update this PR or make a new one without changing |
4f51034 to
4badf2c
Compare
4badf2c to
7897f10
Compare
fb8f48b to
ecef382
Compare
|
@xmrig @SChernykh The changes are in, tested, and ready for your review. |
|
@pdxwebdev The |
No problem, we just released support for xmrig 6 a few minutes ago. Please test pool.yadacoin.io again and the target will be correct. 
|
|
@pdxwebdev Any chance of poking TradeOgre again, to list this? |
I'll submit a listing request. |
|
@pdxwebdev pool.yadacoin.io doesn't send
|
@SChernykh , I just released a fix. "algo": "rx/yada" is now sent with new jobs. 
|
|
@Spudz76 we just got listed on TradeOgre! |
Hello, YadaCoin would like to be added to the master branch of xmrig.