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

[alumar]

Just posted a quick video on YouTube of the testing of the AMD Ryzen 2990WX and gave a shout out to JCE Miner

https://www.youtube.com/watch?v=87mHny7PZME

Cheers

[vmozara]

 

2.5kh/s is really, really nice

If you don't mind, I will post a link to your video on reddit, may I?

[monote]

Hey JCE-Miner (and everybody).
I'm using 32f version for GPU and static diff option (using the dot ".") after the address
doesn't seem to be working...

Someone has the same problem ?
Apparently it is supported by the miner (and also by the mining pool...)

Cheers!

[nordmann666]

Hey JCE-Miner (and everybody).
I'm using 32f version for GPU and static diff option (using the dot ".") after the address
doesn't seem to be working...

Someone has the same problem ?
Apparently it is supported by the miner (and also by the mining pool...)

Cheers!

which pool?
some pools want "+" instead of "."

[Sanguintan]

That's the fastest on CPU and on some GPU cards like RX550/560.

And the fastest and most stable Vega miner, the fact that you should really start to promote a lot more 

Has anybody tried it on R9 390?

[monote]

Hey JCE-Miner (and everybody).
I'm using 32f version for GPU and static diff option (using the dot ".") after the address
doesn't seem to be working...

Someone has the same problem ?
Apparently it is supported by the miner (and also by the mining pool...)

Cheers!

which pool?
some pools want "+" instead of "."

I'm mining veronite (pool.veronite.space), and yeah, I tried both "+" and "." but nothing works...
When using other miner, for example xmr-stak, it does work...

[JCE-Miner]

not me
i've nothing between my old HD7000s and my RXs

The trailing dot, plus or any symbol is tolerated and ignored to detect the coin. And all is passed as-is to the pool.

I strongly recommend 18.6 drivers for RX560, later drivers caused either crash or perf regression on my rigs.

Impressive video about the Threadripper
I note all AMD CPU, even back to the AM3/FM2 sockets, have a performance of about 75 h/s per mining core. But the Athlon x4 can use only two cores (because it has 4M cache) while your threadripper uses 32

I couldn't blind-find the Numa node bug, the node are simply requested from the OS. But since the threads don't share memory (except in the rare case one use the Dual-thread mode for older CPUs) the performance impact of using the wrong Numa is very low.

About the bad CPU counter, i also rechecked all and found no more bug, please in your config go back to a simple numbering from 0 to N. If you kept the indices 0-15 then 64-79 the miner won't start because your 32 cpus are 0-31

Done the 0.32i, now testing

Code:

Lag timer when a share is accepted/rejected by the pool
The yellow hashrate is now called "net hashrate" to avoid ambiguity.
** Key: Yellow=pool-side net results, Blue=instant hashrate, Purple=Hardware GPU status.
New coin: Veronite
New param: --bus-order to order GPUs by bus-id.
Fixed Vega detection

Next big feature will be Watchdog.

I'm mining veronite (pool.veronite.space), and yeah, I tried both "+" and "." but nothing works...

Veronite is to be added in the upcoming 0.32i, meanwhile you can mine with parameter --any --variation 5
let me check on that pool, it will be a good test for the new native Veronite support

edit, tried with current version (the wallet is a dummy one):

Code:

jce_cn_gpu_miner64.exe --auto -u VERayYXDx83WepmMzP5JWkXUqdu578QJ9dEnTpJfSKR2E5vfKM2dPnyfNACMjxLbZnYdPNf3HwTbtbxxEvDniXaGGxTurqtziGs.10000 -o pool.veronite.space:3333 -p x
Wallet does not match any of the supported currencies,
or your wallet couldn't be recognized.
Either use both the --any and --variation N parameters, with N one of:
  1 = Original Cryptonight
  2 = Original Cryptolight
  3 = Cryptonight V7 fork of April-2018
  4 = Cryptolight V7 fork of April-2018
  5 = Cryptonight-Heavy
  6 = Cryptolight-IPBC
  7 = Cryptonight-XTL fork of May-2018
  8 = Cryptonight-Alloy fork of May-2018
  9 = Cryptonight-MKT fork of May-2018
 10 = Cryptonight-Arto fork of May-2018
 11 = Cryptonight-Fast MSR fork of June-2018
 12 = Cryptonight-Haven fork of June-2018
 13 = Cryptonight-BitTube v2 of July-2018

Expected, and it says what to do: add --any --variation N with N=Cryptonight-Heavy=5

Code:

jce_cn_gpu_miner64.exe --auto -u VERayYXDx83WepmMzP5JWkXUqdu578QJ9dEnTpJfSKR2E5vfKM2dPnyfNACMjxLbZnYdPNf3HwTbtbxxEvDniXaGGxTurqtziGs.10000 -o pool.veronite.space:3333 -p x --any --variation 5
...
17:14:54 | Connected to pool. Now logging in...
17:14:54 | Successfuly logged as VERayYXDx83WepmMzP5JWkXUqdu578QJ9dEnTpJfSKR2E5vfKM2dPnyfNACMjxLbZnYdPNf3HwTbtbxxEvDniXaGGxTurqtziGs.10000
17:14:54 | Pool changes Difficulty to 10000.
17:14:57 | Pool sends a new Job.

[JCE-Miner]

0.32i online - minor version

Code:

Lag timer when a share is accepted/rejected by the pool
The yellow hashrate is now called "net hashrate" to avoid ambiguity.
** Key: Yellow=pool-side net results, Blue=instant hashrate, Purple=Hardware GPU status.
New coin: Veronite
New param: --bus-order to order GPUs by bus-id.
Fixed Vega detection

[monote]

I'm mining veronite (pool.veronite.space), and yeah, I tried both "+" and "." but nothing works...

Veronite is to be added in the upcoming 0.32i, meanwhile you can mine with parameter --any --variation 5
let me check on that pool, it will be a good test for the new native Veronite support

edit, tried with current version (the wallet is a dummy one):

Code:

jce_cn_gpu_miner64.exe --auto -u VERayYXDx83WepmMzP5JWkXUqdu578QJ9dEnTpJfSKR2E5vfKM2dPnyfNACMjxLbZnYdPNf3HwTbtbxxEvDniXaGGxTurqtziGs.10000 -o pool.veronite.space:3333 -p x
Wallet does not match any of the supported currencies,
or your wallet couldn't be recognized.
Either use both the --any and --variation N parameters, with N one of:
  1 = Original Cryptonight
  2 = Original Cryptolight
  3 = Cryptonight V7 fork of April-2018
  4 = Cryptolight V7 fork of April-2018
  5 = Cryptonight-Heavy
  6 = Cryptolight-IPBC
  7 = Cryptonight-XTL fork of May-2018
  8 = Cryptonight-Alloy fork of May-2018
  9 = Cryptonight-MKT fork of May-2018
 10 = Cryptonight-Arto fork of May-2018
 11 = Cryptonight-Fast MSR fork of June-2018
 12 = Cryptonight-Haven fork of June-2018
 13 = Cryptonight-BitTube v2 of July-2018

Expected, and it says what to do: add --any --variation N with N=Cryptonight-Heavy=5

Code:

jce_cn_gpu_miner64.exe --auto -u VERayYXDx83WepmMzP5JWkXUqdu578QJ9dEnTpJfSKR2E5vfKM2dPnyfNACMjxLbZnYdPNf3HwTbtbxxEvDniXaGGxTurqtziGs.10000 -o pool.veronite.space:3333 -p x --any --variation 5
...
17:14:54 | Connected to pool. Now logging in...
17:14:54 | Successfuly logged as VERayYXDx83WepmMzP5JWkXUqdu578QJ9dEnTpJfSKR2E5vfKM2dPnyfNACMjxLbZnYdPNf3HwTbtbxxEvDniXaGGxTurqtziGs.10000
17:14:54 | Pool changes Difficulty to 10000.
17:14:57 | Pool sends a new Job.

[/quote]


Thanks for the answer man. And yes, it does set the diff to whatever you put after the ".", BUT after mining a bit,
it starts to increase, decrease, etc, as if you don't put anything!

[samvicky]

Starting GPU Mining thread 22, on GPU 3
Created OpenCL Context for GPU 3 at 00000195b06b7950
Created OpenCL Thread 22 Command-Queue for GPU 3 at 00000195b04fea40
Scratchpad Allocation success for OpenCL Thread 22
Allocating big 2400MB scratchpad for OpenCL Thread 22...
Compiling kernels of OpenCL Thread 22...
Compilation of OpenCL kernels failed.
Error: CL_BUILD_PROGRAM_FAILURE Code: s-331.16

Starting GPU Mining thread 23, on GPU 3
Created OpenCL Thread 23 Command-Queue for GPU 3 at 00000195b04ff220
Scratchpad Allocation success for OpenCL Thread 23
Allocating big 2400MB scratchpad for OpenCL Thread 23...
Compiling kernels of OpenCL Thread 23...
Compilation of OpenCL kernels failed.
Error: CL_BUILD_PROGRAM_FAILURE Code: s-331.16


Getting this error on my vega 64. I am on 18.8.1 driver and win 10. I even tried --auto but same issue. I am using the latest 32i but 32h doesnt have this issue,No issues on my 3x Rx 550 2gb cards

[samvicky]

Please have a social media account where we can contact you. Maybe Discord/Twitter..

[lebuawu2]

Hi JCE,

Just want to write some feature request & feedback :
1. Please add feature keep alive option.
2. Please add report in yellow how many miner reconnect to pool after connection drop.
3. Please do warm up again after miner reconnect to the pool.
4. Along with watch dog for next release is it possible to add feature min speed, so if overall hash rate below min speed for 5 min (after the warm up session) than it will restart the miner or windows.

thanks for new feature order by bus id, it really helpful.

[JCE-Miner]

Error: CL_BUILD_PROGRAM_FAILURE Code: s-331.16

Very interresting, i was tracking that bug for a long time, and thanks to your comment, i know it's related to my "vega detect" routine. I fix it and re-release. Bad bug, but good news for me somehow. This error had been reported on github previously, with a different error code but i could check it was the same bug. Thanks !

social media account

Nope, on purpose, i've no time enough to provide a decent real-time support, and opening a ghost, mostly unused Twitter account would be quite lame. I answer on this topic and the Github page, but no social medias.

1. Please add feature keep alive option.
2. Please add report in yellow how many miner reconnect to pool after connection drop.
3. Please do warm up again after miner reconnect to the pool.
4. Along with watch dog for next release is it possible to add feature min speed, so if overall hash rate below min speed for 5 min (after the warm up session) than it will restart the miner or windows.

1. nice to have but Watchdog has higher priority to be dev'ed
2. Very good idea, i do it right now.
3. Sure, stupid i didn't do it before, but it's longer to dev so it will be in version after next
4. This is my definition of Watchdog, just the "min" will default to zero, but you can set any number. On my rigs with my dev prototype (the future 0.32k) it is set to 90% of normal hashrate as "min".

BUT after mining a bit,
it starts to increase, decrease, etc, as if you don't put anything!

I haven't tested explicitely, but some (most?) pools will force a variable diff if you mine too fast or too slow with a fixed diff. Look at the log, if you get a message "Pool changes Difficulty to XXXX." so that's your pool's job, JCE don't change the diff by itself. I'll switch one rig to that pool for a few hours to check for that (but I mine v7 and not Heavy since i've low-mem cards).

edit:
0.32j online - minor version

Code:

Replaces the short-lived buggy 0.32i, and fixes the vega bug, and keeps its features:
Lag timer when a share is accepted/rejected by the pool
The yellow hashrate is now called "net hashrate" to avoid ambiguity.
** Key: Yellow=pool-side net results, Blue=instant hashrate, Purple=Hardware GPU status.
New coin: Veronite
New param: --bus-order to order GPUs by bus-id.
(really) Fixed Vega detection
Added reconnection counter in yellow report (and in JSON report)

[samvicky]

Can you make jce gpu miner compatible for this
 https://github.com/zbobyuan/JJ-s-XMR-STAK-HashRate-Monitor-and-Restart-Tool....? I was using this for xmr-stak,it was every effective.

[vmozara]

What is vega bug? Never had issues with vegas and jce miner

[monote]

BUT after mining a bit,
it starts to increase, decrease, etc, as if you don't put anything!

I haven't tested explicitely, but some (most?) pools will force a variable diff if you mine too fast or too slow with a fixed diff. Look at the log, if you get a message "Pool changes Difficulty to XXXX." so that's your pool's job, JCE don't change the diff by itself. I'll switch one rig to that pool for a few hours to check for that (but I mine v7 and not Heavy since i've low-mem cards).

Hi again and thanks for the answer.
So, i do get the message: "Pool changes Difficulty to XXXX." therefore as you say it's a pool's job.
Weird part is that when using fixed diff like 25k with jce-miner, diff changes after some time but same 25k with xmr-stak, diff stays fixed... :/

Cheers!

[JCE-Miner]

Thanks

Weird part is that when using fixed diff like 25k with jce-miner, diff changes after some time but same 25k with xmr-stak, diff stays fixed...

Interresting, so it may come from my netcode. A possible explaination could be the devfee session that may get a different diff as the user pool. But the devfee sessions are Claymore-style: small randomized sessions that don't disconnect your own pool, so you may encounter a few shares with a different diff from time to time (0.9% of time average) but not a permanent change.
Also strange is that i got this problem reported on CN-Heavy coins, while of course my netcode is the same whatever the coin is (only Nicehash has dedicated netcode).

This is not a big threat since all diff are equivalent in term of efficiency, but that's still a bug. Also check pool side the shares you get are the same as the effective hashrate reported by the yellow report, within a ~2% tolerance, and after a few hours of mining. If you observe a huge result difference, so it could be a critical bug.

Can you make jce gpu miner compatible for this

I quick read the code, and the purpose is to monitor the hashrate and restart the vega drivers and the miner when they drop.
The monitoring is to circumvent the lack of Watchdog in Stak, and the reset/restart is the pupose of a watchdog too.

So my answer is that once JCE watchdog is released, this script won't be needed, a simple .bat would do the job:

(pseudo-bat and dummy values)

Code:

:Reset
# reset GPU
OverdriveNTool.exe ....
# Run JCE with watchdog with minimum hashrate of 500 h/s
jce_cn_gpu_miner64.exe .... --watchdog=500
if ERRORLEVEL 1 goto Reset # if quit with error reset whole procedure, otherwise, just end

What is vega bug? Never had issues with vegas and jce miner

My wording was bad, that was a OpenCL generation bug caused by the Vega detection routine. It appeared in 0.32i and was immediately fixed thanks to the report of samvicky. 0.32i has been removed and replaced by 0.32j

[samvicky]

Weird scenario, My vega 64 is running actually cold In the latest version. Mostly it 72-73 but now 68 max. Maybe it's the driver (I use 18.8.1). Great work ,jce miner.


And A Quick question, in the past rx 550 did 250+ hs, but now we can squeeze 480+ hs. Does the same apply to vega cards or the current hs is their limit...?

[monote]

Thanks

Weird part is that when using fixed diff like 25k with jce-miner, diff changes after some time but same 25k with xmr-stak, diff stays fixed...

Interresting, so it may come from my netcode. A possible explaination could be the devfee session that may get a different diff as the user pool. But the devfee sessions are Claymore-style: small randomized sessions that don't disconnect your own pool, so you may encounter a few shares with a different diff from time to time (0.9% of time average) but not a permanent change.
Also strange is that i got this problem reported on CN-Heavy coins, while of course my netcode is the same whatever the coin is (only Nicehash has dedicated netcode).

This is not a big threat since all diff are equivalent in term of efficiency, but that's still a bug. Also check pool side the shares you get are the same as the effective hashrate reported by the yellow report, within a ~2% tolerance, and after a few hours of mining. If you observe a huge result difference, so it could be a critical bug.

Yeah, true that it isn't a big threat but sometimes miner stays like 7 minutes without finding hashes.
For example I start at 25k diff but it increases (as far as I could see) to 400k...then moving up and down, etc.
Anyways, thanks mate!

[JCE-Miner]

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.

RX550 : my lovely cards, my underestimated favorite. With JCE (and in a lesser extent Stak or others) you can easily pull ~500 h/s from them on v7. Thanks to their memory controller which is the same as the bigger rx560, and for which JCE has dedicated code. So you get a quarter of a vega for a fraction of the price, best efficiency.

The vega jump happened with Cast and the BetaBlockchain. Now the recent 18.x drivers give full power of Vega and we're reaching hardware max at ~2100h/s. It still requires dedicated code to have good performance but no longer hacks to force Compute mode.