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

[monote]

Jumps to 400k ?
It's similar to a previous bug I already fixed about the share counter (which was a cosmetical but misleading bug). And again, only for CN-Heavy. I'll take a look back once i'm done with the Watchdog.

Yeah, actually taking a closer look, it did arrive to 1.5m diff...
Btw, I'm using 32f version of the miner cause I don't know why, last version wasn't stable for me.
After some time one of the cards randomly stops and resets its clocks to 300mhz...mega weird...
Anyways, this doesn't happen (like NEVER) using 32f miner version

Cheers mate!

[wyzdic]

--bus-order
It's very nice feature:P, JCE gpu list same with hwinfo now.

[JCE-Miner]

It should have been the default order, but I wanted to be somehow compatible with claymore 9 and Stak (which also used OpenCL order). And now changing the default could cause chaos with existing configurations.

[lebuawu2]

Hi JCE,

thanks for additional report how many re-connection occurs (with that I can check if the hash rate drop mostly because of connection drop).

recently I tried driver 18.6.1 and 18.8.1 with JCE 032h or 032j (heavy algorithm) but it instantly crash if all 8 or 10 GPU I used, but if I only configure 6 GPU it's fine. can you please help to take a look of this problem?

driver 18.3.4 with JCE 032h or 032j (heavy algorithm) everything fine with 8 GPU or 10 GPU.

Thanks.

[lebuawu2]

It should have been the default order, but I wanted to be somehow compatible with claymore 9 and Stak (which also used OpenCL order). And now changing the default could cause chaos with existing configurations.

I believe you are referring to Claymore cryptonote, because Claymore ethash since version 9.6 already sorted by bus id.
yes we need to change the config if in one rig contains different GPU type, but I still prefer with order by bus id because of GPU-Z, HWInfo, OverdriveNTool they order by bus id.

[lebuawu2]

Jumps to 400k ?
It's similar to a previous bug I already fixed about the share counter (which was a cosmetical but misleading bug). And again, only for CN-Heavy. I'll take a look back once i'm done with the Watchdog.

Yeah, actually taking a closer look, it did arrive to 1.5m diff...
Btw, I'm using 32f version of the miner cause I don't know why, last version wasn't stable for me.
After some time one of the cards randomly stops and resets its clocks to 300mhz...mega weird...
Anyways, this doesn't happen (like NEVER) using 32f miner version

Cheers mate!

it's a bit strange because for me static diff work perfectly with miner.rocks.

[Lermite]

I have an issue that I've already explained to JCE on a french forum, but I'd like to know if I'm the only one.

It happens with every 0.32 versions and only on Cryptonight V7 (--variation 3): each connection attempt to the pool fails.
All the other algos (CN Light, Heavy, Saber,...) work fine with the 0.32 versions. The issue only concerns CN V7.

The culprit is not my firewall because disabling it has no effect on the issue.

Am I the only one to have to use the 0.31f to mine CN V7?

[lebuawu2]

I have an issue that I've already explained to JCE on a french forum, but I'd like to know if I'm the only one.

It happens with every 0.32 versions and only on Cryptonight V7 (--variation 3): each connection attempt to the pool fails.
All the other algos (CN Light, Heavy, Saber,...) work fine with the 0.32 versions. The issue only concerns CN V7.

The culprit is not my firewall because disabling it has no effect on the issue.

Am I the only one to have to use the 0.31f to mine CN V7?

you can try telnet to your pool and port you are using from command prompt, if you are able to connect then should be good.
you also can try other pool just to check.

telnet xmr-asia1.nanopool.org 14444 that is the example if your pool is nanopool and you are using port 14444.

[Lermite]

you can try telnet to your pool and port you are using from command prompt, if you are able to connect then should be good.
you also can try other pool just to check.

telnet xmr-asia1.nanopool.org 14444 that is the example if your pool is nanopool and you are using port 14444.

Telnet runs fine and such does jce_cn_gpu_miner64.exe 0.31f or older.

The issue only occurs on 0.32 versions (from 0.32a to 0.32j) and I can't understand why, especially why it only affects the Cryptonight V7 (--variation 3).
I've also tried to replace the .exe in the same directory, but the result is the same.

[Sx5000]

Am I the only one to have to use the 0.31f to mine CN V7?

I also use version 31f, but for another reason. All versions after do not restore the maximum speed in case of disconnect on my rig from 12 550. Versions after 31f do not always have time to give the cards to the maximum speed in the allotted time. On version 31f some cards go to the best mode only for 30 minutes, but they do it! I'm writing this about the fast algorithm. http://prntscr.com/knwz2e

[Iamtutut]

Am I the only one to have to use the 0.31f to mine CN V7?

0.32G for me. I sometimes mine graft.

[JCE-Miner]

There were some netcode changes on the 0.32+, i'll revert some of them in next 0.32 (probably k) betting it could fix the regression. But there's no code specific to an algo, except Nicehash. What may happen is that some pools use a proxy internally when the datarate is huge (like xmrig-proxy) that is detected and blocked by my netcode. I forbid use of proxy for security reason, to avoid being turned into stealth botnet (even if it applied more to the cpu version, i don't think there are GPU botnets). So i'll relax a bit the detect.

give a try to a simple pool like xmrpool.eu, which is cn-v7, it works for me on 0.32, same for hashvault.pro for example (tested on graft and xmr).
The difference is not about the algo, but about the pool network config, which may conflict with my security.

Claymore cryptonote

sure

driver 18.3.4 with JCE 032h or 032j (heavy algorithm) everything fine with 8 GPU or 10 GPU.

i experienced that regression on my simple 3 cards rig when upgrading from 18.6 to 18.8

Try to lower a lot the multi_hash, even if it causes perf regression. Like use 75% of previous allocation, for test. I expect it then runs stable. Then increase back by steps of 16. The later are the AMD drivers, the less memory I can allocate staying stable.

[Lermite]

give a try to a simple pool like xmrpool.eu, which is cn-v7, it works for me on 0.32, same for hashvault.pro for example (tested on graft and xmr).
The difference is not about the algo, but about the pool network config, which may conflict with my security.

I had the issue while mining XCA on three different pools.
I actually have it too while mining XMR on XMRPool.eu. I tried three different ports: 3333, 5555 and 7777.

That's why I concluded the issue was related to the algo but if the 0.32+ works fine on XMRpool.eu on your setup, and as I'm apparently the only one to have it, the issue must be related to my setup, but I have no clue of its cause or location.
I tried to disable the firewall and I don't even have any antivirus running.
I even compared 0.31f and 0.32j on another computer, and the same issue pops up with 0.32j while the 0.31f runs fine.

My log has a weird line "Successfuly logged" because all the others claim the connection fails:

Code:

20:56:12 | Socket connect error: Cannot reach pool on Internet, is your connection up?
20:56:12 | Connected to pool. Now logging in...
20:56:12 | Unloaded OpenCL kernels of GPU Thread 10
20:56:12 | Unloaded OpenCL kernels of GPU Thread 11
20:56:12 | Unloaded OpenCL kernels of GPU Thread 8
20:56:12 | Released OpenCL Thread 8 Scratchpad at 000002b62258d6d0
20:56:12 | Released OpenCL Thread 10 Scratchpad at 000002b62986fcb0
20:56:12 | Released OpenCL Thread 11 Scratchpad at 000002b62ccf56e0
20:56:12 | Unloaded OpenCL kernels of GPU Thread 9
20:56:12 | Released OpenCL Thread 9 Scratchpad at 000002b62986ec30
20:56:12 | Released OpenCL Thread 10 Command-Queue of GPU 1 at 000002b6226a51a0
20:56:12 | Released OpenCL Thread 8 Command-Queue of GPU 0 at 000002b6226a5c20
20:56:12 | Released OpenCL Thread 11 Command-Queue of GPU 1 at 000002b6226a56e0
20:56:12 | Released OpenCL Thread 9 Command-Queue of GPU 0 at 000002b6226a5830
20:56:12 | Successfuly logged as [my_XMR_wallet].100000+PC40
20:56:12 | Released OpenCL Context 000002b62239b2d0 of GPU 0
20:56:12 | Pool connection socket closed.

If I block the connection with the firewall, I get another log:

Code:

21:04:07 | Connection failed: Socket connect error: Une tentative dӡcc鳠ࡵn socket de mani鳥 interdite par ses autorisations dӡcc鳠a 굩 tentꥮ 
21:04:07 | Connection interrupted, waiting 5s then retry, attempt #1
21:04:23 | Connecting to mining pool xmrpool.eu:5555 ...
21:04:23 | Connection failed: Socket connect error: Une tentative dӡcc鳠ࡵn socket de mani鳥 interdite par ses autorisations dӡcc鳠a 굩 tentꥮ 
21:04:23 | Connection interrupted, waiting 5s then retry, attempt #2
21:04:28 | Connecting to mining pool xmrpool.eu:5555 ...
21:04:28 | Connection failed: Socket connect error: Une tentative dӡcc鳠ࡵn socket de mani鳥 interdite par ses autorisations dӡcc鳠a 굩 tentꥮ 
21:04:28 | Connection interrupted, waiting 5s then retry, attempt #3
21:04:33 | Connecting to mining pool xmrpool.eu:5555 ...
21:04:33 | Connection failed: Socket connect error: Une tentative dӡcc鳠ࡵn socket de mani鳥 interdite par ses autorisations dӡcc鳠a 굩 tentꥮ 
21:04:33 | Connection interrupted, waiting 5s then retry, attempt #4
21:04:38 | Connecting to mining pool xmrpool.eu:5555 ...
21:04:41 | Connection failed: Socket connect error: Une tentative dӡcc鳠ࡵn socket de mani鳥 interdite par ses autorisations dӡcc鳠a 굩 tentꥮ 
21:04:41 | Connection interrupted, waiting 5s then retry, attempt #5

[JCE-Miner]

Ok i got it, thanks to your log. And yes, that's my anti-proxy heuristic that is too strong (unless you're a shadow hacker ) This is why it locks the connection, and then, with no way to mine, the miner stops by itself. I cannot give more explanations or it will cancel the principle of a anti hack protection, but that's it.
I'll relax it in next version.

[korm]

After switching to a new algo, all the miners began to work badly on old HD6870. This one is the closest to Clay9.7 
But with RX460, it works worse than the srb. I do not know why

[JCE-Miner]

I explicitly benched my miner against Claymore 9.7, and i also explicitly said i couldn't beat it, by an order of magnitude. It can push my HD7850 1G to 450, i cannot go above 370 but yes, i'm still second, other miners are still worse. But i found jce a lot more stable than Claymore 11.3 and faster on cards with 2G+ memory.

On RX550 and RX560 jce should be the best if configured properly, which include waiting for 5-10 minutes after each start to let it warm up.
On RX460 2G use multi-hash 416, 432, 448 or 464, worksize 8, alpha 4 or 8, beta 64. On 4G, use same and multi_hash 464.

Otherwise try the 0.31e, the most stable so far, it takes ages to compile its opencl but may mine a bit faster than 0.32 in some cases.

[whotheff]

Hi JCE, please check this thread:

https://bitcointalk.org/index.php?topic=2361848.3440;topicseen

And provide a way to dual mine Cryptonight 7 + RoI coin using JCEminer.
Thanks!

[heavyarms1912]

1272 H/s on Bittube.  Peaked 1312 H/s on an RX 570 8GB.

[darklus123]

Just started mining using

NVidia gtx 105ti gpu
i3 7th gen
with 8gb ram

current hash rate 64.5h/s using only the cpu


Sorry Mining is a new thing for me how much coin can I expect from this power. How can I switch the mining to GPU btw?

I already did use the gpu prototype but still it is mining using my cpu power

[wyzdic]

Just started mining using

NVidia gtx 105ti gpu
i3 7th gen
with 8gb ram

current hash rate 64.5h/s using only the cpu


Sorry Mining is a new thing for me how much coin can I expect from this power. How can I switch the mining to GPU btw?

I already did use the gpu prototype but still it is mining using my cpu power

only AMD cards. You can use xmr-stak for nvidia cards.