henri2018
Newbie
Offline
Activity: 46
Merit: 0
|
|
July 28, 2018, 07:55:11 PM |
|
No more, online is the 0.32ethat'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.
|
|
|
|
vmozara
Member
Offline
Activity: 190
Merit: 59
|
|
July 28, 2018, 08:19:32 PM |
|
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
|
|
|
|
heavyarms1912
|
|
July 28, 2018, 09:51:28 PM |
|
No more, online is the 0.32ethat'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.
|
|
|
|
Lermite
Newbie
Offline
Activity: 54
Merit: 0
|
|
July 29, 2018, 12:25:54 AM Last edit: July 29, 2018, 08:23:16 AM by Lermite |
|
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
|
|
|
|
gvb
Jr. Member
Offline
Activity: 140
Merit: 9
|
|
July 29, 2018, 09:48:45 AM |
|
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? 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.
|
|
|
|
s0ftcorn
Newbie
Offline
Activity: 70
Merit: 0
|
|
July 29, 2018, 01:05:08 PM |
|
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?
|
|
|
|
JCE-Miner (OP)
Member
Offline
Activity: 350
Merit: 22
|
|
July 29, 2018, 05:37:49 PM Last edit: July 29, 2018, 08:02:12 PM by JCE-Miner |
|
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.32fBroken shares reported in the yellow report 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.
|
|
|
|
Sx5000
Jr. Member
Offline
Activity: 31
Merit: 5
|
|
July 29, 2018, 08:50:28 PM Last edit: July 29, 2018, 09:05:09 PM by Sx5000 |
|
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 - 32frx 588, adrenalin 18.6.1, win 1709On rx 550, on the contrary, with each version everything is better
|
|
|
|
gvb
Jr. Member
Offline
Activity: 140
Merit: 9
|
|
July 29, 2018, 10:30:46 PM |
|
try using only one thread so all power is on the same thread.
was that 1 CPU or 1 GPU thread? I tried with the config below but it's still stuck at 0H/s. I don't know the right values for that card tho. /* The CPU configuration. This is a simple EXAMPLE with one core. Replace by configuration that matches your CPU. The final version of JCE-GPU will be full automatic */ "cpu_threads_conf" : [ { "cpu_architecture" : "auto", "affine_to_cpu" : 0, "use_cache" : true }, { "cpu_architecture" : "auto", "affine_to_cpu" : 0, "use_cache" : true }, ],
/* The GPU configuration. This is a simple EXAMPLE with two low-intensity threads on the first GPU. Replace by configuration that matches your GPUs. The final version of JCE-GPU will be full automatic */ "gpu_threads_conf" : [ { "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta":4, "index" : 0, "multi_hash":128 }, ],
|
|
|
|
|
JCE-Miner (OP)
Member
Offline
Activity: 350
Merit: 22
|
|
July 30, 2018, 05:14:49 AM |
|
I already took a look and gave up. it's not just a fork of cn-v7, they completely changed the network protocol too. the changes are far more important than for Nicehash. it would be too complicated to handle both, and even themselves just made a webchain-only miner from xmrig but not one that handle all CN variations. i cannot afford time to handle two separate netcodes.
any feedback about cn-heavy hashrates of 0.32f ?
|
|
|
|
lebuawu2
Jr. Member
Offline
Activity: 176
Merit: 2
|
|
July 30, 2018, 05:44:48 AM Last edit: July 30, 2018, 05:59:54 AM by lebuawu2 |
|
I already took a look and gave up. it's not just a fork of cn-v7, they completely changed the network protocol too. the changes are far more important than for Nicehash. it would be too complicated to handle both, and even themselves just made a webchain-only miner from xmrig but not one that handle all CN variations. i cannot afford time to handle two separate netcodes.
any feedback about cn-heavy hashrates of 0.32f ?
I tried on bittube it slightly increase hashrate about 5-10 h/s per card and no rejected shared which is good. Edit : the things need to take note is like Sx5000 said on some card it really difficult to reach peak hashrate, I need to fire GPU-Z over and over.
|
|
|
|
henri2018
Newbie
Offline
Activity: 46
Merit: 0
|
|
July 30, 2018, 06:03:10 AM |
|
I already took a look and gave up. it's not just a fork of cn-v7, they completely changed the network protocol too. the changes are far more important than for Nicehash. it would be too complicated to handle both, and even themselves just made a webchain-only miner from xmrig but not one that handle all CN variations. i cannot afford time to handle two separate netcodes.
any feedback about cn-heavy hashrates of 0.32f ?
I tried on bittube it slightly increase hashrate about 5-10 h/s per card and no rejected shared which is good. Edit : the things need to take note is like Sx5000 said on some card it really difficult to reach peak hashrate, I need to fire GPU-Z over and over. Same as me about hard to reach the hashrate peak, should run gpu-z more than once. Very small increase on hashrate, it is about up to 5 h/s only on mine. Currently back to 0.32a.
|
|
|
|
WebTosha
Newbie
Offline
Activity: 14
Merit: 0
|
|
July 30, 2018, 11:22:46 AM |
|
I already took a look and gave up. it's not just a fork of cn-v7, they completely changed the network protocol too. the changes are far more important than for Nicehash. it would be too complicated to handle both, and even themselves just made a webchain-only miner from xmrig but not one that handle all CN variations. i cannot afford time to handle two separate netcodes.
any feedback about cn-heavy hashrates of 0.32f ?
I tried on bittube it slightly increase hashrate about 5-10 h/s per card and no rejected shared which is good. Edit : the things need to take note is like Sx5000 said on some card it really difficult to reach peak hashrate, I need to fire GPU-Z over and over. Same as me about hard to reach the hashrate peak, should run gpu-z more than once. Very small increase on hashrate, it is about up to 5 h/s only on mine. Currently back to 0.32a. in the same way, RX552 start badly, from 13 cards 2-3 cards can either generally 0 h/s or 470 h/s and does not rise. back to 0.32a.
|
|
|
|
QuirkSilver
Member
Offline
Activity: 80
Merit: 13
|
|
July 30, 2018, 02:20:28 PM |
|
heavy cryptonight favoring larger memory variant in Polaris in general, while normal Cryptonight being faster on normal memory size Polaris, is exactly the same as gaming benchmarks, lower 1080p and maybe many 1440p titles perform faster on 4gb 580 marginally. What i'm trying to say is how you through work at those memory chips, tends to change their performance parameters, allowing them to utilize what they excel at (high bandwidth, 8gbps) I'm curious to experiment with those alpha,beta parameters both on normal and heavy. What are they (roughly?) I'm doing huge experiments with timing straps (mostly Cn-V7), and on 2GB Polaris, definitely your miner is faster! however, 580,570 4gb aren't that different? i think its how work is sent to the memory. in fact my elpida 560 does 575 h/s (still experimenting with hard timing parameters to clock more, i sweat i can pass 600 h/s easily) but oddly, 570 is doing only less than 1000 h/s (maybe can pass 1000 h/s) although being exactly 200% in memory bandwidth and compute count!?
Your miner reporting many stales is due to low difficulty (3.5 kh/s and 50k only difficulty) once its set to 100k + stales are less and even non of them gets rejected. (never had rejects with your miner)
P.S: can others share thier setup for v7/heavy? mine for normal is: 2gb Elpida, two threads (448+416), Worksize: (16), (Alpha 64) rest are default. (hynix is 448,400 only) 4 gb 580/570 (896X 2 threads) rest is the same
|
|
|
|
heavyarms1912
|
|
July 30, 2018, 02:25:09 PM |
|
heavy cryptonight favoring larger memory variant in Polaris in general, while normal Cryptonight being faster on normal memory size Polaris, is exactly the same as gaming benchmarks, lower 1080p and maybe many 1440p titles perform faster on 4gb 580 marginally. What i'm trying to say is how you through work at those memory chips, tends to change their performance parameters, allowing them to utilize what they excel at (high bandwidth, 8gbps) I'm curious to experiment with those alpha,beta parameters both on normal and heavy. What are they (roughly?) I'm doing huge experiments with timing straps (mostly Cn-V7), and on 2GB Polaris, definitely your miner is faster! however, 580,570 4gb aren't that different? i think its how work is sent to the memory. in fact my elpida 560 does 575 h/s (still experimenting with hard timing parameters to clock more, i sweat i can pass 600 h/s easily) but oddly, 570 is doing only less than 1000 h/s (maybe can pass 1000 h/s) although being exactly 200% in memory bandwidth and compute count!?
Your miner reporting many stales is due to low difficulty (3.5 kh/s and 50k only difficulty) once its set to 100k + stales are less and even non of them gets rejected. (never had rejects with your miner)
P.S: can others share thier setup for v7/heavy? mine for normal is: 2gb Elpida, two threads (448+416), Worksize: (16), (Alpha 64) rest are default.
570s should be doing pretty much equivalent to any other miner. I get the same 1k+ numbers on JCE as I used to get with others. 944 is the intensity for JCE 4gb RX570/RX580 cards. Dual threads for CN and Single thread for CN-Heavy.
|
|
|
|
QuirkSilver
Member
Offline
Activity: 80
Merit: 13
|
|
July 30, 2018, 02:29:50 PM |
|
944, hmm! thanks a lot for that. trying now. I noticed though on 2gb Hynix is so garbage, cooled or not it takes less maximum memory utilization...
|
|
|
|
JCE-Miner (OP)
Member
Offline
Activity: 350
Merit: 22
|
|
July 30, 2018, 07:02:38 PM |
|
hello all,
small HD5000: i cannot test to find the problem, but i will use in such case the hash counter i use for the no-cache cpu mode, which is able to count very low hashrates like 2h/s also try to lower more the multihash, my little apu hd7560D has zero hash if multihash is >64 for example.
i read carefully your comments about gpuz and the peak hashrate, and… fine i can reproduce… on my Pitcairn rig. this is blantant, 0.31c gives me 536h on my 7870 after 2mn, 0.32f stays at 500 forever until i play with gpuz, then i get 540. i think i can fix it keeping the same peak hashrate. this is my top priority now.
alpha and beta are internal data grouping params, i cannot tell more. other are very minor, i plan to automatize them and remove them from the config, for simplicity.
jce gives a lot of warnings about stale, but success to send the share in time in most cases. the warning is mostly cosmetical. its netcode is optimized to get maximum rate pool side (real hashrate as close as possible as the theorical one). something i observed bad on other miners, mostly Claymore 10+
power of cards: its about memory timings before everything else. then about CU and bandwidth. hence why the RX550 whose gpu is a half RX560 keeps almost the same perf. and why some old cards like HD7850 are at same level as the very more recent RX560. reciprocaly, reenabling the 2 missing CU of a RX560-lite (14 CU) gives zero perf increase.
|
|
|
|
syncro2017
Newbie
Offline
Activity: 81
Merit: 0
|
|
July 30, 2018, 09:58:29 PM |
|
I just tried the latest version of the miner and temperature and fan always show 0 in my case I run 4xRx550 and 1xRX570 Any Ideas? { { "hashrate": { "thread_0": 257.86, "thread_1": 255.29, "thread_2": 260.17, "thread_3": 255.44, "thread_4": 262.53, "thread_5": 265.25, "thread_6": 232.00, "thread_7": 239.94, "thread_8": 503.44, "thread_9": 465.08, "thread_all": [257.86, 255.29, 260.17, 255.44, 262.53, 265.25, 232.00, 239.94, 503.44, 465.08], "thread_gpu": [513.14, 515.60, 527.77, 471.94, 968.51], "total": 2996.95, "max": 3004.91 }, "result": { "wallet": "45UCHuYkQfriTrWoCC2vhFYBSUHtrTsm4DJduNye42ssJagZPjG2tiFBmdgpvehAhSTCqBo2AfiS5Ukx8R1CVv1A2WiEoHk+18450", "pool": "monero.pool-moscow.ru:8888", "ssl": false, "currency": "Monero (XMR/XMV)", "difficulty": 18450, "shares": 1685, "hashes": 31088250, "uptime": "2:47:16", "effective": 3097.67 }, "gpu_status": [ { "index": 0, "temperature": 0, "fan": 0, "processor": "gfx804", "memory": 2048, "good_shares": 245, "bad_shares": 0 }, { "index": 1, "temperature": 0, "fan": 0, "processor": "gfx804", "memory": 2048, "good_shares": 289, "bad_shares": 0 }, { "index": 2, "temperature": 0, "fan": 0, "processor": "gfx804", "memory": 2048, "good_shares": 314, "bad_shares": 0 }, { "index": 3, "temperature": 0, "fan": 0, "processor": "gfx804", "memory": 2048, "good_shares": 255, "bad_shares": 0 }, { "index": 4, "temperature": 0, "fan": 0, "processor": "Ellesmere", "memory": 4096, "good_shares": 582, "bad_shares": 0 } ], "miner": { "version": "jce/0.32f/gpu", "platform": "Intel(R) Celeron(R) CPU G3930 @ 2.90GHz", "system": "Windows 64-bits", "algorithm": "3" } }
I Also noticed that the last RX550 never goes above 470h/s for some reason The same was noticed in 31f build i an before
|
|
|
|
rinzlerus
Newbie
Offline
Activity: 11
Merit: 0
|
|
July 31, 2018, 09:13:38 AM |
|
12:05:28 | Hashrate GPU Thread 0: 262.11 h/s 12:05:28 | Hashrate GPU Thread 1: 259.07 h/s - Total GPU 0: 521.17 h/s 12:05:28 | Hashrate GPU Thread 2: 224.03 h/s 12:05:28 | Hashrate GPU Thread 3: 223.99 h/s - Total GPU 1: 448.01 h/s 12:05:28 | Hashrate GPU Thread 4: 224.81 h/s 12:05:28 | Hashrate GPU Thread 5: 223.66 h/s - Total GPU 2: 448.46 h/s 12:05:28 | Hashrate GPU Thread 6: 223.66 h/s 12:05:28 | Hashrate GPU Thread 7: 222.77 h/s - Total GPU 3: 446.43 h/s 12:05:28 | Hashrate GPU Thread 8: 263.33 h/s 12:05:28 | Hashrate GPU Thread 9: 259.44 h/s - Total GPU 4: 522.77 h/s 12:05:28 | Hashrate GPU Thread 10: 223.60 h/s 12:05:28 | Hashrate GPU Thread 11: 223.33 h/s - Total GPU 5: 446.92 h/s
12:11:04 | Hashrate GPU Thread 1: 222.66 h/s - Total GPU 0: 446.13 h/s 12:11:04 | Hashrate GPU Thread 2: 262.64 h/s 12:11:04 | Hashrate GPU Thread 3: 257.89 h/s - Total GPU 1: 520.52 h/s 12:11:04 | Hashrate GPU Thread 4: 222.94 h/s 12:11:04 | Hashrate GPU Thread 5: 223.91 h/s - Total GPU 2: 446.84 h/s 12:11:04 | Hashrate GPU Thread 6: 222.96 h/s 12:11:04 | Hashrate GPU Thread 7: 223.03 h/s - Total GPU 3: 445.98 h/s 12:11:04 | Hashrate GPU Thread 8: 257.52 h/s 12:11:04 | Hashrate GPU Thread 9: 262.34 h/s - Total GPU 4: 519.85 h/s 12:11:04 | Hashrate GPU Thread 10: 258.22 h/s 12:11:04 | Hashrate GPU Thread 11: 259.96 h/s - Total GPU 5: 518.17 h/s Why not all of the RX552 giving the same hashrate using the same config? { "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 0, "multi_hash" : 448 },
|
|
|
|
|