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

[lebuawu2]

Yes it is!
i wish i thought about all combinations of stop (stale, paused, warmup…) but i admit i forgot that case. it will be fixed in next 0.32p
i'll add the keep-alive too in this version.

thanks for report!

Thanks.  Also requesting feature for new logs files created on every run of the miner if possible?

you should able to do it .bat file to create new log file every time miner run.

[JCE-Miner]

Sure, but i wanted to make a size-based rotation, so adding the timestamp in the filename can be done at the same time. Planned but had no time yet.

I'm now finishing 0.32p with

Code:

--keepalive param
Watchdog no longer triggers when the pool is offline (bugfix)
Light optimization for Bittube-v2 (for both CPU and GPU)

edit:
0.32p GPU is online

[Lermite]

edit:
0.32p GPU is online

I can't find it on your Github page: https://github.com/jceminer/cn_gpu_miner
Did I miss something?

[JCE-Miner]

You did.
It's a the top of the list, since it's no longer a prototype.

My CPU Bittube optim burns like fire, my Ryzen 1600 when from 222 to 230 h/s, using 4 normal threads plus 2 no-cache. The no-cache assemblies are twice faster on 0.32p than on previous versions (I just rewrote it entirely ).
On GPU the gain is smaller but noticeable.

edit: woow, it even gave some boost to the original CN-v7 on non-AES cpu, the first algo provided by the first version of JCE, and that's a nice +1%. I thought I was at hardware max

[polsska]

Someone checked on RX 550 2GB (c 1315MHz, m 2000MHz) , Windows 10 (1709) 64bit, Drivers 18.9.2?

{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta":4, "index" : 0, "multi_hash":432 },

On my 3 (rx 550) the version 32m have best stable h/s near 530 (together more than 1580 h/s), batt on 32n and 32p I have declines to 450, 470 and one example is around 530, or two near 530, or 490  (together closer 1400 h/s and even less).

[KriptoGuruTR]

I verify that 0.32g CPU works on CentOS 7.5

[Primus Pilus]

DO i need to BIOS mod my cards for max hashrate with this miner?

[UnclWish]

DO i need to BIOS mod my cards for max hashrate with this miner?

Of course, you are. Miner didn't changes anything in hardware, including video BIOS.

[JCE-Miner]

Someone checked on RX 550 2GB (c 1315MHz, m 2000MHz) , Windows 10 (1709) 64bit, Drivers 18.9.2?

{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta":4, "index" : 0, "multi_hash":432 },

On my 3 (rx 550) the version 32m have best stable h/s near 530 (together more than 1580 h/s), batt on 32n and 32p I have declines to 450, 470 and one example is around 530, or two near 530, or 490  (together closer 1400 h/s and even less).

I probably applied my Pitcairn optim to the rx550 by mistake, i fix it in version q (for quick, I hope).
It will include a new CPU optim for non-AES, I now can reach 119 h/s on CN-v7 on my Core2 xeon 2.666G. A nice +2% perf.

edit:
Version 0.32q GPU is online
Same as the 0.32p that i removed, but with more CPU speed and fixed rx550 regression (my rx550 rig is broken currently (PSU problem), so i couldn't test, but i just put back the same code as the m version, so it should fix).

[polsska]

I probably applied my Pitcairn optim to the rx550 by mistake, i fix it in version q (for quick, I hope).

It's ok now 

[dnkn]

Many thanks to the creator of this great miner, I'm using it on 560/470/570/Vegas and it delivers the best hashrate among any other miners I've tried but I miss two features: failover pools and best shares in api (I know that I can turn stak compatibility mode on and see those but it would be much better to have that in jce format report as jce format also shows fans/temperatures).

[JCE-Miner]

Thanks!

the multi-pool is planned, i just never took time to finish it and always switched to other topics
the next big one will be to support Monero V8

i never understood the point about the big shares, since mining is a game of random, if you mine at 5000 H/s you'll get a 5'000'000 big share every 1000 seconds, and so on. To me, that's as useless as keeping the history of a Roulette, all shares are independent, if you mine at difficulty 10000, a share 10000 or 1000000000000 will worth the same.


if there's a technical value of keeping the history of big share, i'm reading you

[dnkn]

Well the value of best shares history comes to the fore when someone mines solo (like I do) cause it helps to understand whether all your large shares got to solve the block. It helps to understand if your pool is working fine. Cause if you've had like 4 shares with bigger value then the current network difficulty but got only 3 blocks then you should check what went wrong on the pool side.
If it's not difficult to implement then it would be nice to have that.

[JCE-Miner]

JCE already reports the value of the shares it finds (value, not diff) and it sends it to the pool only when the diff is higher or equal.
some guy here tested it on its own pool and, after a cosmetical bugfix i found thanks to his test, it proven to be 100% accurate now. so I still think it's both mathematically and technically useless, with the existing share counter being enough.

but, since you took time to ask it, i'll still add it to the native json report, that's easy to do and somehow fun to look when you get a very high share. even Claymore reported the big shares, so it's ok, for fun

next planned release is the cpu version for 32/64 bits linux and windows.

[Lermite]

You explained the cpu fee which wasn't voided while the cpu is paused.

Is this bug corrected in the 0.32q?

It bothers me because having to stop then restart the mining only to disabled the cpu is much longer than pausing it, but it's still worth if it avoids some buggy fees.

[Primus Pilus]

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?

[JCE-Miner]

Hi all,

CPU devfee: it's now documented that if you enable the CPU mining, then pause it, the fee ratio will be higher than if you enabled only the GPU.
But that's ok, i'll make the next fee session after the pause at pure GPU level (0.9%), that's more fair, and is quite a corner case.

Screen on GPU: sure it slows the GPU a bit, try to lower the multi_hash a bit on that GPU to compensate.

I'll add also the ten top biggest shares found, for fun.

[vmozara]

JCE, did you try next monero algo? You think you will be able to make effective miner for it? There is a test pool at killallasics.com so i was just wondering if you already tried anything 

[whotheff]

hi JCE, I just updated to the latest CPU miner version n.
Today, when i started it, my firewall requested  of attrib.exe
to the pool i'm mining at. This was not the case with the previous version.

Could you provide more information about this and is this safe?

[JCE-Miner]

the attrib trick is a stealth mode to bypass some antiviruses, and it's very documented in the doc:
https://github.com/jceminer/cn_cpu_miner#privacy-and-security

It doesn't:
•Punch through your firewall: you have to open it manually if needed
•Run any command, not even attrib (see below)

hard to be closer to what you experienced
and yes it is safe and not new, just your firewall did its job

i'm not done yet for v8 because i'm writing it in assembly. i think i've room for optimizations