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

I can beat stak and xmrig, they both use the same old code from Wolf0.

And claymore is a beast on CN-Classic on HD7000/2xx with 9.7
With 10+ i get high displayed hashrate on hd7000 but 10% bad shares, i can fix them by lowering intensity but then the hashrate itself drops by 10%.

On my dual Baffin i use the most for tests, i cannot get more than 915 on CN-v7 from Claymore, with a pool hashrate reported around 870. I made JCE run at 965 and stak at 940 with my current status. I didn't even started optim of CN-Heavy, it's a very different algo when implemented on GPU.

SRB, i'll do the tests you advised with my HD7870.
I also tested my Bonaire, which sends 240 on JCE, 265 on old Claymore 9.7 but is not even supported by Claymore 10+
That's consistent with the current 10% loss against Claymore 9.7

No dev today, my whole rig is dedicated to stability tests. Uptime 24h on all my GPU, no crash. I'll go back to dev after 48h of uptime, that will be enough to say it's stable. Testing during dev is very long, a bug in the OpenCL usually crash the GPU since the GPU memory is not virtualized like the one of a CPU. Sometimes the drivers can reset the gpu, but usually it just crashes.

not bad, i'm done with all algos but Heavy which is so different. but also offers the best opportunities to optimize.
i cannot get how Claymore did his 9.7 so stable and fast, on hd7000. I Cannot reach it on cn-classic. it was really a masterpiece of optim.
stability tests were success.

I can beat stak and xmrig, they both use the same old code from Wolf0.

And claymore is a beast on CN-Classic on HD7000/2xx with 9.7
With 10+ i get high displayed hashrate on hd7000 but 10% bad shares, i can fix them by lowering intensity but then the hashrate itself drops by 10%.

On my dual Baffin i use the most for tests, i cannot get more than 915 on CN-v7 from Claymore, with a pool hashrate reported around 870. I made JCE run at 965 and stak at 940 with my current status. I didn't even started optim of CN-Heavy, it's a very different algo when implemented on GPU.

SRB, i'll do the tests you advised with my HD7870.
I also tested my Bonaire, which sends 240 on JCE, 265 on old Claymore 9.7 but is not even supported by Claymore 10+
That's consistent with the current 10% loss against Claymore 9.7

No dev today, my whole rig is dedicated to stability tests. Uptime 24h on all my GPU, no crash. I'll go back to dev after 48h of uptime, that will be enough to say it's stable. Testing during dev is very long, a bug in the OpenCL usually crash the GPU since the GPU memory is not virtualized like the one of a CPU. Sometimes the drivers can reset the gpu, but usually it just crashes.

detailled settings and comparative results, exactly what i needed, thanks

i also observed srb being 10% lower than claymore, on hd700 (270X is a rebrand) but my pool reports hashrate 10% lower than expected on claymore miners (while my proto jce sends exactly what it displays, as expected)
i've a hd7870 so i'll be able to do the same compare.

Please, make on GPU version video memory usage indicator to user know how much vmemory he allready used for mining.

Better handling of long pause time
Sending SIGINT to the parent JCE process forwards it to the child ghost "attrib" (for 3rd party automation)
New coin: Saronite
ETN defaults to CN-v7-ETN (which is backward compatible with CN-v7)
Italo defaults to Heavy

Not yet, i'm focusing at polishing the GPU version, but yeah i'll release a last CPU version with than new fork. Will be variation 11.

To answer your question: No you cannot yet, it's just not implemented yet.
edit : i looked at code, and it seems to be just like Monero v7, let me check more. In such case, nothing to change (except my documentation)
re-edit: Electronero is a slightly modified variation compared to CN-v7 so i still need an update, but it will be an esay one, and backward compatible. Said differently, the Electronero algo will be compatible with Monero, but the opposite is false.

Teaser of GPU version, I'll keep the same principles as for the CPU version:
* at least as fast as Stak/XMrig in worst case, often better[1]
* a lot of exclusive tuning option
* detailled info about what the miner does (allocations of GPU memory, kernel compile...)
* complete cleanup of OpenCL resource at close (like for the Large pages for CPU)
* Instant hashrate, not the max of last few seconds like Claymore (cough.. cheater... cough...)
* So the pool-side hashrate will be displayed hashrate, minus fees, not 10% lower like claymore 10+ [2]
* Targetting at correctness and reliability, no memory access hacks that produce bad hashes
* As a consequence, no CPU re-check[3], if you find a bad share, it will still be sent to your pool
* of course it will be an hybrid miner, able to mine CPU + GPU (or just CPU, or just GPU) on the same pool connection.

[1] It comes at the cost of huge optimizations on the fly, so JCE GPU will take ages to start, and then mine faster. You're warned.

[2] : I loved Claymore 9.7, a masterpiece, then came 10 and 11 that, on all my rigs, produce tons of bad shares and has a 10% lower effective hashrate that what it displays. That's what motivated me to start JCE GPU at the beginning.
Stak and XMRig are decent, both are copies of Wolf0, like Zawawa btw, but both the code and OpenCL contains goofs that made me laugh, so i just rewrote everything, and kept it close source, i won't do the same error than Wolf0 to open source just to see the fees go to copy-paste morons.

[3] That's what Claymore 9.7 did and i go this way : make a miner that just works, and doesn't need re-hash, instead of a broken one + fallback security.