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

[varusisog]

JCE, didn't you thought about making ethereum miner? About a week it's more profitable than any cn algo on 470/480/570/580 cards...

I think it is less profitable as the emission is changed from 3 to 2 ETH per block.

[mimainer777]

Please, add key to rig identifier for pool-side statistics.

[JCE-Miner]

Hello all:

crash: please look at your antivirus and related (antispyware...) it may have corrupt/quarantined the binary since it's always detected as a virus, like all other miners. The attrib trick is documented and works this way since day one.
Maybe try to run the CPU 32-bits versions, it's a lot less detected. Just to test, as it mines slower.

ETH: above any financial consideration, it just would be hopeless to compete with Claymore, who's just the best referenced, and technically the best. I would have like zero users, assuming i could make a working miner.

The GPU miner can mine cpu-only on Win7, even if pointless. At least it should start.

key to rig identifier

Yeah that's simple and nice to have, good idea.
I'll add the new Stellite, but no urge. I'd like to get a test masari pool to release both, every upload is 10M and i'm flooding my github history

[sharix80]

What about webchain???

[_ap_]

crash: please look at your antivirus and related (antispyware...) it may have corrupt/quarantined the binary since it's always detected as a virus, like all other miners. The attrib trick is documented and works this way since day one.
Maybe try to run the CPU 32-bits versions, it's a lot less detected. Just to test, as it mines slower.

thx for your answer.
my antivirus quarantined it immediately, so my first thing was to add to the exceptions. now i downloaded again, but nothing changed.
the cpu 32 bit version works, but after I close the program, crash.

the gpu version available only 64 bit, right?

*update
problem solved. av exceptions isn't enough. I added the miner to the trusted files, now everything ok.

[pbfarmer]

@JCE-Miner - I think there's a bug w/ mixed GPU + CPU mining.  The CPU portion seems to not only not be counted in your effective total, it doesn't show on the pool side either - seems like it's just missing altogether, other than in the hashrate report section.  I've monitored this over several weeks as a combined process, and have witnessed the problem over multiple rigs.  In the past couple days, I've isolated the two miners into separate processes, which now results in the proper effective and pool-side hashrates.  This may just be a Ryzen issue - I can't definitively say it happens w/ Intel CPUs, as the one I'm using has such a low h/r, it's hard to tell if it's included or not.

I also realize the hashing power difference between CPU threads and GPU threads could cause the CPU to have lower output on a difficulty suited to a GPU rig, but again, I've monitored this over weeks (if not months,) over multiple versions, and its pretty reliable that the CPU h/r simply never appears in the actual results.

[JCE-Miner]

@pbfarmer: i'll redo some tests, but when you mine with the CPU+GPU, do you get some message like

CPU thread N finds a share, value XXX
Accepted by the pool

If yes, so the shares went to the pool, and were accepted.
I've a Ryzen + AMD RX rig so i will be able to do the exact same test.

Try pressing R key to get the effective hashare of each device. CPU should not be zero, unless it has a negligible hash speed compared to the GPUs. But a Ryzen is quite poweful.

Not that the pool connection and fee sessions are global, not per-device, so it cannot be something like CPU disconnected or stuck in fee session. Otherwise you would have zero hashrate on all devices.

please tell what coin you mine on what pool, so i can do an more precise test.

webchain: no support planned, that's not a good algo for CPU, and i don't like how they changed the CN netcode conventions just because they could. Same for Hycon. Both coins can be mined with the CPU reference xmrig fork (possibly recompiled with zero fee), or on GPU with SRB.
I may add them later, but i'm getting less dev time those days and i need to choose between what i support or not. Currently i'm finishing the Stellite v8 fork.

[Iamtutut]

JCE, I've posted the Stellite test mining pool, did you find time to test your miner with the new algo ?

[JCE-Miner]

i'm polishing the test right now.
And this fork is a good fork for CPU mining, with a half main loop. Good for AES CPUs.

Ryzen +GPU test, on the default pool

Code:

13:53:18 | Pool changes Difficulty to 35790.
13:53:19 | GPU 0 Thread 8 Lane 182 finds a Share, value 35790
13:53:19 | Stale Share that may be refused by the pool.
13:53:19 | Accepted by the pool in 68 ms.
13:53:21 | CPU Thread 6 finds a Share, value 35790
13:53:21 | Accepted by the pool in 105 ms.
13:53:33 | Pool pool.monero.hashvault.pro:3333
13:53:33 | Reconnections 0
13:53:33 | Currency Monero (XMR/XMV)
13:53:33 | Current pool Difficulty 35790
13:53:33 | Accepted Shares 12
13:53:33 | Total Hashes 347490
13:53:33 | Miner uptime 0:03:56
13:53:33 | Effective net hashrate 1472.42 h/s
13:53:33 | Devices results - Shares Accepted/Ignored/Rejected - Net Hashrate
13:53:33 | * CPUs  - 2/0/0 - 215.21 h/s
13:53:33 | * GPU 0 - 2/0/0 - 341.95 h/s
13:53:33 | * GPU 1 - 3/0/0 - 330.51 h/s
13:53:33 | * GPU 2 - 5/0/0 - 584.75 h/s

On 3 minutes the hashrates didn't converge well, but my CPU, as fast as each GPU (3x stock RX560) gave similar results.
So far it looks to work, please look for those log patterns:

Code:

13:53:21 | CPU Thread 6 finds a Share, value 35790
13:53:21 | Accepted by the pool in 105 ms.

if there are, so it works.
Also try to add parameter --legacy which helps to lower the CPU pressure when mining on GPU+CPU (at the cost of a very little loss on GPU side, but better perf on CPU). It may have more or less effect (if any) depending on your rig.

I also fixed a bug that made JCE identify itself pool-side as MultiMiner 1.4, a stub i made to test the Pool Autoswitch on Monero Ocean and that i forgot to revert. It's very negligible, i just warn in case you observed such a change pool side. Will be in next version. I'm also adding the rigid key at pool login

[indiainside]

How configure no cpu usage command. Also .exe file in different version are different..!!!

[Samenes1953]

Whats the progress?

[JCE-Miner]

exe file: I don't get it... sure each release has a different exe file, that's the purpose of the updates...
progress: i'm not sure of what you ask for, but the next release will get :

Stellite v8 available as --variation 21
--rig-id parameter, to set rig-id on pool
miner agent id fixed

Do you need it or I can wait for the Masari fork too? That would be a minor release and the fork is not useful yet, except for tests.

edit: tests done, and the CPU perfs are quite good. Will be version 0.33n but i won't release it yet, since the changes are too minor. If a coin already uses Stellite v8, or a Masari test pool exists somewhere, please tell me

[indiainside]

Command for disable cpu mining on JCE

[lebuawu2]

Hi JCE,

most likely ETH will switch to ProgPow, so are you planning to support ProgPow in your miner?

Thanks.

[xsoft]

Just checking .. but you don't have a GPU version for Linux, right?

by https://github.com/jceminer/cn_gpu_miner, "No Linux version (possible but unlikely)"

[JCE-Miner]

ETH: that's very different from CN, the whole miner not just the algo. i didn't have time to add webchain, i really cannot redo a miner from scratch

disable cpu: --no-cpu param.

i'll clean the github doc to state there won't be a gpu linux miner. cpu linux exists.
i advise you use TeamRed for Linux, it's great!

[TheMenda]

Any hopes on implementing nVidia GPUs compatibility?

[UnclWish]

Hi JCE! Doc releases new version of his miner and added thread_delay option. It can be changed manually for each GPU. Is this is what your miner does during warm-up? It try to find best thread delay? Delay between starting mining on 2 or more threads on one GPU?

[JCE-Miner]

nVidia: no there won't be sorry.

delay: that's an option that already exists in xmrstak, with a default of 40%. in jce this is automated, and yes it's related to the warmup. i won't add it as manual param, i'm confident with my automated values.

[UnclWish]

delay: that's an option that already exists in xmrstak, with a default of 40%. in jce this is automated, and yes it's related to the warmup. i won't add it as manual param, i'm confident with my automated values.

Right! Automated delay is better than manual tuning...