Topic: [XMR] JCE Miner Cryptonight/forks, now with GPU! - page 59. (Read 90841 times)

On my RX560 i had a few more h/s on V7 with the k but the consensus is that it's worse, so i do a k2 version with 1rv1n and Lermite fixes but with j OpenCL. I'll look back at the perf later.

0.32k2 online, with exact same OpenCL as the j

Mostly I mine cryptonight-lite v7 coins. My rig is pretty much stable.
This what I get after some over clocking.
21:07:06 | Hashrate CPU Thread 1: 150.02 h/s
21:07:06 | Hashrate CPU Thread 2: 152.76 h/s
21:07:06 | Hashrate CPU Thread 3: 152.82 h/s
21:07:06 | Hashrate CPU Thread 4: 144.86 h/s
21:07:06 | Hashrate CPU Thread 5: 149.35 h/s
21:07:06 | Hashrate CPU Thread 6: 152.20 h/s
21:07:06 | Hashrate CPU Thread 7: 152.64 h/s
21:07:06 | Hashrate CPU Thread 8: 146.10 h/s
21:07:06 | Hashrate CPU Thread 9: 150.32 h/s
21:07:06 | Hashrate CPU Thread 10: 153.36 h/s
21:07:06 | Hashrate CPU Thread 11: 153.38 h/s
21:07:06 | Hashrate CPU Thread 12: 141.62 h/s
21:07:06 | Hashrate CPU Thread 13: 145.26 h/s
21:07:06 | Hashrate CPU Thread 14: 148.97 h/s
21:07:06 | Hashrate CPU Thread 15: 148.18 h/s - Total CPUs: 2383.81 h/s
21:07:06 | Hashrate GPU Thread 16: 518.56 h/s
21:07:06 | Hashrate GPU Thread 17: 501.73 h/s - Total GPU 0: 1020.29 h/s
21:07:06 | Hashrate GPU Thread 18: 505.52 h/s
21:07:06 | Hashrate GPU Thread 19: 503.67 h/s - Total GPU 1: 1009.18 h/s
21:07:06 | Hashrate GPU Thread 20: 508.02 h/s
21:07:06 | Hashrate GPU Thread 21: 520.21 h/s - Total GPU 2: 1028.23 h/s
21:07:06 | Hashrate GPU Thread 22: 2152.51 h/s
21:07:06 | Hashrate GPU Thread 23: 2165.15 h/s - Total GPU 3: 4317.66 h/s
21:07:06 | Total: 9759.15 h/s - Max: 9775.47 h/s

Same here on three RX5.
Raising the multi-hash by 16 only worsen the hashrates or crashed the GPU.
Decreasing it by 16 didn't improve them. They remained unstable and lower than the 0.31f's.

For me it sucks on CN7. Vega 64 rig dropped from 14800 to 14100. that is like 5% less I went back to 0.32j version.

It's working great ,currently doing 4295 hs.

thanks

Is the (new) 0.32k working well on Vega?
I know there may be perf regression between 0.31f and the 0.32 since all code is new, but I cannot go back to the ultra-long compiling version 0.31

Try to re-configure the multi-hash values, 0.32 tend to prefer slightly bigger values (+16 or +32)

I just asked to confirm that.So, that I could recommend your miner to my friends.

exactly, if you have only GPU configured, you pay only the gpu fee 0.9% and this is true for all JCE-GPU versions from the very first.
But if you have a CPU configured and then you pause it, you will still pay for the CPU mining.

fees are logged at startup, if you read "CPU devfee" so you pay them, if you read "GPU devfee" so you pay them, if you read both, so you pay an average between both.

The bug increasing the fee only happens if the CPU if configured to mine but then it is disabled one the fly.
It does not occurs if the CPU is excluded in the configuration.

 

My latest hashrate:

17:54:33 | Hashrate CPU Thread 0: 138.63 h/s
17:54:33 | Hashrate CPU Thread 1: 142.75 h/s
17:54:33 | Hashrate CPU Thread 2: 144.52 h/s
17:54:33 | Hashrate CPU Thread 3: 144.88 h/s
17:54:33 | Hashrate CPU Thread 4: 140.62 h/s
17:54:33 | Hashrate CPU Thread 5: 143.10 h/s
17:54:33 | Hashrate CPU Thread 6: 144.52 h/s
17:54:33 | Hashrate CPU Thread 7: 144.17 h/s
17:54:33 | Hashrate CPU Thread 8: 143.46 h/s
17:54:33 | Hashrate CPU Thread 9: 144.52 h/s
17:54:33 | Hashrate CPU Thread 10: 144.52 h/s
17:54:33 | Hashrate CPU Thread 11: 145.57 h/s
17:54:33 | Hashrate CPU Thread 12: 131.95 h/s
17:54:33 | Hashrate CPU Thread 13: 137.83 h/s
17:54:33 | Hashrate CPU Thread 14: 142.75 h/s
17:54:33 | Hashrate CPU Thread 15: 144.17 h/s - Total CPUs: 2277.91 h/s
17:54:33 | Hashrate GPU Thread 16: 543.70 h/s
17:54:33 | Hashrate GPU Thread 17: 474.41 h/s - Total GPU 0: 1018.10 h/s
17:54:33 | Hashrate GPU Thread 18: 503.67 h/s
17:54:33 | Hashrate GPU Thread 19: 497.62 h/s - Total GPU 1: 1001.29 h/s
17:54:33 | Hashrate GPU Thread 20: 497.62 h/s
17:54:33 | Hashrate GPU Thread 21: 516.10 h/s - Total GPU 2: 1013.72 h/s
17:54:33 | Hashrate GPU Thread 22: 2150.64 h/s
17:54:33 | Hashrate GPU Thread 23: 2159.47 h/s - Total GPU 3: 4310.10 h/s
17:54:33 | Total: 9621.10 h/s - Max: 9621.10 h/s

About the fees , if I mine only my gpus then I still pay "the devfee for cpu" or only the "devfee for gpu"....? That fee bit is confusing

My connection issue is gone thank to the 0.32k.

But my hashrates became pretty unstable, with lower average values than the perfectly stables ones of the 0.31f.

0.31f > 0.32k on CN V7
RX570 8G Micron: 965 > ~941 h/s
RX570 4G Samsung: 1036 > ~1003 h/s

The bug about the fee with a disabled device such the CPU is annoying because I'm used to often disable my CPU for several hours to encode some videos.
Now, I'll remember not to disable anything anymore. I'll stop and restart the miner to change the mining devices.

thanks, i re-uploaded the 0.32k
this is a very dirty way to work, but i want to release the fixed version asap. I updated the documentation too about the mixed fees, to says explicitly the fees depend on the devices you enable, not the devices that mine (so a paused CPU will still increase the fee ratio if mixed with GPUs).

Awesome 0.32j gave the highest hashrate to me.my rig contains Ryzen 7 1800x , 1 x vega 64 and 3 x rx 550 2gb.


17:41:41 | Hashrate CPU Thread 0: 134.71 h/s
17:41:41 | Hashrate CPU Thread 1: 141.31 h/s
17:41:41 | Hashrate CPU Thread 2: 143.62 h/s
17:41:41 | Hashrate CPU Thread 3: 143.98 h/s
17:41:41 | Hashrate CPU Thread 4: 139.50 h/s
17:41:41 | Hashrate CPU Thread 5: 142.05 h/s
17:41:41 | Hashrate CPU Thread 6: 143.18 h/s
17:41:41 | Hashrate CPU Thread 7: 143.60 h/s
17:41:41 | Hashrate CPU Thread 8: 142.13 h/s
17:41:41 | Hashrate CPU Thread 9: 143.98 h/s
17:41:41 | Hashrate CPU Thread 10: 144.34 h/s
17:41:41 | Hashrate CPU Thread 11: 145.53 h/s
17:41:41 | Hashrate CPU Thread 12: 126.34 h/s
17:41:41 | Hashrate CPU Thread 13: 135.98 h/s
17:41:41 | Hashrate CPU Thread 14: 142.13 h/s
17:41:41 | Hashrate CPU Thread 15: 143.98 h/s - Total CPUs: 2256.30 h/s
17:41:41 | Hashrate GPU Thread 16: 513.72 h/s
17:41:41 | Hashrate GPU Thread 17: 491.82 h/s - Total GPU 0: 1005.53 h/s
17:41:41 | Hashrate GPU Thread 18: 502.17 h/s
17:41:41 | Hashrate GPU Thread 19: 508.17 h/s - Total GPU 1: 1010.33 h/s
17:41:41 | Hashrate GPU Thread 20: 484.70 h/s
17:41:41 | Hashrate GPU Thread 21: 511.31 h/s - Total GPU 2: 996.00 h/s
17:41:41 | Hashrate GPU Thread 22: 2141.50 h/s
17:41:41 | Hashrate GPU Thread 23: 2165.25 h/s - Total GPU 3: 4306.74 h/s
17:41:41 | Total: 9574.89 h/s - Max: 10751.17 h/s

Even srb miner fails to get 4300+ hs in my vega 64. Mostly it gets 4050.

Your are really awesome.

thanks for fast reply. I'll re-release it with previous opencl, better i focus on fixes and speed separately

Vega 64 is only hashing 225 hs in cryptonight lite v7. And rx 550 2gb hashrate decreased little bit in the latest 0.32k

It's somehow good you did those proxy tests, i don't always use mine when i do my test, to be in real-life condition, and even when I do, i check for netcode correctness, not for the displayed numbers, which are cosmetical. And i never tried your mix of GPU + paused CPUs.

About it, I will not fix it completely, because there are tons of cases, all being corner cases:
* cpu paused during fee session
* or unpaused
* or paused then unpaused, possibly several times
* some but not all gpu paused, or all, or unpaused, or both, possibly several times...

Each case would require a recompute of fee level on the fly, a lot of code for corner cases. A rig is supposed to mine with all its configured devices.
So i fix the stuck session, but one who start JCE with cpu+gpu and then pause the cpu will still pay for the cpu mining service, even if unused. I rewrite the message "CPU Devfee" into "Devfee for CPU" to be more explicit. I will also update the doc to say to use --no-cpu to disable the cpu, and not pause it forever. It would also make JCE start faster and allocate less memory.

Next version will have:
* Yellow share counter fixed (cosmetical fix)
* stuck fee session skipped for paused-forever devices
* relaxed netcode security for Lermite
* faster JCE start sequence
* reworked a bit the OpenCL
* No watchdog yet (postponed)

edit:

0.32k online

I included a primitive, undocumented and mostly untested watchdog: --watchdog to quit if a non-paused GPU thread is stuck. And --watchdog N to quit if total GPU (ignoring CPU) hashrate goes below N h/s, except if a GPU is paused, or the pool disconnected.

@1rV1N : if you redo your test with version 0.32k, you should get a perfect one-for-one match between the yellow hashrate and your proxy. And no change pool side, since the fixes were cosmetical. Don't forget to add --no-cpu, or let your CPU really mine.

Good to hear it.
I will be wait next release.
Good Job!

Ok, I didn't notice you used a proxy (which is not supported officialy, but alas)
so what I said about pool is true, but does not explain your problem.

I rechecked my netcode and found the problem, and that's a corner bug: you have a CPU (or several) configured but with no mining enabled. It caused the CPU devfee to be stuck (because the devfee sessions could never finish with a paused CPU) and so you were running with the GPU at 0.9% fee plus the CPU fee stuck, which caused the total counter to increase (including the illegitimate fees) with a higher than normal fee level.
Retry your test with --no-cpu param and the 4% difference should be lowered to ~1%

That's an unplanned behavior that i never though about, and it's somehow luck that not the whole mining was stuck at fee (I had a similar bug in earlier versions where all shares of user pool were sent to fee pool, causing a ban for me and a zero gain for user, of course it has been fixed immediately).

While it's a corner bug (i don't think a lot of people mine with a paused useless CPU) it's still a bad bug since the CPU fee should have no impact on the GPU, and a paused device (cpu or GPU) should giveup the fee instead of waiting forever to finish.
The idea was to prevent to do the opposite: start JCE with GPU+CPU to have a lower average fee then pause the GPU and mine with the CPU. Obviously you did the opposite and it caused higher fee.

I postpone release of 0.32k until I fix it.

edit: since i reworked the yellow report for version 0.32h and j, i need to check also that the accepted fees are not in the net hashrate (in such case, it wouldn't be net). The netness of the yellow hashrate has changed between 0.32f, 0.32h and 0.32j (you can see the h tells Average and the j tells Net). If there's a regression, it would be only cosmetical, but still in need to be checked.

All in all, if you avoid your bug of the paused CPU, you should get a 0.9% difference on the long term, measured with a proxy (to count stale shares), a proof the fee level is not fake. But sure of all possible combinations of CPU/GPU/Pause i missed one.

edit: i just re-tested with a proxy too (a custom one I use to test my netcode) and I confirm:
* the gpu-only fee level is well 0.9% with a randomization (Claymore-style), good
* the gpu+cpu is well weighted averaged between 3% and 0.9% depending on your config, good
* the gpu+paused cpu cause the fees to be added and not averaged once all the CPU are paused for longer than its fee session) corner bug
* but the so-called Net i display in the 0.32j is still the Average as in the 0.32h (the test to distinguish the shares was present but wrong). cosmetical bug

I have 50 ms to Proxy and pool 10 ms to pool  I think it is excellent
Proxy counts stale share. Also pool counts share if share is late less than 4 sec.
And as you can see JCE has only Accepted shares

Hello,

I can: stale shares.

First, the shares and the effective hashrate are related (the rate is the shares divided by the uptime). So if you have a 4% difference on one, you'll get a 4% diff on the other.

You can get a documentation here:
https://bitcoin.stackexchange.com/questions/1416/what-are-stale-shares-and-what-can-i-do-to-avoid-them

let's quote that guy, who had a big problem (not using JCE)

After fix it dropped to 3%, you're at 4%, you can see that number is normal, yet a bit high, i admit.

Stale shares are caused by ping and pool (and miner) netcode aggressivity, and happens when a share is found while the pool was changing the job (and sometimes, the difficulty on the fly). The shorter the pool jobs are, and the higher your ping is, the more Stale you'll get.

Most pools, and in fact, almost all but NiceHash, report stale shares as Accepted not to make the miners afraid. But the share is then still dropped. JCE cannot distinguish between them and will report them as Accepted, but when it doubts, it logs may be refused by the pool. I guess you got lots of those warning, followed by Accepted. The thuth is that 4% of them were not really accepted.

In doubt, try this test: mine with a open-source software with the fees recompiled to zero (like Stak), so you can be sure that 100% of yout hashing power goes to your pool. Compare the displayed GPU hashrate and the pool hashrate. It should be 4% different.

Do not compare the Stak reported share counter against the pool counter. Why? because each miner has a different netcode that may choose to send more or less potential stale shares. A very convervative miner will have less stale shares but also a very lower pool hashrate. JCE is a medium/high aggressive miner, I send most the of the potentially stale shares, but not all. Except on Nicehash where i send no suspicious share, because it always refuse them.
If i remember well, Stak was very conservative and Claymore medium aggressive. SRB is convervative by default but can be configured to be ultra-aggressive.
I tuned my netcode to what i expect to be the optimal aggressiveness.