rx 588, adrenalin 18.6.1, win 1709
On rx 550, on the contrary, with each version everything is better
Topic: [XMR] JCE Miner Cryptonight/forks, now with GPU! - page 69. (Read 90841 times)
Developer, it's excellent that you did temperature monitoring and share counting, thanks! But version 31f is still the best on hash for me. All cards reach their maximum speed within 5 minutes. After this version, as well as the latter does not give such a result. 1-2 cards sometimes can reach their best speeds, but not all. Is it possible to return the old mechanism (slower) of the kernel compilation or to give a choice?
- 31f
- 32f
rx 588, adrenalin 18.6.1, win 1709
On rx 550, on the contrary, with each version everything is better
rx 588, adrenalin 18.6.1, win 1709
On rx 550, on the contrary, with each version everything is better
on such a small card, if the hashrate is less than ~10h/s it may be flagged as non functional, since it may get 0 share during the observation period of 10s. try using only one thread so all power is on the same thread. 2 threads for 2 CU sounds overkill. my autoconfig doesn't even try to configure well such a card.
the 0.32e focused on stability and gpu fan/temp features. I gave up my optima that broke the previous versions.
i now remove version t and d from GitHub, the last good is e.
ok for json i'll rerelease it with one less coma. thanks for report!
edit:
fixed in the 0.32f
as i said, broken shares are GPU-computed shares that were wrong. No matter if they reached the pool, were stale, reject or whatever. Broken means physically broken.
the 0.32e focused on stability and gpu fan/temp features. I gave up my optima that broke the previous versions.
i now remove version t and d from GitHub, the last good is e.
ok for json i'll rerelease it with one less coma. thanks for report!
edit:
fixed in the 0.32f
Code:
Broken shares reported in the yellow report
Fixed JSON
Reintroduced a blind Vega/RX CN-Heavy optim dropped from 0.32c
Fixed JSON
Reintroduced a blind Vega/RX CN-Heavy optim dropped from 0.32c
as i said, broken shares are GPU-computed shares that were wrong. No matter if they reached the pool, were stale, reject or whatever. Broken means physically broken.
I havent been following the whole testing version but the current 0.32e gives me nearly identical hashrate as the t5 version on my RX580 8GB with autotunining. There is 1h/s difference, but i dont think it has anything to do with optimizations?
hello again,
My desktop at home has an AMD Radeon HD 5450 in it.
I know... it's a sh*tcard for mining but since it's there I could take benefit of it even when it could only do 50H/s.
While JCE detects it without problem and pushes some code to it (see below) the hash rate remain at 0H/s for both GPUs.
Does anyone know what config I need to feed JCE with to get it working?
My desktop at home has an AMD Radeon HD 5450 in it.
I know... it's a sh*tcard for mining but since it's there I could take benefit of it even when it could only do 50H/s.
While JCE detects it without problem and pushes some code to it (see below) the hash rate remain at 0H/s for both GPUs.
Does anyone know what config I need to feed JCE with to get it working?
Quote
Detecting OpenCL-capable GPUs...
Found GPU 0, with:
Vendor: AMD
Processor: Cedar
Device: 01:00
Compute-Units: 2
Cache Memory: 0 KB
Local Memory: 32 KB
Global Memory: 1024 MB
Addressing: 32-bits
Starting GPU Mining thread 4, on GPU 0
Created OpenCL Context for GPU 0 at 00000151b59548a0
Created OpenCL Thread 4 Command-Queue for GPU 0 at 00000151b56701a0
Allocating big 416MB scratchpad for OpenCL Thread 4...
Scratchpad Allocation success for OpenCL Thread 4
Compiling kernels of OpenCL Thread 4, it will be long...
Kernels of OpenCL Thread 4 compiled.
Starting GPU Mining thread 5, on GPU 0
Created OpenCL Thread 5 Command-Queue for GPU 0 at 00000151b5670560
Allocating big 416MB scratchpad for OpenCL Thread 5...
Scratchpad Allocation success for OpenCL Thread 5
Compiling kernels of OpenCL Thread 5, it will be long...
Kernels of OpenCL Thread 5 compiled.
Found GPU 0, with:
Vendor: AMD
Processor: Cedar
Device: 01:00
Compute-Units: 2
Cache Memory: 0 KB
Local Memory: 32 KB
Global Memory: 1024 MB
Addressing: 32-bits
Starting GPU Mining thread 4, on GPU 0
Created OpenCL Context for GPU 0 at 00000151b59548a0
Created OpenCL Thread 4 Command-Queue for GPU 0 at 00000151b56701a0
Allocating big 416MB scratchpad for OpenCL Thread 4...
Scratchpad Allocation success for OpenCL Thread 4
Compiling kernels of OpenCL Thread 4, it will be long...
Kernels of OpenCL Thread 4 compiled.
Starting GPU Mining thread 5, on GPU 0
Created OpenCL Thread 5 Command-Queue for GPU 0 at 00000151b5670560
Allocating big 416MB scratchpad for OpenCL Thread 5...
Scratchpad Allocation success for OpenCL Thread 5
Compiling kernels of OpenCL Thread 5, it will be long...
Kernels of OpenCL Thread 5 compiled.
The JSON data seems to have a bug.
My Firefox doesn't like the comma after the last line in "gpu_status":
"gpu_status":
[
{ "index": 0, "temperature": 45, "fan": 46, "processor": "Ellesmere", "memory": 8192, "good_shares": 1, "bad_shares": 0 },
{ "index": 1, "temperature": 43, "fan": 44, "processor": "Ellesmere", "memory": 4096, "good_shares": 1, "bad_shares": 0 },
{ "index": 2, "temperature": 49, "fan": 49, "processor": "Ellesmere", "memory": 4096, "good_shares": 1, "bad_shares": 0 },
],
=> SyntaxError: JSON.parse: unexpected character at line 41 column 3 of the JSON data
My Firefox doesn't like the comma after the last line in "gpu_status":
"gpu_status":
[
{ "index": 0, "temperature": 45, "fan": 46, "processor": "Ellesmere", "memory": 8192, "good_shares": 1, "bad_shares": 0 },
{ "index": 1, "temperature": 43, "fan": 44, "processor": "Ellesmere", "memory": 4096, "good_shares": 1, "bad_shares": 0 },
{ "index": 2, "temperature": 49, "fan": 49, "processor": "Ellesmere", "memory": 4096, "good_shares": 1, "bad_shares": 0 },
],
=> SyntaxError: JSON.parse: unexpected character at line 41 column 3 of the JSON data
No more,
online is the 0.32e
that's the exact same as 0.32d, plus GPU fan/temp in JSON, and bad shares colored in red if > 0
seven releases in one day, two days to track the bug and two hours to add GPU fan/temp. Woow.
Thanks all for all the tests you did
online is the 0.32e
that's the exact same as 0.32d, plus GPU fan/temp in JSON, and bad shares colored in red if > 0
seven releases in one day, two days to track the bug and two hours to add GPU fan/temp. Woow.
Thanks all for all the tests you did
it would be great if we can display bad shares stats info with the 'r' results key.
Man I wish so bad that you connect remotely and use one of the rigs for testing. But now is too late, i am onboard drilling rig for next 3 weeks. Next time I come home, I will set up one rig with 2 vegas and power consumption monitoring and remote shutdown, so you can play. You will accept This only because I appreciate your miner for no cheating, and if you achieve better hashrate for vegas, i profit directly. kkkkkkkkkkk
This only because I appreciate your miner for no cheating, and if you achieve better hashrate for vegas, i profit directly. kkkkkkkkkkk No more,
online is the 0.32e
that's the exact same as 0.32d, plus GPU fan/temp in JSON, and bad shares colored in red if > 0
seven releases in one day, two days to track the bug and two hours to add GPU fan/temp. Woow.
Thanks all for all the tests you did
online is the 0.32e
that's the exact same as 0.32d, plus GPU fan/temp in JSON, and bad shares colored in red if > 0
seven releases in one day, two days to track the bug and two hours to add GPU fan/temp. Woow.
Thanks all for all the tests you did
Tested on my 570 4GB.
Great release!!!
Great temp and fan!!!
No rejected share.
Got same hashrate as 0.32a for bittube.
Will roll out to 580 8GB rigs.
Thanks JCE.
No more,
online is the 0.32e
that's the exact same as 0.32d, plus GPU fan/temp in JSON, and bad shares colored in red if > 0
seven releases in one day, two days to track the bug and two hours to add GPU fan/temp. Woow.
Thanks all for all the tests you did
online is the 0.32e
that's the exact same as 0.32d, plus GPU fan/temp in JSON, and bad shares colored in red if > 0
seven releases in one day, two days to track the bug and two hours to add GPU fan/temp. Woow.
Thanks all for all the tests you did
My apologies too.
I blamed the 0.32d hashrate without taking care of its fluctuation.
It was wrong because according to this fluctuation, the average value is the same than the 0.32a's.
In others words, the 0.32d looks the best over all the 0.32x.
I blamed the 0.32d hashrate without taking care of its fluctuation.
It was wrong because according to this fluctuation, the average value is the same than the 0.32a's.
In others words, the 0.32d looks the best over all the 0.32x.
Fine, if there's a version that's as fast as before, plus no more bad shares.
What about 0.32d, is it all fine? If yes i could remove the t versions from github.
What about 0.32d, is it all fine? If yes i could remove the t versions from github.
I posted the results too early, it was necessary to give more time for testing the fifth version of 0.32t, now the hashrate became equal to 0.31f, I apologize for misleading.
Code:
22:41:18 | Hashrate GPU Thread 0: 538.82 h/s
22:41:18 | Hashrate GPU Thread 1: 535.35 h/s - Total GPU 0: 1074.16 h/s
22:41:18 | Hashrate GPU Thread 2: 537.83 h/s
22:41:18 | Hashrate GPU Thread 3: 536.40 h/s - Total GPU 1: 1074.22 h/s
22:41:18 | Total: 2148.38 h/s - Max: 2148.38 h/s
22:41:18 | Hashrate GPU Thread 1: 535.35 h/s - Total GPU 0: 1074.16 h/s
22:41:18 | Hashrate GPU Thread 2: 537.83 h/s
22:41:18 | Hashrate GPU Thread 3: 536.40 h/s - Total GPU 1: 1074.22 h/s
22:41:18 | Total: 2148.38 h/s - Max: 2148.38 h/s
Ok, that's a very important point of definition :
All is about physical shares.
A Good share in the GPU log is a share the GPU has computed, and that is good. Period. No matter if it is stale or not.
A Bad share is a physically bad computation, no matter if it is sent to the pool or not.
How are differentiated the good and the bad?
For each GPU share found, a partial CPU recompute of the first 32 bits of the result (the full result is 512 bits) is done to know if the share is good or not. It is logically unrelated to the --doublecheck feature, but of course the two computes recycles each other (the 32 bits or 512 are computed, but not both separately).
Perf: I still flag the 0.32+ series as experimental, and keep the 0.31f online for real mining.
Maybe try the 0.32a which is closer to the 0.31f but compiles OpenCL a lot faster.
All is about physical shares.
A Good share in the GPU log is a share the GPU has computed, and that is good. Period. No matter if it is stale or not.
A Bad share is a physically bad computation, no matter if it is sent to the pool or not.
How are differentiated the good and the bad?
For each GPU share found, a partial CPU recompute of the first 32 bits of the result (the full result is 512 bits) is done to know if the share is good or not. It is logically unrelated to the --doublecheck feature, but of course the two computes recycles each other (the 32 bits or 512 are computed, but not both separately).
Perf: I still flag the 0.32+ series as experimental, and keep the 0.31f online for real mining.
Maybe try the 0.32a which is closer to the 0.31f but compiles OpenCL a lot faster.
Thanks for the explanation, really appreciate it.
Thanks!
Online is the 0.32d version
A normal version, which is supposed to be a fixed 0.32c plus a primitive GPU Fan/Temp display.
It's very simple for now: only in log, with a fancy color. I'll improve colors later (red for bad shares) and add it to the JSON output.
Online is the 0.32d version
A normal version, which is supposed to be a fixed 0.32c plus a primitive GPU Fan/Temp display.
It's very simple for now: only in log, with a fancy color. I'll improve colors later (red for bad shares) and add it to the JSON output.
Nice version for RX 470 8Gb(Samsung) on Win10 LTSB, AMD 18.6.1., running FAST variant 1991 H/s temps fans and shares look good in purple.
Ok, that's a very important point of definition :
All is about physical shares.
A Good share in the GPU log is a share the GPU has computed, and that is good. Period. No matter if it is stale or not.
A Bad share is a physically bad computation, no matter if it is sent to the pool or not.
How are differentiated the good and the bad?
For each GPU share found, a partial CPU recompute of the first 32 bits of the result (the full result is 512 bits) is done to know if the share is good or not. It is logically unrelated to the --doublecheck feature, but of course the two computes recycles each other (the 32 bits or 512 are computed, but not both separately).
Perf: I still flag the 0.32+ series as experimental, and keep the 0.31f online for real mining.
Maybe try the 0.32a which is closer to the 0.31f but compiles OpenCL a lot faster.
All is about physical shares.
A Good share in the GPU log is a share the GPU has computed, and that is good. Period. No matter if it is stale or not.
A Bad share is a physically bad computation, no matter if it is sent to the pool or not.
How are differentiated the good and the bad?
For each GPU share found, a partial CPU recompute of the first 32 bits of the result (the full result is 512 bits) is done to know if the share is good or not. It is logically unrelated to the --doublecheck feature, but of course the two computes recycles each other (the 32 bits or 512 are computed, but not both separately).
Perf: I still flag the 0.32+ series as experimental, and keep the 0.31f online for real mining.
Maybe try the 0.32a which is closer to the 0.31f but compiles OpenCL a lot faster.
RX 580 8GB Sapphire Nitro+, GPU 1300 Memory 2050
driver Crimson-ReLive-Beta-Blockchain, win10 ver 1709
Algo:Cryptonight-Haven , Coin XHV
The fifth version of 0.32t works without problems, but compared to 0.31f hashrate with the same settings decreased:
with version 0.31f:
with the fifth version of 0.32t:
driver Crimson-ReLive-Beta-Blockchain, win10 ver 1709
Algo:Cryptonight-Haven , Coin XHV
The fifth version of 0.32t works without problems, but compared to 0.31f hashrate with the same settings decreased:
with version 0.31f:
Code:
18:14:29 | Hashrate GPU Thread 1: 535.92 h/s - Total GPU 0: 1074.66 h/s
18:14:29 | Hashrate GPU Thread 2: 536.17 h/s
18:14:29 | Hashrate GPU Thread 3: 537.91 h/s - Total GPU 1: 1074.07 h/s
18:14:29 | Total: 2148.73 h/s - Max: 2148.73 h/s
18:14:29 | Hashrate GPU Thread 2: 536.17 h/s
18:14:29 | Hashrate GPU Thread 3: 537.91 h/s - Total GPU 1: 1074.07 h/s
18:14:29 | Total: 2148.73 h/s - Max: 2148.73 h/s
with the fifth version of 0.32t:
Code:
22:02:29 | Hashrate GPU Thread 0: 486.80 h/s
22:02:29 | Hashrate GPU Thread 1: 484.77 h/s - Total GPU 0: 971.57 h/s
22:02:29 | Hashrate GPU Thread 2: 483.96 h/s
22:02:29 | Hashrate GPU Thread 3: 483.36 h/s - Total GPU 1: 967.31 h/s
22:02:29 | Total: 1938.87 h/s - Max: 2054.02 h/s
22:02:29 | Hashrate GPU Thread 1: 484.77 h/s - Total GPU 0: 971.57 h/s
22:02:29 | Hashrate GPU Thread 2: 483.96 h/s
22:02:29 | Hashrate GPU Thread 3: 483.36 h/s - Total GPU 1: 967.31 h/s
22:02:29 | Total: 1938.87 h/s - Max: 2054.02 h/s
Thanks!
Online is the 0.32d version
A normal version, which is supposed to be a fixed 0.32c plus a primitive GPU Fan/Temp display.
It's very simple for now: only in log, with a fancy color. I'll improve colors later (red for bad shares) and add it to the JSON output.
Online is the 0.32d version
A normal version, which is supposed to be a fixed 0.32c plus a primitive GPU Fan/Temp display.
It's very simple for now: only in log, with a fancy color. I'll improve colors later (red for bad shares) and add it to the JSON output.
Hi JCE,
a few question regarding new version :
1. good shares included stale shares?
2. if we added option --doublecheck it will count as bad shares or only if we submit to pool and pool rejected?
please consider to order by device id because it will easy for us to troubleshoot since the order will be the same as hwinfo, gpu-z, and overdriventool.
Thanks.
While mining Haven:
My 570 8G has the same hashrate with 0.32a and 0.32d.
But my 570 4G is 4 h/s slower with the 0.32d.
That's why I gonna keep the 0.32a.
My 570 8G has the same hashrate with 0.32a and 0.32d.
But my 570 4G is 4 h/s slower with the 0.32d.
That's why I gonna keep the 0.32a.
Thanks!
Online is the 0.32d version
A normal version, which is supposed to be a fixed 0.32c plus a primitive GPU Fan/Temp display.
It's very simple for now: only in log, with a fancy color. I'll improve colors later (red for bad shares) and add it to the JSON output.
Online is the 0.32d version
A normal version, which is supposed to be a fixed 0.32c plus a primitive GPU Fan/Temp display.
It's very simple for now: only in log, with a fancy color. I'll improve colors later (red for bad shares) and add it to the JSON output.
Hi Dev,
I'm still using version 0.31c of the miner on a Vega56(Driver: 18.6.1) to mine CryptoLight V7(set FORK=4).
This is my conf:
With the same conf i've try to mine with version 0.32a, 0.32t but no luck.
My first problem is the hashrate drop from 4300 to 3700 and the second, i get a lot of invalid shares.
The only improvement is the compilation speed of the kernels.
JCE 0.32t results: https://imgur.com/Tao8Y7Q
I have also good news for the Cryptonight V7(set FORK=3). The hashrate is the same with all versions, around 1950 h/s.
Because of that i will continue to use version 0.31c until you get a Vega so you can test your code properly.
Until then keep up the good work!
It's a great miner!!!
I'm still using version 0.31c of the miner on a Vega56(Driver: 18.6.1) to mine CryptoLight V7(set FORK=4).
This is my conf:
Code:
"gpu_threads_conf" :
[
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 16, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 0, "multi_hash" : 3552 },
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 16, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 0, "multi_hash" : 3552 },
]
JCE 0.31c results: https://imgur.com/TSkGb7h[
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 16, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 0, "multi_hash" : 3552 },
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 16, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 0, "multi_hash" : 3552 },
]
With the same conf i've try to mine with version 0.32a, 0.32t but no luck.
My first problem is the hashrate drop from 4300 to 3700 and the second, i get a lot of invalid shares.
The only improvement is the compilation speed of the kernels.
JCE 0.32t results: https://imgur.com/Tao8Y7Q
I have also good news for the Cryptonight V7(set FORK=3). The hashrate is the same with all versions, around 1950 h/s.
Because of that i will continue to use version 0.31c until you get a Vega so you can test your code properly.
Until then keep up the good work!
It's a great miner!!!
Jump to: