I have tested this miner now for couple of days with few old i7 2600K that I have.
So far its working very well, and is 10-15% faster than xmr-stak. Runs smooth with no problems, good job!
Topic: [XMR] JCE Miner Cryptonight/forks, now with GPU! - page 87. (Read 90841 times)
Thanks all 
@nightfury : go to the GitHub page or to the first post of this topic, there's an example of simple command line. note the gpu prototype still need manual configuration.
maybe stay on 0.30a since 0.30b has a glitchy netcode
@nightfury : go to the GitHub page or to the first post of this topic, there's an example of simple command line. note the gpu prototype still need manual configuration.
maybe stay on 0.30a since 0.30b has a glitchy netcode
i will try this JCE miner tonight and report the result, sir, thank you for the hard work
What a welcome message, thanks!
I already discussed about the real hashrate of close-source miners, and I still claim that some do cheat, the most blantant case for me was Claymore 11.3 on cn-classic.
Just run Claymore 9.7 on an old non-forked coin like Bytecoin. You'll get 99% of the reported hashrate. Do the same with 11.3 and you'll get 90%.
I know about the random factor and the Stale shares, but on exact same pool, exact same hardware, on the long term (>24h) you should get the same ratio.
JCE does no tweak about the hashrate, may everybody check themselves and they can see.
I got good results on Vega, which is funny since i don't even own any myself. But i applied all the best optimizations possible (except on Heavy, not good yet) and i got excellent results on RX550 and vega, good on RX560 and 7850, and decent on RX570/580
I've finished the Bittube-v4 fork assemblies (ouch, ~100 asm files to update) and openCL (with the same bad perf than Heavy). And fixed the netcode, but i want to test more before release.
I expect the CPU version of bittube-v4 JCE to be a lot faster than on other miners, since I used assembly pseudo-aes implementation and not naive C like others.
There will be a complete release with CPU and 32-bits and Linux this time, not just GPU version.
Waiting optimization heavy algo code... I already discussed about the real hashrate of close-source miners, and I still claim that some do cheat, the most blantant case for me was Claymore 11.3 on cn-classic.
Just run Claymore 9.7 on an old non-forked coin like Bytecoin. You'll get 99% of the reported hashrate. Do the same with 11.3 and you'll get 90%.
I know about the random factor and the Stale shares, but on exact same pool, exact same hardware, on the long term (>24h) you should get the same ratio.
JCE does no tweak about the hashrate, may everybody check themselves and they can see.
I got good results on Vega, which is funny since i don't even own any myself. But i applied all the best optimizations possible (except on Heavy, not good yet) and i got excellent results on RX550 and vega, good on RX560 and 7850, and decent on RX570/580
I've finished the Bittube-v4 fork assemblies (ouch, ~100 asm files to update) and openCL (with the same bad perf than Heavy). And fixed the netcode, but i want to test more before release.
I expect the CPU version of bittube-v4 JCE to be a lot faster than on other miners, since I used assembly pseudo-aes implementation and not naive C like others.
There will be a complete release with CPU and 32-bits and Linux this time, not just GPU version.
What a welcome message, thanks!
I already discussed about the real hashrate of close-source miners, and I still claim that some do cheat, the most blantant case for me was Claymore 11.3 on cn-classic.
Just run Claymore 9.7 on an old non-forked coin like Bytecoin. You'll get 99% of the reported hashrate. Do the same with 11.3 and you'll get 90%.
I know about the random factor and the Stale shares, but on exact same pool, exact same hardware, on the long term (>24h) you should get the same ratio.
JCE does no tweak about the hashrate, may everybody check themselves and they can see.
I got good results on Vega, which is funny since i don't even own any myself. But i applied all the best optimizations possible (except on Heavy, not good yet) and i got excellent results on RX550 and vega, good on RX560 and 7850, and decent on RX570/580
I've finished the Bittube-v4 fork assemblies (ouch, ~100 asm files to update) and openCL (with the same bad perf than Heavy). And fixed the netcode, but i want to test more before release.
I expect the CPU version of bittube-v4 JCE to be a lot faster than on other miners, since I used assembly pseudo-aes implementation and not naive C like others.
There will be a complete release with CPU and 32-bits and Linux this time, not just GPU version.
I already discussed about the real hashrate of close-source miners, and I still claim that some do cheat, the most blantant case for me was Claymore 11.3 on cn-classic.
Just run Claymore 9.7 on an old non-forked coin like Bytecoin. You'll get 99% of the reported hashrate. Do the same with 11.3 and you'll get 90%.
I know about the random factor and the Stale shares, but on exact same pool, exact same hardware, on the long term (>24h) you should get the same ratio.
JCE does no tweak about the hashrate, may everybody check themselves and they can see.
I got good results on Vega, which is funny since i don't even own any myself. But i applied all the best optimizations possible (except on Heavy, not good yet) and i got excellent results on RX550 and vega, good on RX560 and 7850, and decent on RX570/580
I've finished the Bittube-v4 fork assemblies (ouch, ~100 asm files to update) and openCL (with the same bad perf than Heavy). And fixed the netcode, but i want to test more before release.
I expect the CPU version of bittube-v4 JCE to be a lot faster than on other miners, since I used assembly pseudo-aes implementation and not naive C like others.
There will be a complete release with CPU and 32-bits and Linux this time, not just GPU version.
so im trying to load this on simpleminingOS. what is a good example of config line to put in for mining?
What a welcome message, thanks!
I already discussed about the real hashrate of close-source miners, and I still claim that some do cheat, the most blantant case for me was Claymore 11.3 on cn-classic.
Just run Claymore 9.7 on an old non-forked coin like Bytecoin. You'll get 99% of the reported hashrate. Do the same with 11.3 and you'll get 90%.
I know about the random factor and the Stale shares, but on exact same pool, exact same hardware, on the long term (>24h) you should get the same ratio.
JCE does no tweak about the hashrate, may everybody check themselves and they can see.
I got good results on Vega, which is funny since i don't even own any myself. But i applied all the best optimizations possible (except on Heavy, not good yet) and i got excellent results on RX550 and vega, good on RX560 and 7850, and decent on RX570/580
I've finished the Bittube-v4 fork assemblies (ouch, ~100 asm files to update) and openCL (with the same bad perf than Heavy). And fixed the netcode, but i want to test more before release.
I expect the CPU version of bittube-v4 JCE to be a lot faster than on other miners, since I used assembly pseudo-aes implementation and not naive C like others.
There will be a complete release with CPU and 32-bits and Linux this time, not just GPU version.
I already discussed about the real hashrate of close-source miners, and I still claim that some do cheat, the most blantant case for me was Claymore 11.3 on cn-classic.
Just run Claymore 9.7 on an old non-forked coin like Bytecoin. You'll get 99% of the reported hashrate. Do the same with 11.3 and you'll get 90%.
I know about the random factor and the Stale shares, but on exact same pool, exact same hardware, on the long term (>24h) you should get the same ratio.
JCE does no tweak about the hashrate, may everybody check themselves and they can see.
I got good results on Vega, which is funny since i don't even own any myself. But i applied all the best optimizations possible (except on Heavy, not good yet) and i got excellent results on RX550 and vega, good on RX560 and 7850, and decent on RX570/580
I've finished the Bittube-v4 fork assemblies (ouch, ~100 asm files to update) and openCL (with the same bad perf than Heavy). And fixed the netcode, but i want to test more before release.
I expect the CPU version of bittube-v4 JCE to be a lot faster than on other miners, since I used assembly pseudo-aes implementation and not naive C like others.
There will be a complete release with CPU and 32-bits and Linux this time, not just GPU version.
Ok,
I managed to run the JCe on one of my 7xVega 56 rigs
So far results are amazing
14200-14350H/s, I run the miner for 14 hours on support XMR and pool reported exact the same number of hashes as the miner after 14 hours. This is so much better when Srbminer or Cast. When I asked about this problem in Srbminer topic, nobody cared and everybody made fun of me explaining that it is normal for hashrate to fluctuate and didn't even care for my elaboration. Now, I shut the rig down as it is in my home and I could not stand the noise
Tomorrow, I will switch all my rigs to JCE. Please keep developing, this will be fantastic miner.
I managed to run the JCe on one of my 7xVega 56 rigs
So far results are amazing
14200-14350H/s, I run the miner for 14 hours on support XMR and pool reported exact the same number of hashes as the miner after 14 hours. This is so much better when Srbminer or Cast. When I asked about this problem in Srbminer topic, nobody cared and everybody made fun of me explaining that it is normal for hashrate to fluctuate and didn't even care for my elaboration. Now, I shut the rig down as it is in my home and I could not stand the noise
Tomorrow, I will switch all my rigs to JCE. Please keep developing, this will be fantastic miner.
yes I got message from users from everywhere about the duplicated shares, my fix for Nicehash has a huge regression impact on the normal netcode (of course some parts are common). I'm fixing right now, i'll release a 0.30c with Bittube-v4 is i can do it in time, plus netcode fix.
any hints why Ryzen starts with 180hs per Thread and drop to 130hs after some minutes (CNV7 lite)
and yes..got many duplicates at no nicehash pool
and yes..got many duplicates at no nicehash pool
is it with Nicehash or a normal pool?
I hope i havent made a regression because of my Nicehash fixes
I'm implementing Bittube-v2 right now
I hope i havent made a regression because of my Nicehash fixes
I'm implementing Bittube-v2 right now
I seem to submit duplicate shares with CN v7, which leads to banning from the pool. I am using the last beta version.
I added a troubleshooting section on the github page, and added the optimal vega config
Yes, i've lowered the intensity, now it's working with stellite, but not with IPBC, I tried with heavy and IPBC variations.
With heavy algo 4Gb cards max intensity is 496-512. Higher volumes can decrease speed or drop it to 0.
Yes, i've lowered the intensity, now it's working with stellite, but not with IPBC, I tried with heavy and IPBC variations.
Here is my config: (3X RX570)
"gpu_threads_conf" :
[
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 0, "multi_hash": 944},
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 0, "multi_hash": 944},
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 1, "multi_hash": 992},
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 1, "multi_hash": 992},
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 2, "multi_hash": 992},
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 2, "multi_hash": 992},
],
Here is my start.bat:
jce_cn_gpu_miner64.exe -c config.txt --any --forever --no-cpu -o mining.bit.tube:15555 -u bxdWD*******S5zNmeioRQahVNGgyxBL1boqPpEmv -p Z***t %SSL% %*
Kernels are compiled but y hashrate is 0 with IPBC ot Stellite (when changing pool in start.bat)
What am I doing wrong please ?
Thanks
Cards with 4Gb video memory? "gpu_threads_conf" :
[
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 0, "multi_hash": 944},
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 0, "multi_hash": 944},
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 1, "multi_hash": 992},
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 1, "multi_hash": 992},
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 2, "multi_hash": 992},
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 2, "multi_hash": 992},
],
Here is my start.bat:
jce_cn_gpu_miner64.exe -c config.txt --any --forever --no-cpu -o mining.bit.tube:15555 -u bxdWD*******S5zNmeioRQahVNGgyxBL1boqPpEmv -p Z***t %SSL% %*
Kernels are compiled but y hashrate is 0 with IPBC ot Stellite (when changing pool in start.bat)
What am I doing wrong please ?
Thanks
Here is my config: (3X RX570)
"gpu_threads_conf" :
[
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 0, "multi_hash": 944},
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 0, "multi_hash": 944},
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 1, "multi_hash": 992},
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 1, "multi_hash": 992},
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 2, "multi_hash": 992},
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 2, "multi_hash": 992},
],
Here is my start.bat:
jce_cn_gpu_miner64.exe -c config.txt --any --forever --no-cpu -o mining.bit.tube:15555 -u bxdWD*******S5zNmeioRQahVNGgyxBL1boqPpEmv -p Z***t %SSL% %*
Kernels are compiled but y hashrate is 0 with IPBC ot Stellite (when changing pool in start.bat)
What am I doing wrong please ?
Thanks
"gpu_threads_conf" :
[
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 0, "multi_hash": 944},
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 0, "multi_hash": 944},
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 1, "multi_hash": 992},
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 1, "multi_hash": 992},
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 2, "multi_hash": 992},
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 2, "multi_hash": 992},
],
Here is my start.bat:
jce_cn_gpu_miner64.exe -c config.txt --any --forever --no-cpu -o mining.bit.tube:15555 -u bxdWD*******S5zNmeioRQahVNGgyxBL1boqPpEmv -p Z***t %SSL% %*
Kernels are compiled but y hashrate is 0 with IPBC ot Stellite (when changing pool in start.bat)
What am I doing wrong please ?
Thanks
Thanks UnclWish for all your rants about my nicehash netcode, so i could fix it 
Bittube v2 will keep a decent speed with JCE CPU since i'm the king of software aes in assembly, but there will be a huge penality compared to original IPBC. It's algo is fine tuned to be good on gpu only.
i'll add the new best config for Vega 64 on GitHub, thanks
yeah my code for heavy is bad, i even tell it in the doc, i haven't have time to improve it yet
Bittube v2 will keep a decent speed with JCE CPU since i'm the king of software aes in assembly, but there will be a huge penality compared to original IPBC. It's algo is fine tuned to be good on gpu only.
i'll add the new best config for Vega 64 on GitHub, thanks
yeah my code for heavy is bad, i even tell it in the doc, i haven't have time to improve it yet
For monero using Vega 64 I got improved performance upgrading from the first release.
00:49:36 | Hashrate GPU Thread 0: 1064.70 h/s
00:49:36 | Hashrate GPU Thread 1: 1063.73 h/s - Total GPU 0: 2128.42 h/s
Overclocks:
Core 1408 MHz @ 905 mV
Memory 1100 MHz @ 900 mV
This config.txt setting seems slightly better than the previous one I posted:
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 0, "multi_hash":1936 },
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 0, "multi_hash":1936 },
I tried increasing intensity to 1952 but hashrate dropped, so maybe 1936 could be the max.
00:49:36 | Hashrate GPU Thread 0: 1064.70 h/s
00:49:36 | Hashrate GPU Thread 1: 1063.73 h/s - Total GPU 0: 2128.42 h/s
Overclocks:
Core 1408 MHz @ 905 mV
Memory 1100 MHz @ 900 mV
This config.txt setting seems slightly better than the previous one I posted:
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 0, "multi_hash":1936 },
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 0, "multi_hash":1936 },
I tried increasing intensity to 1952 but hashrate dropped, so maybe 1936 could be the max.
ok, i've an idea about where it could come from. My last idea.
I looked at the new Bittube v2, they use a tweaked AES algo to prevent the CPUs to use their native hardware AES instruction. No problem to implement it, but i'll have tons of assemblies to update
I looked at the new Bittube v2, they use a tweaked AES algo to prevent the CPUs to use their native hardware AES instruction. No problem to implement it, but i'll have tons of assemblies to update
So then is it true that this will make it unprofitable to mine on a CPU?
I've re-uploaded the 0.30b with the extra Nicehash fix. I recheck at every step the Job and the nonce is still valid. And again before sending the result to the pool. If nicehash after that still says the nonce is invalid or the job doesn't exist, well, i'm out of ideas.
i also added the total cpu hashrate in the log.
Invalid nonce is well known bug with nicehash pool. But duplicate shares and job not found maybe fixed, i think.i also added the total cpu hashrate in the log.
I'll try updated version right now. Thanks!
EDIT: Well, now fixed version is more-more stable and without any rejects allready an hour. Hope it will be all time ))). Effective speed close to hashrate. Good job!
EDIT2: Speed on V7 very good! But speed on heavy almost the same as on v7... Only a little bit faster. But on other miners heavy up to 7-10% faster on 8Gb cards. I think that your code in heavy algo can be improved...
Jump to: