[JCE]Fast & stable CN/v8/Heavy/Tube/XHV miner, CPU+GPU, Vega56 1800+ RX580 1200+

[korm]

I explicitly benched my miner against Claymore 9.7, and i also explicitly said i couldn't beat it, by an order of magnitude. It can push my HD7850 1G to 450, i cannot go above 370 but yes, i'm still second, other miners are still worse. But i found jce a lot more stable than Claymore 11.3 and faster on cards with 2G+ memory.

On RX550 and RX560 jce should be the best if configured properly, which include waiting for 5-10 minutes after each start to let it warm up.
On RX460 2G use multi-hash 416, 432, 448 or 464, worksize 8, alpha 4 or 8, beta 64. On 4G, use same and multi_hash 464.

Otherwise try the 0.31e, the most stable so far, it takes ages to compile its opencl but may mine a bit faster than 0.32 in some cases.

It's true. Clay 9.7 knows the secret but no longer works on new algorithms. So now JCE it's the number one miner for old GPU (HD6870 on Clay - 290Hs, JCE - 260Hs (effectiv 240).
 { "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta":4, "index" : 0, "multi_hash":368 },


On RX 460 4G new SRB1.6.6 after 5-10m give 463Hs on each GPU. JCE stuck on 420-440 depending on the card (like old srb 1.30)
I also had that the cards gave out only half of the maximum speed. Noticed once
3*RX460
 { "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta":4, "index" : 0, "multi_hash":464 },
 { "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta":4, "index" : 0, "multi_hash":464 },
 { "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta":4, "index" : 1, "multi_hash":464 },
 { "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta":4, "index" : 1, "multi_hash":464 },
 { "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta":4, "index" : 2, "multi_hash":464 },
 { "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta":4, "index" : 2, "multi_hash":464 },

[1715022685]

1715022685

[1715022685]

1715022685

[1715022685]

1715022685

[1715022685]

1715022685

[1715022685]

1715022685

[JCE-Miner]

No nVidia mining sorry
Not yet

Dual mining with a non-memory intensive coin is a smart idea, but it would require lots of changes in my netcode which is completely bound to Cryptonight-style coin. Again, the first step would be the multi-pool netcode. I'm still working on it.

I pretend to be the fastest on :
* small RX550 and 560 (2G)
* Bittube on some GPU
* old HD6000/7000 if you consider claymore 9.7 as dead
* CPUs, in a more or less large scale depending on the cpu and algo (far beyond on non-aes, Turtle or Tube-v2, noticeably faster on v7 and heavy, close to other on CN-classic). And i provide exclusive features like no-cache mode or 6x multi-hash.
* ratio between displayed hashrate/real hashrate (98%, i benched Claymore 11 to rather ~92%, and got bad reports about others)

But not better at
* CN-heavy
* Vega FE
* large-mem RX

I'm working on 0.32k focused on hashrate consistency, with
* Watchdog
* Shorter warmup but then better re-sync in case:
** The warmup failed to reach 100% (in such case it will have high chances of success during the next minutes if you let it run)
** The GPU was paused or pool got disconnected

[Lermite]

I'm working on 0.32k focused on hashrate consistency, with
* Watchdog
* Shorter warmup but then better re-sync in case:
** The warmup failed to reach 100% (in such case it will have high chances of success during the next minutes if you let it run)
** The GPU was paused or pool got disconnected

Please do not forget to soften the anti-proxy heuristic feature to settle my connection issue

[JCE-Miner]

Sure
Again, JCE has protection against everything with is not a direct normal connection to internet :
* proxy
* vpn
* tunnel
* fake DNS
* fake WAN
* ...

[Lermite]

Sure
Again, JCE has protection against everything with is not a direct normal connection to internet :
* proxy
* vpn
* tunnel
* fake DNS
* fake WAN
* ...

This protection could be a problem to me within a few months.
I don't have and don't need a VPN now because my actual ISP does not work with HADOPI (the french anti-piracy establishment)
But my VDSL2 connection will be replaced by a FTTH one during 2019 or the early 2020 and it should come with another ISP that works with HADOPI, making me to need a VPN 24h/24 and as I mine with my main PC, my mining softwares will be affected by this VPN.

Perhaps you should offer to disable this protection through a parameter or to declare a legit VPN, with the suitable warnings about the dangers.

[whotheff]

No nVidia mining sorry
Not yet

Dual mining with a non-memory intensive coin is a smart idea, but it would require lots of changes in my netcode which is completely bound to Cryptonight-style coin. Again, the first step would be the multi-pool netcode. I'm still working on it.

I pretend to be the fastest on :
* small RX550 and 560 (2G)
* Bittube on some GPU
* old HD6000/7000 if you consider claymore 9.7 as dead
* CPUs, in a more or less large scale depending on the cpu and algo (far beyond on non-aes, Turtle or Tube-v2, noticeably faster on v7 and heavy, close to other on CN-classic). And i provide exclusive features like no-cache mode or 6x multi-hash.
* ratio between displayed hashrate/real hashrate (98%, i benched Claymore 11 to rather ~92%, and got bad reports about others)

But not better at
* CN-heavy
* Vega FE
* large-mem RX

I'm working on 0.32k focused on hashrate consistency, with
* Watchdog
* Shorter warmup but then better re-sync in case:
** The warmup failed to reach 100% (in such case it will have high chances of success during the next minutes if you let it run)
** The GPU was paused or pool got disconnected

I understand your focus. My question was if you can provide settings
for using JCE miner + Roi coin miner combo.

[lebuawu2]

No nVidia mining sorry
Not yet

Dual mining with a non-memory intensive coin is a smart idea, but it would require lots of changes in my netcode which is completely bound to Cryptonight-style coin. Again, the first step would be the multi-pool netcode. I'm still working on it.

I pretend to be the fastest on :
* small RX550 and 560 (2G)
* Bittube on some GPU
* old HD6000/7000 if you consider claymore 9.7 as dead
* CPUs, in a more or less large scale depending on the cpu and algo (far beyond on non-aes, Turtle or Tube-v2, noticeably faster on v7 and heavy, close to other on CN-classic). And i provide exclusive features like no-cache mode or 6x multi-hash.
* ratio between displayed hashrate/real hashrate (98%, i benched Claymore 11 to rather ~92%, and got bad reports about others)

But not better at
* CN-heavy
* Vega FE
* large-mem RX

I'm working on 0.32k focused on hashrate consistency, with
* Watchdog
* Shorter warmup but then better re-sync in case:
** The warmup failed to reach 100% (in such case it will have high chances of success during the next minutes if you let it run)
** The GPU was paused or pool got disconnected

rx 580 8gb cn-heavy is the best compare with other miner.
rx vega 56 cn-v7 is the best compare with other miner.

[1rV1N]

Hello
I use proxy XNP.
jCE version 32j
Count shares and hashrate don't equal in proxy and miner
How can you explain it?
http://prntscr.com/kozqvs

[JCE-Miner]

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)

I was also facing the same problem that time. This problem was due to my usb device (modem) which give internet access to my rig, when I remove that usb modem and connect the rig with my phone via USB than i saw a huge change in the mining performance.
My stale share which came down from 30% to almost 3%

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.

[1rV1N]

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

[JCE-Miner]

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

[1rV1N]

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

[JCE-Miner]

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.

[samvicky]

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

[JCE-Miner]

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

[samvicky]

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.

[JCE-Miner]

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

[Lermite]

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.

[samvicky]

 

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

[Lermite]

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

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.