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

Hi,
waited for 30 minutes, but still hasn't got the peak yet on my rx 580 8gb.
https://ibb.co/kAODoz

??
https://github.com/jceminer/cn_gpu_miner/raw/master/jce_cn_gpu_miner.prototype.032g.zip
the exe inside is jce_cn_gpu.... i don't see any "cpu" exe.
Not to be confused with the real 0.32g CPU-only which also exist, on Windows and Linux

If you have some errors in HWInfo64 so your overclocking goes too far, maybe the warmup of 0.31f did not trigger the error but that's still a too strong overclocking. Maybe retry from stock frequency then rise back by steps.


For RX580 4G, per GPU. put the good GPU index and maybe lower the 944 by steps of 16 if you experience very low or zero hashrate.
Again, during the warmup, the hashrates may be very unstable (but not down to zero), wait a bit to get the stabilized hashrates before concluding.

Excellent thank you! Finally, in this version there is a stable hash on 588 cards on a bittube algorithm, and it even became a little higher! In the rig 552x with the Elpida, digging the Masary, did not notice the changes, everything is still stable!

31f 1150|2100 http://prntscr.com/kezlod
32g 1150|2100 http://prntscr.com/kezlgf

P.S. Dear, I really look forward to the function of the failover pool

Unfortunately for sapphire rx552 cards with memory elpida of 6000 MHz running at the limit does not fit the version During the warmup the cards start to give out memory errors in HWInfo and after a while the blue screen, reducing the frequency to 1800 MHz does not help, apparently it is necessary to look for other timings for now I remain on version 031f.

The hashrate depends on the mining algo, in more of the card settings, including its memory timings.

What sort of hashrate should I be seeing for a 580 per card? Are there any optimal overclocking settings?

Im running Clock 1130, Mem 2200 and only getting 369h/s per card.... I've seen people claiming upwards of 800h/s per card on forums. Is this achievable?

Also still getting the following with the dropped hashrate settings

18:38:14 | Hashrate CPU Thread 0: 3.39 h/s - Total CPUs: 3.39 h/s
18:38:14 | Hashrate GPU Thread 1: 0.00 h/s
18:38:14 | Hashrate GPU Thread 2: 0.00 h/s - Total GPU 0: 0.00 h/s
18:38:14 | Hashrate GPU Thread 3: 0.00 h/s
18:38:14 | Hashrate GPU Thread 4: 0.00 h/s - Total GPU 1: 0.00 h/s
18:38:14 | Hashrate GPU Thread 5: 0.00 h/s
18:38:14 | Hashrate GPU Thread 6: 0.00 h/s - Total GPU 2: 0.00 h/s
18:38:14 | Hashrate GPU Thread 7: 733.89 h/s
18:38:14 | Hashrate GPU Thread 8: 0.00 h/s - Total GPU 3: 733.89 h/s
18:38:14 | Hashrate GPU Thread 9: 0.00 h/s
18:38:14 | Hashrate GPU Thread 10: 0.00 h/s - Total GPU 4: 0.00 h/s
18:38:14 | Hashrate GPU Thread 11: 184.22 h/s
18:38:14 | Hashrate GPU Thread 12: 184.22 h/s - Total GPU 5: 368.44 h/s
18:38:14 | Total: 1105.71 h/s - Max: 2568.70 h/s

18:38:16 | Hashrate CPU Thread 0: 3.41 h/s - Total CPUs: 3.41 h/s
18:38:16 | Hashrate GPU Thread 1: 183.64 h/s
18:38:16 | Hashrate GPU Thread 2: 183.64 h/s - Total GPU 0: 367.28 h/s
18:38:16 | Hashrate GPU Thread 3: 171.09 h/s
18:38:16 | Hashrate GPU Thread 4: 171.18 h/s - Total GPU 1: 342.27 h/s
18:38:16 | Hashrate GPU Thread 5: 183.46 h/s
18:38:16 | Hashrate GPU Thread 6: 183.53 h/s - Total GPU 2: 366.99 h/s
18:38:16 | Hashrate GPU Thread 7: 732.51 h/s
18:38:16 | Hashrate GPU Thread 8: 0.00 h/s - Total GPU 3: 732.51 h/s
18:38:16 | Hashrate GPU Thread 9: 179.56 h/s
18:38:16 | Hashrate GPU Thread 10: 179.45 h/s - Total GPU 4: 359.00 h/s
18:38:16 | Hashrate GPU Thread 11: 0.00 h/s
18:38:16 | Hashrate GPU Thread 12: 184.33 h/s - Total GPU 5: 184.33 h/s
18:38:16 | Total: 2355.76 h/s - Max: 2568.70 h/s

18:38:19 | Hashrate CPU Thread 0: 3.41 h/s - Total CPUs: 3.41 h/s
18:38:19 | Hashrate GPU Thread 1: 0.00 h/s
18:38:19 | Hashrate GPU Thread 2: 0.00 h/s - Total GPU 0: 0.00 h/s
18:38:19 | Hashrate GPU Thread 3: 0.00 h/s
18:38:19 | Hashrate GPU Thread 4: 0.00 h/s - Total GPU 1: 0.00 h/s
18:38:19 | Hashrate GPU Thread 5: 0.00 h/s
18:38:19 | Hashrate GPU Thread 6: 0.00 h/s - Total GPU 2: 0.00 h/s
18:38:19 | Hashrate GPU Thread 7: 732.28 h/s
18:38:19 | Hashrate GPU Thread 8: 0.00 h/s - Total GPU 3: 732.28 h/s
18:38:19 | Hashrate GPU Thread 9: 179.56 h/s
18:38:19 | Hashrate GPU Thread 10: 179.45 h/s - Total GPU 4: 359.00 h/s
18:38:19 | Hashrate GPU Thread 11: 184.26 h/s
18:38:19 | Hashrate GPU Thread 12: 184.33 h/s - Total GPU 5: 368.58 h/s
18:38:19 | Total: 1463.26 h/s - Max: 2568.70 h/s

You multi-hash values are probably too high. You should try to lower them.

You could test 928, then 944,... until you find the one that give the stable and highest hashrate for each card.

Im running 6 XFX RX 580's and my hashrate is constantly displaying as 0 in the miner except for the CPU. sometimes it spikes up to 150h/s on a thread but thats it

Im using the following config for QRL mining

Using Cryptonight 7

{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta":4, "index" : 0, "multi_hash":1088 },
     { "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta":4, "index" : 0, "multi_hash":1088 },
     { "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta":4, "index" : 1, "multi_hash":1088 },
     { "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta":4, "index" : 1, "multi_hash":1088 },
     { "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta":4, "index" : 2, "multi_hash":1088 },
     { "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta":4, "index" : 2, "multi_hash":1088 },
     { "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta":4, "index" : 3, "multi_hash":1088 },
     { "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta":4, "index" : 3, "multi_hash":1088 },
     { "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta":4, "index" : 4, "multi_hash":1088 },
     { "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta":4, "index" : 4, "multi_hash":1088 },
     { "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta":4, "index" : 5, "multi_hash":1088 },
     { "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta":4, "index" : 5, "multi_hash":1088 },

any help?

Your file name is wrong, it's called "cpu" instead of "gpu".

Here comes

0.32g GPU


During the warmup (about 5min) the hashrate can be crazy, your vega can display 50 or 5000 h/s, that's normal (as least, expected). That's because all timings are tweaked during this time, so two hashes can be mined in a row, leading to a crazy number. That's cosmetical, during this time you mine normally and can find shares. If a bad share is found, that's a bug or GPU problem, the warum phase is not expected to produce bad shares.

I tested it on my RX560 and after 5mn of crazy hashrates, i get my stable 527 h/s i got on 0.31, same for all my rigs.

you can keep the greeks in the config, but the four less important won't be logged anymore at startup.

RYO wallet are the same as Sumo so i. cannot deduce if a sumo wallet mines ryo. but you can mine ryo with
--any --variation 5
5 is fork number of CN-Heavy

i get perfect results of warmup with my Pitcairn but mixed with the rx560 where sometime the gpu with the display attached stays at 90% speed. i'll probably release as-is so you can give feedback. i cannot just restore behavior of 0.31 because everything has changed inbetween

keepalive: possible but low priority to dev


webchain: nope they changed too many things in the netcode, not just in the algo. i won't double my netcode volume for one obscure coin.

watchdog: JCE currently fails to quit because it tries to clean every memory at exit. in case of watchdog fail, it won't clean and just successfully quit. so the line to be called will be the next in the caller script, i prefer this way rather than forwarding a command line.

hi

can you add RYO?

can you please add keepalive option in the next release plan?

Can you elaborate, please..?

it seems to me that this does not always help those who do not have a hardware watchdog. I have one or two cards falling and when I close the miner it just hangs for a long time (20 minutes the system may hang in this state), so the next line will not be executed for a long time and the reboot will not happen. It may be better to call a pre-defined script, even if it's empty, but there everyone will write what he needs in it.

Can you still keep the greek letters optional? I  was playing yesterday a little bit and managed to squeeze extra 60h/s from entire rig by playing with these letters 

Hello JCE,

Can you add support for https://webchain.network/?
Their algo it's a modified version of CryptoNightV7.
They have official miner for CPU here: https://github.com/webchain-network and unofficial for GPU here: https://github.com/monkins1010.

Tnx and keep up the good work!

I plan to put a Claymore-like watchdog: in case a GPU falls under a certain hashrate (default: 0) the miner quits. Then it's up to you to have a script (.bat or .sh) whose next line is a reboot command.

The watchdog wouldn't apply during the warmup session, since then the hashrate is very unstable and inconsistent, on purpose. It may crate both false positive (hashrate higher than real hardware max) or false negative (hashrate very low). That's because the VRAM memory accesses are managed to ensure 100% hashrate after the warmup. Something that was broken in the 0.32+
And not applied to CPU, since a slower CPU is caused by a legitimate other app that need some compute (the system, a driver, whatever...).

0.32g released soon. I skip the minor updates and will release them later in a minor upgrade. 0.32g will only have:


Then next:

even linux won't be able to recover from that state.  Typically those kind of crashes are the ones stuck in interrupt handling.

Well, out of experience, if a gpu crashes as in memory errors, nothing can reboot it except a power loss (forced shutdown) windows is so stupid.