Topic: [XMR] JCE Miner Cryptonight/forks, now with GPU! - page 68. (Read 90814 times)

 I assume hope that a RX 580 8GB is required to get more than 1000 h/s, because on CN V7, Heavy or Saber, all my cards (580 4G, 570 8G, 570 4G) remain between 800 and 970 h/s.

By the way I found out my 580 works better with

while both my 570 as faster with
 

Hello, can we get your OC settings to get this results ? do you undervolt ? also what multihash do you use ? 848 ?

For me, more effective settings (at summer 40° celsius) with a cost of 0.14usd/Kwh is : 960 h/s for 95W at wall per rx580 (Wattman : 1100 core 810cv, 1190 mem 830mv)

Thank you

Thanks for your explanation about multi_hash, understand by pressing H or T or R will reduce our effective hashrate. normally I often press H when running GPU-Z to know as fast as possible my hashrate already reach peak and then close GPU-Z. so if you able to make GPU reach peak it self not needed to keep pressing H again :-).

The display that I suggested is just my thought base on my experience with other miner like XMR Stak (only display accepted shares and press key if you want to know other information), Phoenix Miner (display accepted shares, stale shares, bad shares), SRB Miner (one line information for each GPU).

Anyway I already happy with how effective hashrate closed to reported hashrate and I think right now is the fastest miner for RX 580 8GB, so keep good work.

pro-tip : on HD7950, use drivers 15.12 and on FM2 APU, 15.7

i focused on some non-gpu bugs and i'm fixing two:
* blue hashrate stops to popup automatically when gpu status (purple) comes
* miner loses connection to pool but continues to mine in the void (UnclWish bug)


Pressing H (or T or R) stops the miner for a split second, needed to gather the very up-to-date info to display, and to flush the console display. don't manic-press h or it cause the hashrate to drop. it even apply to the cpu miner. if you really want to constantly get the hashrate, open the JSON out in a browser and punch F5 as much as you want.


the multiple of 16 is due to the internal way i pack the data. it must be an even square, the next lower is 4 (2x2) and it's too small, so i need to keep 16.

the purple report is all about physics. fan, temp and gpu compute correctness. adding stale or accepted share info is not about physics, that's about your pool. those info should be displayed, but in the yellow report.
i'd like to avoid adding too many parameters, for simplicity. the default frequency the reports (blue, yellow and purple) pop is already quite low and impact on perf is negligeible.

Hello,

what GPU driver do you recommend ? i don't see it on the first post. Thank you !

ATM my hashrates with 580 Samsung is 1030 h/S (heavy) using the version 31c with 842 multihash and no OC.

Hi JCE,

any reason why multi_hash must be multiple by 16? why is it not 2 or 4 or 8?

another opinion is it possible to display hash rate, temp, fan, good shares, stale shares, bad shares in one line like below?

GPU0 : 1100 h/s, Temp : 50C, Fan : 50%, Shares : 100/0/1
GPU1 : 1090 h/s, Temp : 51C, Fan : 51%, Shares : 101/1/2

and another option like --disabledmonitoring to prevent that information showing up every xx seconds. if we want to show that information we can just press h. because I notice if I keep pressing h I don't see any accepted shares from pool so just curios by displaying that information is it reduce our effective hash rate?

Thanks.

Hello,

i plan to add per-gpu coin config, to allow different gpu mine different coins, since some are faster on Heavy or on V7. but not a super autoswitch, that goes too far for now.

recent jce have a bug on the warm-up phase and get stuck at 80% speed, never reaching 100% even after 5mn, even after a hour. i can reproduce the bug and i'm experimenting fixes.

rinzlerus: that's what you're experiencing. try the 0.31c it shouldn't have this regression. same for you synchro2017

i must also focus on a bug reported where jce stops sending shares after having been paused, either manually or by a devfee session. it looks a rare bug but it's a critical one. seems to depend on the pool, Unclwsh reported it on nicehash.

In relation to the above:




Do you plan on adding this or a form of this to the JCE miner?

Why not all of the RX552 giving the same hashrate using the same config?

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?



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

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.

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...

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.

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
                                                        

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.

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.

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.

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 ?

hi please add to JCE Miner for this coin, webchain with modified cryptoNightV7
https://bitcointalksearch.org/topic/annmintmemintmecom-coincpu-miningdapps-via-websitesno-icoasic-3649170

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.