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

[1rV1N]

Hello!
You miner is perfect!!
Good work.
Can you add in miner mining algorithm negotiation like xmirg
https://github.com/xmrig/xmrig-proxy/blob/master/doc/STRATUM_EXT.md

[1714838501]

1714838501

[1714838501]

1714838501

[1714838501]

1714838501

[pbfarmer]

I've got a problem with the warm-up on my RX580s, not all cards in a sistem end up at full optimal speed after the warmup on heavy/haven/saber. This happens even if I have gpu-z in the background (which adds another 15h/s per card fluctuation after the warmup). I am on "p" version right now, on "n" version I thought it did much better, but wanted to use refined watchdog and get a small boost in mining speed with the latest version. What am I doing wrong?
I use 976 intensity, happens with lower intensity too. If I turn off a card that has optimal speed after warmup, and turn it back on, it has 15% less speed and doesn't get back up to optimal. Something needs to be reworked in the handling of the warmup, I also see a VRAM cluttering, an 8gb cards ends up showing it has 11gb of vram used in gpu-z (maybe bug?). Maybe we need some way to flush the vram and this is what's causing it, especially for those that restart the miner quite often (automatic profit switchers).

Have same issue (mentioned above).  Often-times, it works itself out after an hour or two.  However, you can also put a watchdog limit in, and an auto-restart loop around the miner, and it may get to optimal speeds faster.

[JCE-Miner]

Hi all!

Sorry I had very little time to do the Support since i'm focusing on the V8 fork, and there are little time remaining to do all the benches and tests. The problem with assembly dev is that it takes a LOT of time, step by step.

JC - can't even begin to say how impressed I am w/ this miner

Thanks for the warm feedback

Pretty solid Miner JCE ! I have not yet fine tuned my 12 rx580 with your miner and already got 1kh increase in the 24h avg chart !

ditto

Hi ! nice miner i tried it local yesterday before planing to put it on my rigs. Before it i would like to know how devfees works ? Is it like Claymore and you connect to your pool from time to time for few secs/mins ? i've not seen anything on my test yesterday.

I use the same fee system as Claymore, I already explained it, so there are randomized start/duration of fee sessions on the same algo that you use, for both CPU and GPU. Like Claymore did.
One difference, I use non-aggressive opaque fee sessions: some shares, from time to time, on a 0.9% average, are sent to me, and not counted in the effective hashrate counter. This this different from Claymore who colored them Purple.
And having learnt from SRB feedbacks, the fees are non-blocking (if the fee fails the miner continues fine, and does not produce revenge stale shares like Claymore did). And having observed the tagged fees in SRB triggered people restarting the miner just before the fee session, a form of cheating, they are opaque and randomized, on purpose.
The overall behavior is that you'll get at least 99.1% of your hashing power whatever happens.
On CPU fees are 1.5% (AES) or 3% (non-AES) and in case of mix, the fee level is weighted-averaged.

jce will automaticatly change algo on the fork or not?

Can you add in miner mining algorithm negotiation like xmirg

This is a nice feature... which is useful twice a year at best, so i probably won't have time for it

Hi, JCE! I want to send you a personal message with your permission! This is important.

Sure send, i'll take time to read it. I appologize to all who sent me a message i haven't read yet, but as said above, i'm struggling at finishing my v8 assembly in time

I skip all questions about GPU for now, I'm focusing on the CPU version, I want to release all CPU versions (32/64, AES/non-aes, Win/Linux) in time.

[1rV1N]

This is a nice feature... which is useful twice a year at best, so i probably won't have time for it

not two. I use this features very often. I can connect xmrig miner to XNP and don't touch miner, only config XNP to connect to different pools. XNP says xmirg which algo to use.

[JCE-Miner]

Oh, i never tried this feature, sure it's a lot more useful than the autoswitch when Monero forks (twice a year). I'm still not confident to have time enough to implement it, but you convinced me it's not just a gadget feature

I hope i'll be able to release the v8-capable CPU version soon.

[chrisbfrpky]

Thank you for a great CPU/GPU miner. I'm currently getting an average of 360 H/s each on RX 560 2GB cards mining Cryptonight heavy. That's about 50 H/s more per card than when I was using them on SMOS with XMR-stak or XMR-rig. Plus with the --no cpu command I'm able to cpu mine a different coin with a different algo miner and there is no noticeable loss in performance for either coin being mined. Maximum hashrates all around.

The RX 560 4GB and RX 580 rigs are next on the list of moving to your miner program. Thanks again and the dev fee is definitely reasonable and worth every bit.

It would certainly be nice of you were to write a multi-algo miner to cover them all. HODL comes to mind.......

Thanks again,
Chris B.

[mijnerke]

thnx for your great miner.
Upcoming October 18th fork of XMR supported?

cheers

[sxemini]

Hi JCE,

i updated my 3 Rigs to JCE Miner. It works great, effective hash increase, but i have a problem.



At around 3:30 o´clock all 3 rigs deliver stale shares for around 1.5 hours, 5 days in a row. Other people in this pool don´t have this problem, other miner (for example SRB) don´t have this problem. If it is on 1 Rig then i say ok to much OC, but 3 realy different rigs with different cards and different drivers make the same problem? i think it is a jce miner problem. A Ryzen R5 1600 delivers also stales shares and with the older version 0.32m it works.
I use jce 0.32q at the moment. Any solution or other guys with this problem?

[Pennywis3]

Oh, i never tried this feature, sure it's a lot more useful than the autoswitch when Monero forks (twice a year). I'm still not confident to have time enough to implement it, but you convinced me it's not just a gadget feature

I hope i'll be able to release the v8-capable CPU version soon.

Moneroocean pool also uses XMrig for algo switching, it's really useful and gives nice profits.
XMR Stack can also be compiled to use algo switch, and SRB also supports it.

Just sayin', so you don't get left behind 

[Uaciuganadu]

Oh, i never tried this feature, sure it's a lot more useful than the autoswitch when Monero forks (twice a year). I'm still not confident to have time enough to implement it, but you convinced me it's not just a gadget feature

I hope i'll be able to release the v8-capable CPU version soon.

Moneroocean pool also uses XMrig for algo switching, it's really useful and gives nice profits.
XMR Stack can also be compiled to use algo switch, and SRB also supports it.

Just sayin', so you don't get left behind 

While i do agree with you and think that auto algo switch is a good idea and can create better profits, i also think that the way is currently implemented in other miners is very trivial and thus i refused to use it. The fact that you need to manually configure and test every algo is wasting time in my opinion. Another waste of time is that in the current trivial implementation, the miner has to restart when changing the algo.

What i really hope is that in the future more altcoins will implement algos that are very compatible with what Monero is putting out there and that due to this, miner software can be modified to perform an auto algo switch as fast as they do the devfee switch.

At this point i find the current implementation of algo switch more of an interruption to mining with very small increase in profits.

[Pennywis3]

Oh, i never tried this feature, sure it's a lot more useful than the autoswitch when Monero forks (twice a year). I'm still not confident to have time enough to implement it, but you convinced me it's not just a gadget feature

I hope i'll be able to release the v8-capable CPU version soon.

Moneroocean pool also uses XMrig for algo switching, it's really useful and gives nice profits.
XMR Stack can also be compiled to use algo switch, and SRB also supports it.

Just sayin', so you don't get left behind  

While i do agree with you and think that auto algo switch is a good idea and can create better profits, i also think that the way is currently implemented in other miners is very trivial and thus i refused to use it. The fact that you need to manually configure and test every algo is wasting time in my opinion. Another waste of time is that in the current trivial implementation, the miner has to restart when changing the algo.

What i really hope is that in the future more altcoins will implement algos that are very compatible with what Monero is putting out there and that due to this, miner software can be modified to perform an auto algo switch as fast as they do the devfee switch.

At this point i find the current implementation of algo switch more of an interruption to mining with very small increase in profits.

XMrig does what you describe, it changes algo without restart or compile and it will also benchmark your rig so you are left just with the fine tuning.
I hope that something similar can be implemented into JCE and others, especially SRBminer that has really awkward and way too long algo changes ( restart + compile + warmup ), which makes it useless for algo switching
Miner developers should really look at MoneroOcean + XMrig, algo switching is done on the fly and really well implemented, and since we have tons of CN based coins one could assume algo switching is gonna become even more popular in the future.

You can check CN mining pool profits below ( especially for last half a year ).
https://moneroocean.stream/profits/

[dingdongtobias]

Oh, i never tried this feature, sure it's a lot more useful than the autoswitch when Monero forks (twice a year). I'm still not confident to have time enough to implement it, but you convinced me it's not just a gadget feature

I hope i'll be able to release the v8-capable CPU version soon.

Moneroocean pool also uses XMrig for algo switching, it's really useful and gives nice profits.
XMR Stack can also be compiled to use algo switch, and SRB also supports it.

Just sayin', so you don't get left behind  

While i do agree with you and think that auto algo switch is a good idea and can create better profits, i also think that the way is currently implemented in other miners is very trivial and thus i refused to use it. The fact that you need to manually configure and test every algo is wasting time in my opinion. Another waste of time is that in the current trivial implementation, the miner has to restart when changing the algo.

What i really hope is that in the future more altcoins will implement algos that are very compatible with what Monero is putting out there and that due to this, miner software can be modified to perform an auto algo switch as fast as they do the devfee switch.

At this point i find the current implementation of algo switch more of an interruption to mining with very small increase in profits.

XMrig does what you describe, it changes algo without restart or compile and it will also benchmark your rig so you are left just with the fine tuning.
I hope that something similar can be implemented into JCE and others, especially SRBminer that has really awkward and way too long algo changes ( restart + compile + warmup ), which makes it useless for algo switching
Miner developers should really look at MoneroOcean + XMrig, algo switching is done on the fly and really well implemented, and since we have tons of CN based coins one could assume algo switching is gonna become even more popular in the future.

You can check CN mining pool profits below ( especially for last half a year ).
https://moneroocean.stream/profits/

XMrig for cpu version change algo without restart not gpu.
Compile needs only once on SRB, not every restart 

[chrisbfrpky]

hi, gpu 0 for me has lower hash rate then the other gpu's, same OC settings and parameters in miner, is it because it has a monitor plugged in? difference in hashrate is noticable

also 1 gpu on CN heavy is averaging around 460h/s but has spiked to 590 h/s! is that normal on CN-heavy?

It's normal to get a lower hashrate on a GPU that has a monitor plugged into it. Either power down the monitor and disconnect it from the card, or setup Windows startup programs to automatically run your miner program on system boot up. The latter will be the best option IMO as your miner will automatically restart after a system reboot from a Windows update or something with no monitor connection or interaction from you required. Some guys disable Windows update, I don't. There are many reason Windows needs to be up to date. Easy to find a step by step guide on Youtube to show you how to add a program to the Windows start up folder.

Hashrates will be up and down depending on the share submitted, no worries.
Chris B.

[monote]

Hey hey hey! Maybe it was asked before (at least i couldn't find it).
Any plan of adding webchain to the list of supported coins?

Cheers!

[HardKano]

Your miner with CN-heavy is solid ! I have better hashrate on 24avg than cnv7 !

[UnclWish]

Your miner with CN-heavy is solid ! I have better hashrate on 24avg than cnv7 !

Speed of heavy algo on 8Gb+ cards allways faster than on V7. It's normal.

[Iamtutut]

Your miner with CN-heavy is solid ! I have better hashrate on 24avg than cnv7 !

Speed of heavy algo on 8Gb+ cards allways faster than on V7. It's normal.

I thought it was 1,5KH/s on CN Heavy (Vega 56/64) and 2K/s on V7.

[HardKano]

Your miner with CN-heavy is solid ! I have better hashrate on 24avg than cnv7 !

Speed of heavy algo on 8Gb+ cards allways faster than on V7. It's normal.

Good to know ! i tried Alloy too and it was half of my normal speed. i was sure heavy algo was a bit slower in speed.

[lilu5151515151]

Hi,
I've been trying to run jce_cn_gpu_miner.032q and jce_cn_gpu_miner.prototype.032n on this card. I'm using Windows 10 and 18.8.1 drivers. No overclock. Card Sapphire Radeon RX 560 4GB
+------------------------------------------+
| JC Expert Cryptonote CPU+GPU Miner 0.32n |
+------------------------------------------+

For Windows 64-bits
Analyzing Processors topology...
AMD Ryzen 5 1600 Six-Core Processor
Assembly codename: ryzen
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: 512 KB, shared with CPU 1
L3 Cache: 8192 KB, shared with CPU 1, 2, 3, 4, 5
Found CPU 1, with:
L1 Cache: 32 KB, shared with CPU 0
L2 Cache: 512 KB, shared with CPU 0
L3 Cache: 8192 KB, shared with CPU 0, 2, 3, 4, 5
Found CPU 2, with:
L1 Cache: 32 KB, shared with CPU 3
L2 Cache: 512 KB, shared with CPU 3
L3 Cache: 8192 KB, shared with CPU 0, 1, 3, 4, 5
Found CPU 3, with:
L1 Cache: 32 KB, shared with CPU 2
L2 Cache: 512 KB, shared with CPU 2
L3 Cache: 8192 KB, shared with CPU 0, 1, 2, 4, 5
Found CPU 4, with:
L1 Cache: 32 KB, shared with CPU 5
L2 Cache: 512 KB, shared with CPU 5
L3 Cache: 8192 KB, shared with CPU 0, 1, 2, 3, 5
Found CPU 5, with:
L1 Cache: 32 KB, shared with CPU 4
L2 Cache: 512 KB, shared with CPU 4
L3 Cache: 8192 KB, shared with CPU 0, 1, 2, 3, 4
Found CPU 6, with:
L1 Cache: 32 KB, shared with CPU 7
L2 Cache: 512 KB, shared with CPU 7
L3 Cache: 8192 KB, shared with CPU 7, 8, 9, 10, 11
Found CPU 7, with:
L1 Cache: 32 KB, shared with CPU 6
L2 Cache: 512 KB, shared with CPU 6
L3 Cache: 8192 KB, shared with CPU 6, 8, 9, 10, 11
Found CPU 8, with:
L1 Cache: 32 KB, shared with CPU 9
L2 Cache: 512 KB, shared with CPU 9
L3 Cache: 8192 KB, shared with CPU 6, 7, 9, 10, 11
Found CPU 9, with:
L1 Cache: 32 KB, shared with CPU 8
L2 Cache: 512 KB, shared with CPU 8
L3 Cache: 8192 KB, shared with CPU 6, 7, 8, 10, 11
Found CPU 10, with:
L1 Cache: 32 KB, shared with CPU 11
L2 Cache: 512 KB, shared with CPU 11
L3 Cache: 8192 KB, shared with CPU 6, 7, 8, 9, 11
Found CPU 11, with:
L1 Cache: 32 KB, shared with CPU 10
L2 Cache: 512 KB, shared with CPU 10
L3 Cache: 8192 KB, shared with CPU 6, 7, 8, 9, 10

Detecting OpenCL-capable GPUs...
Pм)╨╫�

+------------------------------------------+
| JC Expert Cryptonote CPU+GPU Miner 0.32q |
+------------------------------------------+

For Windows 64-bits
Analyzing Processors topology...
AMD Ryzen 5 1600 Six-Core Processor
Assembly codename: ryzen
SSE2 : Yes
SSE3 : Yes
SSE4 : Yes
AES : Yes
AVX : Yes
AVX2 : Yes

Auto-configuration, selected CPUs will be highlighted...
Found CPU 0, with:
L1 Cache: 32 KB, shared with CPU 1
L2 Cache: 512 KB, shared with CPU 1
L3 Cache: 8192 KB, shared with CPU 1, 2, 3, 4, 5
Found CPU 1, with:
L1 Cache: 32 KB, shared with CPU 0
L2 Cache: 512 KB, shared with CPU 0
L3 Cache: 8192 KB, shared with CPU 0, 2, 3, 4, 5
Found CPU 2, with:
L1 Cache: 32 KB, shared with CPU 3
L2 Cache: 512 KB, shared with CPU 3
L3 Cache: 8192 KB, shared with CPU 0, 1, 3, 4, 5
Found CPU 3, with:
L1 Cache: 32 KB, shared with CPU 2
L2 Cache: 512 KB, shared with CPU 2
L3 Cache: 8192 KB, shared with CPU 0, 1, 2, 4, 5
Found CPU 4, with:
L1 Cache: 32 KB, shared with CPU 5
L2 Cache: 512 KB, shared with CPU 5
L3 Cache: 8192 KB, shared with CPU 0, 1, 2, 3, 5
Found CPU 5, with:
L1 Cache: 32 KB, shared with CPU 4
L2 Cache: 512 KB, shared with CPU 4
L3 Cache: 8192 KB, shared with CPU 0, 1, 2, 3, 4
Found CPU 6, with:
L1 Cache: 32 KB, shared with CPU 7
L2 Cache: 512 KB, shared with CPU 7
L3 Cache: 8192 KB, shared with CPU 7, 8, 9, 10, 11
Found CPU 7, with:
L1 Cache: 32 KB, shared with CPU 6
L2 Cache: 512 KB, shared with CPU 6
L3 Cache: 8192 KB, shared with CPU 6, 8, 9, 10, 11
Found CPU 8, with:
L1 Cache: 32 KB, shared with CPU 9
L2 Cache: 512 KB, shared with CPU 9
L3 Cache: 8192 KB, shared with CPU 6, 7, 9, 10, 11
Found CPU 9, with:
L1 Cache: 32 KB, shared with CPU 8
L2 Cache: 512 KB, shared with CPU 8
L3 Cache: 8192 KB, shared with CPU 6, 7, 8, 10, 11
Found CPU 10, with:
L1 Cache: 32 KB, shared with CPU 11
L2 Cache: 512 KB, shared with CPU 11
L3 Cache: 8192 KB, shared with CPU 6, 7, 8, 9, 11
Found CPU 11, with:
L1 Cache: 32 KB, shared with CPU 10
L2 Cache: 512 KB, shared with CPU 10
L3 Cache: 8192 KB, shared with CPU 6, 7, 8, 9, 10

Detecting OpenCL-capable GPUs...
Found GPU 0, with:
Vendor: AMD
Processor: Baffin
Device: 09:00
Compute-Units: 16
Cache Memory: 16 KB
Local Memory: 32 KB
Global Memory: 4096 MB
Addressing: 64-bits

Preparing 10 Mining Threads...

+-- Thread 0 config -----------------------+
| Run on CPU: 0 |
| Use cache: yes |
| Multi-hash: no |
| Assembly module: ryzen |
+------------------------------------------+

+-- Thread 1 config -----------------------+
| Run on CPU: 1 |
| Use cache: yes |
| Multi-hash: no |
| Assembly module: ryzen |
+------------------------------------------+

+-- Thread 2 config -----------------------+
| Run on CPU: 2 |
| Use cache: yes |
| Multi-hash: no |
| Assembly module: ryzen |
+------------------------------------------+

+-- Thread 3 config -----------------------+
| Run on CPU: 4 |
| Use cache: yes |
| Multi-hash: no |
| Assembly module: ryzen |
+------------------------------------------+

+-- Thread 4 config -----------------------+
| Run on CPU: 6 |
| Use cache: yes |
| Multi-hash: no |
| Assembly module: ryzen |
+------------------------------------------+

+-- Thread 5 config -----------------------+
| Run on CPU: 7 |
| Use cache: yes |
| Multi-hash: no |
| Assembly module: ryzen |
+------------------------------------------+

+-- Thread 6 config -----------------------+
| Run on CPU: 8 |
| Use cache: yes |
| Multi-hash: no |
| Assembly module: ryzen |
+------------------------------------------+

+-- Thread 7 config -----------------------+
| Run on CPU: 10 |
| Use cache: yes |
| Multi-hash: no |
| Assembly module: ryzen |
+------------------------------------------+

+-- Thread 8 config -----------------------+
| Run on GPU: 0 |
| Multi-hash: 464 |
| Worksize: 8 |
| Factor Alpha 64 |
| Factor Beta 8 |
+------------------------------------------+

+-- Thread 9 config -----------------------+
| Run on GPU: 0 |
| Multi-hash: 464 |
| Worksize: 8 |
| Factor Alpha 64 |
| Factor Beta 8 |
+------------------------------------------+

Cryptonight Variation: Cryptonight V7 fork of April-2018

Low intensity.

Starting CPU Mining thread 0, affinity: CPU 0
Thread 0 successfully bound to CPU 0
Allocated shared Large Page at: 0000023044c00000
Allocated 2MB Cached Large Page Scratchpad Buffer for CPU 0 of NUMA node 0 at: 0000023044e00000

Starting CPU Mining thread 1, affinity: CPU 1
Thread 1 successfully bound to CPU 1
Allocated 2MB Cached Large Page Scratchpad Buffer for CPU 1 of NUMA node 0 at: 0000023045000000

Starting CPU Mining thread 2, affinity: CPU 2
Thread 2 successfully bound to CPU 2
Allocated 2MB Cached Large Page Scratchpad Buffer for CPU 2 of NUMA node 0 at: 0000023045200000

Starting CPU Mining thread 3, affinity: CPU 4
Thread 3 successfully bound to CPU 4
Allocated 2MB Cached Large Page Scratchpad Buffer for CPU 4 of NUMA node 0 at: 0000023045400000

Starting CPU Mining thread 4, affinity: CPU 6
Thread 4 successfully bound to CPU 6
Allocated 2MB Cached Large Page Scratchpad Buffer for CPU 6 of NUMA node 0 at: 0000023045600000

Starting CPU Mining thread 5, affinity: CPU 7
Thread 5 successfully bound to CPU 7
Allocated 2MB Cached Large Page Scratchpad Buffer for CPU 7 of NUMA node 0 at: 0000023045800000

Starting CPU Mining thread 6, affinity: CPU 8
Thread 6 successfully bound to CPU 8
Allocated 2MB Cached Large Page Scratchpad Buffer for CPU 8 of NUMA node 0 at: 0000023045a00000

Starting CPU Mining thread 7, affinity: CPU 10
Thread 7 successfully bound to CPU 10
Allocated 2MB Cached Large Page Scratchpad Buffer for CPU 10 of NUMA node 0 at: 0000023045c00000

Starting GPU Mining thread 8, on GPU 0
Created OpenCL Context for GPU 0 at 000002304485e040
Created OpenCL Thread 8 Command-Queue for GPU 0 at 0000023044872e10
Scratchpad Allocation success for OpenCL Thread 8
Allocating big 928MB scratchpad for OpenCL Thread 8...
Compiling kernels of OpenCL Thread 8...
Compilation of OpenCL kernels failed.
Error: CL_BUILD_PROGRAM_FAILURE Code: O-2.10

Starting GPU Mining thread 9, on GPU 0
Created OpenCL Thread 9 Command-Queue for GPU 0 at 0000023044846400
Scratchpad Allocation success for OpenCL Thread 9
Allocating big 928MB scratchpad for OpenCL Thread 9...
Compiling kernels of OpenCL Thread 9...
Compilation of OpenCL kernels failed.
Error: CL_BUILD_PROGRAM_FAILURE Code: O-2.10
Devfee for CPU is 1.5%
Devfee for GPU is 0.9%

15:34:41 | OpenCL Thread 8 failed, Stop.
15:34:41 | Unloaded OpenCL kernels of GPU Thread 8
15:34:41 | Connecting to mining pool pool.supportxmr.com:5555 ...
15:34:41 | Monero (XMR/XMV) Mining session starts!

During mining time, press:
h display hashrate for each mining thread.
r display full report.
p pause all.
u pause CPUs.
0-F pause GPU 0-15.
t GPU temperature and fan speed.
q quit.

15:34:41 | GPU Compute allocation starts at 80% and reaches 100% after ~5min,
15:34:41 | during this time, the hashrate may be unstable and inconsistent.
15:34:41 | Let the miner warm-up if you're tuning for performance.
15:34:41 | OpenCL Thread 9 failed, Stop.
15:34:41 | Unloaded OpenCL kernels of GPU Thread 9
15:34:41 | Released OpenCL Thread 8 Scratchpad at 000002304ad32ac0
15:34:41 | Released OpenCL Thread 9 Scratchpad at 00000230449d9fb0
15:34:41 | Released OpenCL Thread 8 Command-Queue of GPU 0 at 0000023044872e10
15:34:42 | Released OpenCL Thread 9 Command-Queue of GPU 0 at 0000023044846400
15:34:42 | Connected to pool. Now logging in...
15:34:42 | Successfuly logged as 47aepaEmi318XjZV5k5Svf4jYdzb4dKcZX7bLbSPCP41Ade7NZs816rjXqrT3anyZ22j7DEE74GkbVc QFyH2nNiC3hzR3gr
15:34:42 | Pool changes Difficulty to 10000.

Any thoughts on that? xmr-stak, Claymore and other GPU miners work just fine.

[kissmarx]

hi JCE Miner! I love your miner. But I wish you also include Monero v8 variant in your next release version of this miner because Wownero have changed to it already in anticipation to Monero's soon move to it.