Topic: [XMR] JCE Miner Cryptonight/forks, now with GPU! - page 6. (Read 90841 times)

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

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

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

https://bitcointalksearch.org/topic/cpu-jce-miner-cryptonightforks-brand-new-super-fast-5103137

I reported him, so should all JCE users.

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:

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.

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

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

This is very summarized, but not wrong

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

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

Cool JCE ! Real life and bills to pay ! I hope your miner will get more traction and you might be able to retire and live from developing it 😎

Hi all,

first i apologize for the long offline period, but this year i've clearly a lot less time to dev and provide support, as you may have noticed, and it's unlikely it will get better. I don't just give up but the daily releases of december won't happen again.

Quick support:
100% cpu on GPU mining: this is very not the normal behavior, try to add --low --legacy params

new algos
Graft: i'm waiting to see if that's still close to Monero, or a very different fork like Webchain
Masari: as i expected, this is just the same as Stellite v8, so you can already mine it with --variation 21

Still, i'll release new versions with this fork as the default fork for masari wallet (ditto for Stellite) plus the option to restart the miner instead of quit when the watchdog triggers.

HI JCE, What about massari fork ?

...config please!

and also with --no-cpu the cpu is on 100% - thats why also is laggy

trtl algo give 16000hr on vega 56

@JCE-Miner : you should follow it for your GPU software update and test it before they implement it. Graft will create their own algo : https://www.graft.network/2019/01/23/nicehash-attacks-update/

tried new GPU Version with TRTL - Vega auto settings give only 4khs on each vega...tried my old cn_lite config...same Hs

the miner hiimself runs realy realy slow (pressing h = it need some seconds for displaying the hs rates).

whats wrong? it should run with --auto (not optimized but better than 4khs)

Hey JCE,

Any plans of speed improvement and maybe algo switch on GPU?

Hi all!

Virus: sure, false positive, as with any other miner ever. There's no malicious behavior at all, it's a miner, it mines, period. Just be sure to download it from the github, otherwise the fake ones from Mega are trojan. I'm not related with them in any way, and they are online from almost the very first release of JCE in ~april 2018

Process control: you can pause all devices, and even close the miner itself remotely
Config edit: it's possible in an indirect way, with edition of file serviceconfig.txt (which may be a symlink to a remote file) and then restart. This way you can edit in any way: change pool, number of cpu, whatever.

@maedonald
there's a watchdog to close the miner in such case --watchdog N with N the minimum GPU hashrate (ignoring CPUs).
I didn't implement the restart because i experienced it to always fail with Claymore (the restart froze the miner or the whole PC).
But right, in next GPU version i'll add the option to make the watchdog restart instead of close, since it's a popular request.

Linux crashes: very interresting report. On a modern Ubuntu x64, the casual case. There may be a mem leak that doesn't show in the Windows version.
Did you use SSL? and/or Nicehash? The keepalive?
Those 3 params have an impact on the netcode. The main mining code is just a loop that hash and rehash on the same piece of ram, no allocation. But the netcode plays with the memory.

With my usual config, I get around 7.5KH/s with Stellite v5 algo. It's power hungry at 540W/h
Config is 4 RX 574 with bios mod.

Read the doc, it's a false flag.

No issue

Trying to set up your miner and have a look.

The jce_cn_gpu_miner64.exe is identified as "Win64/Packed.Enigma.Q" by ESET. "Enigma" and "trojan" are 2 things I want my computer far away from.
I know that all mining software give false positives but having an alert from my antivirus for a known trojan that encrypted everything and asked for ransom is not a pretty site.

Any inputs on this?