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

[JCE-Miner]

yes I got message from users from everywhere about the duplicated shares, my fix for Nicehash has a huge regression impact on the normal netcode (of course some parts are common). I'm fixing right now, i'll release a 0.30c with Bittube-v4 is i can do it in time, plus netcode fix.

[vmozara]

Ok,
I managed to run the JCe on one of my 7xVega 56 rigs

So far results are amazing

14200-14350H/s, I run the miner for 14 hours on support XMR and pool reported exact the same number of hashes as the miner after 14 hours. This is so much better when Srbminer or Cast. When I asked about this problem in Srbminer topic, nobody cared and everybody made fun of me explaining that it is normal for hashrate to fluctuate and didn't even care for my elaboration. Now, I shut the rig down as it is in my home and I could not stand the noise

Tomorrow, I will switch all my rigs to JCE. Please keep developing, this will be fantastic miner.

[JCE-Miner]

What a welcome message, thanks!

I already discussed about the real hashrate of close-source miners, and I still claim that some do cheat, the most blantant case for me was Claymore 11.3 on cn-classic.

Just run Claymore 9.7 on an old non-forked coin like Bytecoin. You'll get 99% of the reported hashrate. Do the same with 11.3 and you'll get 90%.

I know about the random factor and the Stale shares, but on exact same pool, exact same hardware, on the long term (>24h) you should get the same ratio.
JCE does no tweak about the hashrate, may everybody check themselves and they can see.

I got good results on Vega, which is funny since i don't even own any myself. But i applied all the best optimizations possible (except on Heavy, not good yet) and i got excellent results on RX550 and vega, good on RX560 and 7850, and decent on RX570/580

I've finished the Bittube-v4 fork assemblies (ouch, ~100 asm files to update) and openCL (with the same bad perf than Heavy). And fixed the netcode, but i want to test more before release.
I expect the CPU version of bittube-v4 JCE to be a lot faster than on other miners, since I used assembly pseudo-aes implementation and not naive C like others.
There will be a complete release with CPU and 32-bits and Linux this time, not just GPU version.

[nightfury626]

What a welcome message, thanks!

I already discussed about the real hashrate of close-source miners, and I still claim that some do cheat, the most blantant case for me was Claymore 11.3 on cn-classic.

Just run Claymore 9.7 on an old non-forked coin like Bytecoin. You'll get 99% of the reported hashrate. Do the same with 11.3 and you'll get 90%.

I know about the random factor and the Stale shares, but on exact same pool, exact same hardware, on the long term (>24h) you should get the same ratio.
JCE does no tweak about the hashrate, may everybody check themselves and they can see.

I got good results on Vega, which is funny since i don't even own any myself. But i applied all the best optimizations possible (except on Heavy, not good yet) and i got excellent results on RX550 and vega, good on RX560 and 7850, and decent on RX570/580

I've finished the Bittube-v4 fork assemblies (ouch, ~100 asm files to update) and openCL (with the same bad perf than Heavy). And fixed the netcode, but i want to test more before release.
I expect the CPU version of bittube-v4 JCE to be a lot faster than on other miners, since I used assembly pseudo-aes implementation and not naive C like others.
There will be a complete release with CPU and 32-bits and Linux this time, not just GPU version.

so im trying to load this on simpleminingOS. what is a good example of config line to put in for mining?

[UnclWish]

What a welcome message, thanks!

I already discussed about the real hashrate of close-source miners, and I still claim that some do cheat, the most blantant case for me was Claymore 11.3 on cn-classic.

Just run Claymore 9.7 on an old non-forked coin like Bytecoin. You'll get 99% of the reported hashrate. Do the same with 11.3 and you'll get 90%.

I know about the random factor and the Stale shares, but on exact same pool, exact same hardware, on the long term (>24h) you should get the same ratio.
JCE does no tweak about the hashrate, may everybody check themselves and they can see.

I got good results on Vega, which is funny since i don't even own any myself. But i applied all the best optimizations possible (except on Heavy, not good yet) and i got excellent results on RX550 and vega, good on RX560 and 7850, and decent on RX570/580

I've finished the Bittube-v4 fork assemblies (ouch, ~100 asm files to update) and openCL (with the same bad perf than Heavy). And fixed the netcode, but i want to test more before release.
I expect the CPU version of bittube-v4 JCE to be a lot faster than on other miners, since I used assembly pseudo-aes implementation and not naive C like others.
There will be a complete release with CPU and 32-bits and Linux this time, not just GPU version.

Waiting optimization heavy algo code...

[Mrsmoker]

i will try this JCE miner tonight and report the result, sir, thank you for the hard work

[JCE-Miner]

Thanks all

@nightfury : go to the GitHub page or to the first post of this topic, there's an example of simple command line. note the gpu prototype still need manual configuration.

maybe stay on 0.30a since 0.30b has a glitchy netcode

[Lalli]

I have tested this miner now for couple of days with few old i7 2600K that I have.

So far its working very well, and is 10-15% faster than xmr-stak. Runs smooth with no problems, good job!

[JuanHungLo]

When running probe I get:

Code:

For Windows 64-bits
Analyzing Processors topology...
Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz
Assembly codename: generic_aes_avx
  SSE2          : Yes
  SSE3          : Yes
  SSE4          : Yes
  AES           : Yes
  AVX           : Yes
  AVX2          : Yes

Found CPU 0, with:
  L1 Cache:    32 KB, shared with CPU 1
  L2 Cache:   256 KB, shared with CPU 1
  L3 Cache:  8192 KB, shared with CPU 1, 2, 3, 4, 5, 6, 7
Found CPU 1, with:
  L1 Cache:    32 KB, shared with CPU 0
  L2 Cache:   256 KB, shared with CPU 0
  L3 Cache:  8192 KB, shared with CPU 0, 2, 3, 4, 5, 6, 7
Found CPU 2, with:
  L1 Cache:    32 KB, shared with CPU 3
  L2 Cache:   256 KB, shared with CPU 3
  L3 Cache:  8192 KB, shared with CPU 0, 1, 3, 4, 5, 6, 7
Found CPU 3, with:
  L1 Cache:    32 KB, shared with CPU 2
  L2 Cache:   256 KB, shared with CPU 2
  L3 Cache:  8192 KB, shared with CPU 0, 1, 2, 4, 5, 6, 7
Found CPU 4, with:
  L1 Cache:    32 KB, shared with CPU 5
  L2 Cache:   256 KB, shared with CPU 5
  L3 Cache:  8192 KB, shared with CPU 0, 1, 2, 3, 5, 6, 7
Found CPU 5, with:
  L1 Cache:    32 KB, shared with CPU 4
  L2 Cache:   256 KB, shared with CPU 4
  L3 Cache:  8192 KB, shared with CPU 0, 1, 2, 3, 4, 6, 7
Found CPU 6, with:
  L1 Cache:    32 KB, shared with CPU 7
  L2 Cache:   256 KB, shared with CPU 7
  L3 Cache:  8192 KB, shared with CPU 0, 1, 2, 3, 4, 5, 7
Found CPU 7, with:
  L1 Cache:    32 KB, shared with CPU 6
  L2 Cache:   256 KB, shared with CPU 6
  L3 Cache:  8192 KB, shared with CPU 0, 1, 2, 3, 4, 5, 6

Detecting OpenCL-capable GPUs...
No OpenCL-capable GPU found.

I have a MB-integrated graphics chip and 2 RX470s 8GB, Win7-64, AMD (Robinh00d blockchain driver)

Why aren't the GPUs being recognized?  They work in other miners.

[Iamtutut]

I mined a bit of XTL with the GPU miner

Config: Win 10 build 1803, AMD drivers 18.6.1
3X RX570 4GB with bios mod.
Display GPU (0): 1230/2100. Intensity: 720
GPU 1: 1230/2035. Intensity: 816
GPU2: 1230/2030.. Intensity: 816

Max speed: 2780 H/s. Power draw less than 350W. Others have a much higher intensity for this kind of algo, so I could get better hashrates.

JCE, one idea:
At some point, for one particular Stellite V4 kernel compilation, my display GPU had an exceptionnal hasrate regarding the intensity (always much lower than the two other GPUs), I had around 1030H/s. Could you program include something that compare the current compiling kernel to the best result (that would be saved) and keep the best of the two ? Like this, each GPU could have a optimum kernel regarding the intensity setup.

[UnclWish]

I mined a bit of XTL with the GPU miner

Config: Win 10 build 1803, AMD drivers 18.6.1
3X RX570 4GB with bios mod.
Display GPU (0): 1230/2100. Intensity: 720
GPU 1: 1230/2035. Intensity: 816
GPU2: 1230/2030.. Intensity: 816

Max speed: 2780 H/s. Power draw less than 350W. Others have a much higher intensity for this kind of algo, so I could get better hashrates.

JCE, one idea:
At some point, for one particular Stellite V4 kernel compilation, my display GPU had an exceptionnal hasrate regarding the intensity (always much lower than the two other GPUs), I had around 1030H/s. Could you program include something that compare the current compiling kernel to the best result (that would be saved) and keep the best of the two ? Like this, each GPU could have a optimum kernel regarding the intensity setup.

Did you tried intensity 832?

[vmozara]

Ok, I just started JCe miner on 34 Vegas to see if all have good results and stable operation. Total of 5 rigs with different motherboards, with and without risers, etc. After 24 hours I will count the hashes and run the calculations. If successful, I will update remaining rigs.

So far I did not encounter any stability issues, what happens with miner if one of the cards get stuck or some problem occurs? Does it have any kind of watchdog or restart feature? To be honest I didn't even read the manual, I just copy pasted settings that you guys put here and it worked beautiful  

[UnclWish]

On my RX 580 8Gb miner is pretty stable.
But on my 270X 4Gb one thread periodically stucks and didn't restarts until comp reboot. On Claymore's 11.3 with the same OC parameters 270X works stable.

[Iamtutut]

I mined a bit of XTL with the GPU miner

Config: Win 10 build 1803, AMD drivers 18.6.1
3X RX570 4GB with bios mod.
Display GPU (0): 1230/2100. Intensity: 720
GPU 1: 1230/2035. Intensity: 816
GPU2: 1230/2030.. Intensity: 816

Max speed: 2780 H/s. Power draw less than 350W. Others have a much higher intensity for this kind of algo, so I could get better hashrates.

JCE, one idea:
At some point, for one particular Stellite V4 kernel compilation, my display GPU had an exceptionnal hasrate regarding the intensity (always much lower than the two other GPUs), I had around 1030H/s. Could you program include something that compare the current compiling kernel to the best result (that would be saved) and keep the best of the two ? Like this, each GPU could have a optimum kernel regarding the intensity setup.

Did you tried intensity 832?

Right now:
720
880
880
Max hashrate: 2833 H/s.
345W from the wall

[UnclWish]

I mined a bit of XTL with the GPU miner

Config: Win 10 build 1803, AMD drivers 18.6.1
3X RX570 4GB with bios mod.
Display GPU (0): 1230/2100. Intensity: 720
GPU 1: 1230/2035. Intensity: 816
GPU2: 1230/2030.. Intensity: 816

Max speed: 2780 H/s. Power draw less than 350W. Others have a much higher intensity for this kind of algo, so I could get better hashrates.

JCE, one idea:
At some point, for one particular Stellite V4 kernel compilation, my display GPU had an exceptionnal hasrate regarding the intensity (always much lower than the two other GPUs), I had around 1030H/s. Could you program include something that compare the current compiling kernel to the best result (that would be saved) and keep the best of the two ? Like this, each GPU could have a optimum kernel regarding the intensity setup.

Did you tried intensity 832?

Right now:
720
880
880
Max hashrate: 2833 H/s.
345W from the wall

Higher 880 speed drops? Good intensity is 896, 912

[metalo]

No nicehash. It's on https://pool.catalyst.cash

is it with Nicehash or a normal pool?
I hope i havent made a regression because of my Nicehash fixes

I'm implementing Bittube-v2 right now

[syncro2017]

Anyone has some good settings mining Cryptonight-Fast? Thats the latest Masari Algo. So it looks like the regular V7 settings work pretty good.

[Beruang123]

Hi can anyone share the setting for vega 56?

Onething i notice from srb that jce uses 10 watts higher than srb.

[Lermite]

Anyone has some good settings mining Cryptonight-Fast? Thats the latest Masari Algo. So it looks like the regular V7 settings work pretty good.

Here are mines:

RX 580 4GB with lazy memory, GPU 1280 MHz VRAM 1950 Mhz: 1816 h/s
     { "mode": "GPU", "worksize": 4, "alpha": 128, "beta": 8, "gamma": 4, "delta": 4, "epsilon": 4, "zeta": 4, "index": 1, "multi_hash": 944 },
     { "mode": "GPU", "worksize": 4, "alpha": 128, "beta": 8, "gamma": 4, "delta": 4, "epsilon": 4, "zeta": 4, "index": 1, "multi_hash": 944 },

RX 570 8GB with awesome memory, GPU 1280 Mhz, VRAM 2250 MHz: 1868 h/s
     { "mode": "GPU", "worksize": 4, "alpha": 128, "beta": 8, "gamma": 4, "delta": 4, "epsilon": 4, "zeta": 4, "index": 2, "multi_hash": 1024 },
     { "mode": "GPU", "worksize": 4, "alpha": 128, "beta": 8, "gamma": 4, "delta": 4, "epsilon": 4, "zeta": 4, "index": 2, "multi_hash": 1024 },

[JCE-Miner]

Wow, so many messages, thanks all.

I'm currently burning my ryzen with the Bittube-v4 fork test. I'm one day late, but the speed on ryzen is higher than other miner. I don't give numbers since i may have badly configured the other (xmrig) I let you test by yourself, but my assembly optimization looks good.

Code:

Detecting OpenCL-capable GPUs...
No OpenCL-capable GPU found.

I've a known bug about APUs, nVidia cards and probably other cases, i've several exotic cards on my rigs (Baffin, Tahiti, Pitcairn, and even a Bonaire) but no APU or RX470 yet. That's why i keep it labeled "prototype" for now. I plan to buy an APU to test my bug, and hope it will fix the other cases too.

Could you program include something that compare the current compiling kernel to the best result (that would be saved) and keep the best of the two ? Like this, each GPU could have a optimum kernel regarding the intensity setup.

As i already mentionned, the OpenCL in the prototype is dynamic and expandable for security reasons. No way to save or reuse a kernel, on purpose. JCE kernels, may you dump them, would not work, even on a subsequent run of JCE.
I hope i'll find a way to be both secure and fast, and then maybe i'll be able to provide reusable kernels.

SRB kernels are normal kernels with just the file encrypted. One can attach a OpenCL debugger and look at the clear IL code (CGN pseudo-assembly). The same for Cast or Claymore. I want to be more secure. (no i didn't do that myself, my code uses exclusive optims I originaly developped for JCE CPU 32-bits, since CGN GPU are scalar 32-bits now, hence why the perf are different, and lower on Heavy for now).

what happens with miner if one of the cards get stuck or some problem occurs?

Yeah a watchdog is planned, to look for zero hashrate or GPU overheat. But not higher priority for now.

"Lermite" mmh, that name sounds familiar...