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

[UnclWish]

Why on CPU heavy algo is twice lower than V7? On GPU's it's use more vmem but speed is the same or higher...

[Iamtutut]

Why on CPU heavy algo is twice lower than V7? On GPU's it's use more vmem but speed is the same or higher...

May be it uses twice the cache.

[JCE-Miner]

because on CPU cryptonight is latency limited.
it means the performance key is all in the cache. since CN Heavy requires twice the cache, you can compute twice less. the compute itself is also slightly slower, but not that much. it makes a Division, which is a bit slow, nothing more. its round does two memory access instead of one, but it makes half of them.

on gpu latency is bad because we do a lot of random access to glogal vram. a gpu can take a whole second to make a cryptonight round. so cache is negligible, and Heavy impact is very low too

you can see that with the no-cache mode of JCE which is slow as hell (often 3 h/s) but not really slower on Heavy than v7.


about gpu, i'm now working on releasing the gpu version of jce. maybe i'll release a last cpu-only then next will be gpu+cpu.
i'll still provide a cpu-only for those who don't have any opencl gpu.

[UnclWish]

because on CPU cryptonight is latency limited.
it means the performance key is all in the cache. since CN Heavy requires twice the cache, you can compute twice less. the compute itself is also slightly slower, but not that much. it makes a Division, which is a bit slow, nothing more. its round does two memory access instead of one, but it makes half of them.

on gpu latency is bad because we do a lot of random access to glogal vram. a gpu can take a whole second to make a cryptonight round. so cache is negligible, and Heavy impact is very low too

you can see that with the no-cache mode of JCE which is slow as hell (often 3 h/s) but not really slower on Heavy than v7.


about gpu, i'm now working on releasing the gpu version of jce. maybe i'll release a last cpu-only then next will be gpu+cpu.
i'll still provide a cpu-only for those who don't have any opencl gpu.

It's good news about gpu-version. I'll wait them. Claymore drops dev of CN miner. GGS is in development. SRB-miner is not stable still. Hope your miner will be good!

[nordmann666]

because on CPU cryptonight is latency limited.
it means the performance key is all in the cache. since CN Heavy requires twice the cache, you can compute twice less. the compute itself is also slightly slower, but not that much. it makes a Division, which is a bit slow, nothing more. its round does two memory access instead of one, but it makes half of them.

on gpu latency is bad because we do a lot of random access to glogal vram. a gpu can take a whole second to make a cryptonight round. so cache is negligible, and Heavy impact is very low too

you can see that with the no-cache mode of JCE which is slow as hell (often 3 h/s) but not really slower on Heavy than v7.


about gpu, i'm now working on releasing the gpu version of jce. maybe i'll release a last cpu-only then next will be gpu+cpu.
i'll still provide a cpu-only for those who don't have any opencl gpu.

great news!

[fishdogduck]

Is it possible to get this to work for the Electroneum May 30th fork? I tried using --variation 3 but it's getting rejected by the pool.

[JCE-Miner]

Not yet, i'm focusing at polishing the GPU version, but yeah i'll release a last CPU version with than new fork. Will be variation 11.

To answer your question: No you cannot yet, it's just not implemented yet.
edit : i looked at code, and it seems to be just like Monero v7, let me check more. In such case, nothing to change (except my documentation)
re-edit: Electronero is a slightly modified variation compared to CN-v7 so i still need an update, but it will be an esay one, and backward compatible. Said differently, the Electronero algo will be compatible with Monero, but the opposite is false.

Teaser of GPU version, I'll keep the same principles as for the CPU version:
* at least as fast as Stak/XMrig in worst case, often better[1]
* a lot of exclusive tuning option
* detailled info about what the miner does (allocations of GPU memory, kernel compile...)
* complete cleanup of OpenCL resource at close (like for the Large pages for CPU)
* Instant hashrate, not the max of last few seconds like Claymore (cough.. cheater... cough...)
* So the pool-side hashrate will be displayed hashrate, minus fees, not 10% lower like claymore 10+ [2]
* Targetting at correctness and reliability, no memory access hacks that produce bad hashes
* As a consequence, no CPU re-check[3], if you find a bad share, it will still be sent to your pool
* of course it will be an hybrid miner, able to mine CPU + GPU (or just CPU, or just GPU) on the same pool connection.

[1] It comes at the cost of huge optimizations on the fly, so JCE GPU will take ages to start, and then mine faster. You're warned.

[2] : I loved Claymore 9.7, a masterpiece, then came 10 and 11 that, on all my rigs, produce tons of bad shares and has a 10% lower effective hashrate that what it displays. That's what motivated me to start JCE GPU at the beginning.
Stak and XMRig are decent, both are copies of Wolf0, like Zawawa btw, but both the code and OpenCL contains goofs that made me laugh, so i just rewrote everything, and kept it close source, i won't do the same error than Wolf0 to open source just to see the fees go to copy-paste morons.

[3] That's what Claymore 9.7 did and i go this way : make a miner that just works, and doesn't need re-hash, instead of a broken one + fallback security.

[fishdogduck]

Thanks for the quick reply.

Looking forward to seeing how to GPU miner turns out also.

[JCE-Miner]

i didn't plan that, but i'll release an intermediate version ASAP, with :

* The front end of the GPU version, which will say for example "CPU Thread" instead of just "Thread" because it expects to have some GPU, and some new features like the --probe parameter to get a list of mining devices (CPU and GPU).
* I fix Electronemero
* I want to fix that bug: https://github.com/jceminer/cn_cpu_miner/issues/7 because i got this complain several times.
* But the GPU part will not be present yet.

[Iamtutut]

Not yet, i'm focusing at polishing the GPU version, but yeah i'll release a last CPU version with than new fork. Will be variation 11.

To answer your question: No you cannot yet, it's just not implemented yet.
edit : i looked at code, and it seems to be just like Monero v7, let me check more. In such case, nothing to change (except my documentation)
re-edit: Electronero is a slightly modified variation compared to CN-v7 so i still need an update, but it will be an esay one, and backward compatible. Said differently, the Electronero algo will be compatible with Monero, but the opposite is false.

Teaser of GPU version, I'll keep the same principles as for the CPU version:
* at least as fast as Stak/XMrig in worst case, often better[1]
* a lot of exclusive tuning option
* detailled info about what the miner does (allocations of GPU memory, kernel compile...)
* complete cleanup of OpenCL resource at close (like for the Large pages for CPU)
* Instant hashrate, not the max of last few seconds like Claymore (cough.. cheater... cough...)
* So the pool-side hashrate will be displayed hashrate, minus fees, not 10% lower like claymore 10+ [2]
* Targetting at correctness and reliability, no memory access hacks that produce bad hashes
* As a consequence, no CPU re-check[3], if you find a bad share, it will still be sent to your pool
* of course it will be an hybrid miner, able to mine CPU + GPU (or just CPU, or just GPU) on the same pool connection.

[1] It comes at the cost of huge optimizations on the fly, so JCE GPU will take ages to start, and then mine faster. You're warned.

[2] : I loved Claymore 9.7, a masterpiece, then came 10 and 11 that, on all my rigs, produce tons of bad shares and has a 10% lower effective hashrate that what it displays. That's what motivated me to start JCE GPU at the beginning.
Stak and XMRig are decent, both are copies of Wolf0, like Zawawa btw, but both the code and OpenCL contains goofs that made me laugh, so i just rewrote everything, and kept it close source, i won't do the same error than Wolf0 to open source just to see the fees go to copy-paste morons.

[3] That's what Claymore 9.7 did and i go this way : make a miner that just works, and doesn't need re-hash, instead of a broken one + fallback security.

Right now, the best CN GPU miner is "SRB". Better than XMRig, better than cast XMR, better than claymore.

[JCE-Miner]

Cast is a masterpiece on Vega.

I found SRB to be very like Claymore, but more stable. Btw it's a very good miner, and not a rip of Wolf0.
I know i'll face other very good gpu miners, including some with no fees, that's the game.

The 0.29b is on the way, supporting new ETN, but i tested it very little.

Better handling of long pause time
Sending SIGINT to the parent JCE process forwards it to the child ghost "attrib" (for 3rd party automation)
New coin: Saronite
ETN defaults to CN-v7-ETN (which is backward compatible with CN-v7)
Italo defaults to Heavy

[UnclWish]

Please, make on GPU version video memory usage indicator to user know how much vmemory he allready used for mining.

[Iamtutut]

On Vega it seems SRB gives (CN V7) 2K-2.05K with 56 (64 bios), up to 2.1K with 64 and 2.2K with the frontier (16GB).
XMR stack no dev is slower.

[JCE-Miner]

Please, make on GPU version video memory usage indicator to user know how much vmemory he allready used for mining.

I'll tell the amount of Memory JCE allocates, but of course not the amount of memory already allocated by other software. This is not a miner's job, better use GPU-Z.

@proffe14 : thanks for the ad... did you want to show you also provide a closed source CN Miner you pretend not to be a fork while you obviously use the Wolf OpenCL files like any other, or you just want I add your coin to my list?

[UnclWish]

Any progress with GPU version?

[JCE-Miner]

A lot.
i had to update my prototype i made at start to something releasable, and add the forks that didn't exist yet.  now i need to overcharge it to beat at least stak and xmrig, maybe srb.

i know srb will be my best opponent, and… i didn't find a way to make it mine fast on my test cards, which are Pitcairn, Tahiti and Baffin. if you know the optimal config of those, it would help to compare.

claymore 11 is still far above on hd7000 but produces a lot of bad shares. on Baffin i'm a lot above, my dual baffin peaks at 966 against 916 for claymore, who make 10% bad shares. bad shares deduced, maybe i'm on par with claymore on hd7000

against stak/xmrig i'm 2-3% better

[UnclWish]

I have Pitcairn card. 270X with 4Gb vmem. Best speed on cnv7 is on Claymore 11.3 - it's about 500-510 h/s. Settings are -h 460 -dmem 1
On SRB cnv7 about 450-475 h/s with intensity 58-59, worksize 8, threads 2.

Heavy algo on SRB - about 400 h/s with intensity 26, worksize 8, threads 2.

[JCE-Miner]

detailled settings and comparative results, exactly what i needed, thanks

i also observed srb being 10% lower than claymore, on hd700 (270X is a rebrand) but my pool reports hashrate 10% lower than expected on claymore miners (while my proto jce sends exactly what it displays, as expected)
i've a hd7870 so i'll be able to do the same compare.

[UnclWish]

detailled settings and comparative results, exactly what i needed, thanks

i also observed srb being 10% lower than claymore, on hd700 (270X is a rebrand) but my pool reports hashrate 10% lower than expected on claymore miners (while my proto jce sends exactly what it displays, as expected)
i've a hd7870 so i'll be able to do the same compare.

As I understand right, SRB is more for new cards... On old cards like 2xx and 3xx series Claymore is faster, but Claemore didn't support heavy algo...
I didn't tried XMR-stak and XMRig GPU, but i don't think that they are faster than Claymore on v7 or SRB on heavy...

[JCE-Miner]

I can beat stak and xmrig, they both use the same old code from Wolf0.

And claymore is a beast on CN-Classic on HD7000/2xx with 9.7
With 10+ i get high displayed hashrate on hd7000 but 10% bad shares, i can fix them by lowering intensity but then the hashrate itself drops by 10%.

On my dual Baffin i use the most for tests, i cannot get more than 915 on CN-v7 from Claymore, with a pool hashrate reported around 870. I made JCE run at 965 and stak at 940 with my current status. I didn't even started optim of CN-Heavy, it's a very different algo when implemented on GPU.

SRB, i'll do the tests you advised with my HD7870.
I also tested my Bonaire, which sends 240 on JCE, 265 on old Claymore 9.7 but is not even supported by Claymore 10+
That's consistent with the current 10% loss against Claymore 9.7

No dev today, my whole rig is dedicated to stability tests. Uptime 24h on all my GPU, no crash. I'll go back to dev after 48h of uptime, that will be enough to say it's stable. Testing during dev is very long, a bug in the OpenCL usually crash the GPU since the GPU memory is not virtualized like the one of a CPU. Sometimes the drivers can reset the gpu, but usually it just crashes.