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

[JCE-Miner]

This is very summarized, but not wrong

Here's the 0.33p CPU Win and Linux, 32 and 64, minor revision

Native Stellite v8 and Masari v8 support

Next comes GPU version. You can already mine Masari v8 with the current 0.33n with parameter --variation 21

[Iamtutut]

Can't GPU mine Masar with GPU 0.33B16

Start.bat: jce_cn_gpu_miner64.exe -c config.txt --variation 21 --forever --no-cpu -o pool.masaricoin.com:5555 -u 5k2sy1QzaJ*******vk8mriNPURHP4vSf -p Z****t

Starting GPU Thread 0, on GPU 0
Created OpenCL Context for GPU 0 at 00000247754389e0
Created OpenCL Thread 0 Command-Queue for GPU 0 at 0000024775419b80
Scratchpad Allocation success for OpenCL Thread 0
Allocating big 1888MB scratchpad for OpenCL Thread 0...
Compiling kernels of OpenCL Thread 0...
Kernels of OpenCL Thread 0 compiled.
Allocated shared Large Page at: 000002477f800000
Allocated 4MB Cached Large Page Scratchpad Buffer at: 000002477fa00000

Starting GPU Thread 1, on GPU 0
Created OpenCL Thread 1 Command-Queue for GPU 0 at 000002477a04b910
Scratchpad Allocation success for OpenCL Thread 1
Allocating big 1888MB scratchpad for OpenCL Thread 1...
Compiling kernels of OpenCL Thread 1...
Kernels of OpenCL Thread 1 compiled.

Starting GPU Thread 2, on GPU 1
Created OpenCL Context for GPU 1 at 0000024775b34470
Created OpenCL Thread 2 Command-Queue for GPU 1 at 000002477a04bbb0
Scratchpad Allocation success for OpenCL Thread 2
Allocating big 1888MB scratchpad for OpenCL Thread 2...
Compiling kernels of OpenCL Thread 2...
Kernels of OpenCL Thread 2 compiled.

Starting GPU Thread 3, on GPU 1
Created OpenCL Thread 3 Command-Queue for GPU 1 at 000002477a04afe0
Scratchpad Allocation success for OpenCL Thread 3
Allocating big 1888MB scratchpad for OpenCL Thread 3...
Compiling kernels of OpenCL Thread 3...
Kernels of OpenCL Thread 3 compiled.

Starting GPU Thread 4, on GPU 2
Created OpenCL Context for GPU 2 at 0000024775b34730
Created OpenCL Thread 4 Command-Queue for GPU 2 at 000002477a04b7c0
Scratchpad Allocation success for OpenCL Thread 4
Allocating big 1888MB scratchpad for OpenCL Thread 4...
Compiling kernels of OpenCL Thread 4...
Kernels of OpenCL Thread 4 compiled.

Starting GPU Thread 5, on GPU 2
Created OpenCL Thread 5 Command-Queue for GPU 2 at 000002477f411350
Scratchpad Allocation success for OpenCL Thread 5
Allocating big 1888MB scratchpad for OpenCL Thread 5...
Compiling kernels of OpenCL Thread 5...
Kernels of OpenCL Thread 5 compiled.

Starting GPU Thread 6, on GPU 3
Created OpenCL Context for GPU 3 at 0000024775b32e70
Created OpenCL Thread 6 Command-Queue for GPU 3 at 000002477f4114a0
Scratchpad Allocation success for OpenCL Thread 6
Allocating big 1888MB scratchpad for OpenCL Thread 6...
Compiling kernels of OpenCL Thread 6...
Kernels of OpenCL Thread 6 compiled.

Starting GPU Thread 7, on GPU 3
Created OpenCL Thread 7 Command-Queue for GPU 3 at 000002477f410390
Scratchpad Allocation success for OpenCL Thread 7
Allocating big 1888MB scratchpad for OpenCL Thread 7...
Compiling kernels of OpenCL Thread 7...
Kernels of OpenCL Thread 7 compiled.
Devfee for GPU is 0.9%

22:30:45 | Masari (MSR) 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.

22:30:45 | GPU Compute allocation starts at 80% and reaches 100% after ~1min,
22:30:45 | during this time, the hashrate may be unstable and inconsistent.
22:30:45 | Let the miner warm-up if you're tuning for performance.

22:30:46 | Connecting to mining pool pool.masaricoin.com:5555 ...
22:30:46 | Connected to pool. Now logging in...
22:30:46 | Successfuly logged as 5k2sy1QzaJ************NPURHP4vSf
22:30:46 | Pool changes Difficulty to 10000.
Appuyez sur une touche pour continuer...

[JCE-Miner]

i could reproduce the bug, right
Since I planned to add official support in b17 only, it doesn't change the plan, just i'll invalidate the b16 once b17 is online.
Thanks a lot for the report
The cpu part of b16 can still mine Masari, so there's clearly something missing in my opencl generator.

edit: yeah this was exactly the bug, something missing to handle Masari well.
The new 0.33b17 GPU replaces the b16, with

Masari v8 support
watchdog can restart the miner instead of quit, parameter --restart

[nc50lc]

Hey, there's a guy who's using your miner's name and thread contents to distribute a virus. Link to his thread
Probably another Russian hacker or the same guy who've done the same thing last year.

I've already reported him but it would be best if you can immediately reply an allegation to minimize the possible victims.
Time's ticking.

[UnclWish]

Can't launch miner to use only 1st GPU. For both of GPU's all works fine. When I remove from config.txt all strings with GPU 1 lefting only GPU 0, miner starts and after connecting to pool closes.
In events error with attrib.exe
In log:

Code:

Starting GPU Thread 0, on GPU 0
Created OpenCL Context for GPU 0 at 0000022fca316a00
Created OpenCL Thread 0 Command-Queue for GPU 0 at 0000022fca0f7830
Scratchpad Allocation success for OpenCL Thread 0
Allocating big 3968MB scratchpad for OpenCL Thread 0...
Compiling kernels of OpenCL Thread 0...
Kernels of OpenCL Thread 0 compiled.
Allocated shared Large Page at: 000002308de00000
Allocated 8MB Cached Large Page Scratchpad Buffer at: 000002308e000000
17:48:18 | Nicehash Mining session starts!

17:48:18 | GPU Compute allocation starts at 80% and reaches 100% after ~1min,
17:48:18 | during this time, the hashrate may be unstable and inconsistent.
17:48:18 | Let the miner warm-up if you're tuning for performance.

17:48:19 | Connecting to mining pool cryptonightheavy.eu.nicehash.com:3364 ...
17:48:19 | Connected to pool. Now logging in...
17:48:19 | Successfuly logged as xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.JCE1stGPU
17:48:19 | Pool changes Difficulty to 50000.

[whotheff]

JCE, beware, this guy is trying to rip you and your miners:

https://bitcointalk.org/index.php?topic=5103137.0

I reported him, so should all JCE users.

[Iamtutut]

GRAFT UPCOMING FORK (CN Waltz):
https://github.com/graft-project/GraftNetwork/tree/test/cn_waltz_test

[HardKano]

Hell yeah ! they don't waste time wandering ! I love graft team !

[justoiurii]

Hi, DEV) Are you planing to add HYC coin?

[Iamtutut]

So, after around 19hs mining TURTLECOIN with the new algo, a bit of feedback:

Reminder: my PC/rig is composed of Ryzen 5 2400G (12GB DDR4 2400) on a X470 mobo and 4X AMD RX570 4GB with bios mod.

My GPU hashrate is 4,22X higher than with the previous algo, which means GPUs are much better off against FPGAs. I have now around 33KH/s, I had at most 7,8KH/s before.
My CPU hashrate is 6X higher than previously (I had 860H/s, now 5150H/s) which means to me that the new algo really favors CPUs for better decentralisation. The Ryzen G has little cache (8MB L3) and I use it for display, meaning that I can't access the whole L3 cache. I expect normal Ryzen series to get an even more impressive boost in performance.

The new algo is more power hungry, that doesn't bother me at all considering the HUGGGGE boost in performance. With the CN lite V7 it was 450W/H (CPU + GPU), now 570W/H (CPU + GPU) with CN ultra lite.

Among my RX570s, one has a much weaker ASIC than the others, so I had to reduce the intensity compared to the other GPUs, otherwise it hangs out after less than 30mn mining. So the weak one intensity is 960, the others including my beloved little Sapphire ITX is 1008.

The network fee is ridiculously low (love it ), 0.03TRTL for a >10K payment by the pool.



Thanks to JCE for the amazing miner, thanks to TURTLECOIN devs for really taking care of their mining community

[JCE-Miner]

Hi all!

Unclwish: i note, i'll try to reproduce the bug on a 2-gpu rig.

HYC: both Hycon and Webchain are non-standard CN forks that would require a lot more refactoring of my netcode than the other forks, so, looking at how little dev time i've left now, i bypassed them for now. My next fork should be Graft. Take a look at SRB who added support for those both forks recently on GPU, and on CPU you can get the reference miner, possibly compiled with zero fees.
Both those forks are not CPU-friendly, and coin-specific, and since my miner is mostly a CPU miner, I somehow overlooked them on purpose. Turtle v2 and Masari v8 are a lot more interresting to mine on CPU.
Now I focus on CN-Waltz for Graft, which is a cleaner and better documented fork.

JCE as a virus: thanks all for the report, and yes that already happened several times, and there's little I can do above putting a warning about the fake releases on all my download pages (here page 1 and Github). I tends to happen to every miner software, very like being detected as a virus by Win Defender and al. That's the game

So sad how all those coin prices are on a down trend. Haven got its price divided by 10

[rednoW]

So, after around 19hs mining TURTLECOIN with the new algo, a bit of feedback:

Reminder: my PC/rig is composed of Ryzen 5 2400G (12GB DDR4 2400) on a X470 mobo and 4X AMD RX570 4GB with bios mod.

My GPU hashrate is 4,22X higher than with the previous algo, which means GPUs are much better off against FPGAs. I have now around 33KH/s, I had at most 7,8KH/s before.
My CPU hashrate is 6X higher than previously (I had 860H/s, now 5150H/s) which means to me that the new algo really favors CPUs for better decentralisation. The Ryzen G has little cache (8MB L3) and I use it for display, meaning that I can't access the whole L3 cache. I expect normal Ryzen series to get an even more impressive boost in performance.

The new algo is more power hungry, that doesn't bother me at all considering the HUGGGGE boost in performance. With the CN lite V7 it was 450W/H (CPU + GPU), now 570W/H (CPU + GPU) with CN ultra lite.

Among my RX570s, one has a much weaker ASIC than the others, so I had to reduce the intensity compared to the other GPUs, otherwise it hangs out after less than 30mn mining. So the weak one intensity is 960, the others including my beloved little Sapphire ITX is 1008.

The network fee is ridiculously low (love it ), 0.03TRTL for a >10K payment by the pool.



Thanks to JCE for the amazing miner, thanks to TURTLECOIN devs for really taking care of their mining community

FPGAs will have even more impressive boost with this low-mem algo. Don't worry ))) Only heavy type algos leave hope for gpus

[JCE-Miner]

This may be true for any algo...
On TRTL v2, a AES cpu is close to an asic: all instructions are native (the 128-bits multiply, the 64 bits divide, the squareroot, and of course the AES) with all data fitting into the cache, assuming you have a decent CPU (read: not an Atom).

The next release will default Turtle to v2, as it has just forked, and will enable it among the eligible algo for pool autoswitch.
I'll release CPU version first.

As an exception, i'll ship the new Graft fork right now, with no test on a real pool (tested only on a local node). As --variation 22.
Sorry Unclwish I won't delay the release to investigate your bug since the Turtle fork is somewhat an emergency issue.

[UnclWish]

Sorry Unclwish I won't delay the release to investigate your bug since the Turtle fork is somewhat an emergency issue.

Ok-ok. I'll wait. Note that cards are both RX 580 8Gb. Now I forced to set 2nd GPU 1 thread and 16 multi_hash to start mining at 1st GPU and 2nd GPU almost free, but even 1x16 gives some load on 2nd GPU...

[JCE-Miner]

A 33q CPU is online but I just noticed a bug when mining Masari v8 on a AES cpu with multi-hash=2 (reported on Github).
So I re-release it with the fix included. If you already downloaded 33q, wait a bit and redownload. The linux and GPU version will be released with the fix directly.

edit: it's fixed now. Then come the Linux and GPU version. I'll still give a try to reproduce Unclwish bug.

[HardKano]

Now I focus on CN-Waltz for Graft, which is a cleaner and better documented fork.

God thanks ! And thanks Graft (soon another name) project ! ... Will be huge in few years ! Hope the effort you put it will reward you in the long term

[rednoW]

Guys, what results should one expect on TRTL v2 with polaris and vega? I have 8.2khs with rx578 micron 1200/2140@900mV and 15.5 khs with vega 56 hynix 1380/1050@875mV with another miner.
Should I expect boost with jce?
BTW, my R5 1600@3.8ghz is doing nice 10khs )) Thanks, JCE

[Iamtutut]

Guys, what results should one expect on TRTL v2 with polaris and vega? I have 8.2khs with rx578 micron 1200/2140@900mV and 15.5 khs with vega 56 hynix 1380/1050@875mV with another miner.
Should I expect boost with jce?
BTW, my R5 1600@3.8ghz is doing nice 10khs )) Thanks, JCE

Change your settings for the 580. I have 8,5KH/s to 8,6KH/s with my 574s (except the crappy one at 7KH/s with lower intensity). Core 1240, mem 2060 (one at 2035) with 1008 intensity.

No Vega, so I dunno about them. I'm waiting for Navi

[pogadaev]

Dear developers how can I contact you?

[JCE-Miner]

Yes, use the private messages feature of that forum please, i don't use social medias like Discord (too time consuming).
Also, i dev alone, no pural developers

@Unclwish: i mined the same way as you (Nicehash Heavy on GPU 0, one thread) and it worked for me. Sad i couldn't reproduce the bug. What happens when you add parameter --legacy ?

I'm building the 0.33b18 GPU, with the same changes as CPU:

* Fix Masari v8 bad shares
* CN-Waltz fork
* Turtle defaults to v2

edit: it's online now