Can you please ad this coin https://arqma.com/ ?
Algo is light v7
Topic: [XMR] JCE Miner Cryptonight/forks, now with GPU! - page 93. (Read 90841 times)
thanks for the feedback 
your results are suprising on 270X on my hd7870 i really was far above Claymore, and Claymore is easy to configure.
against srb, well i probably didn't configure it at max but i couldn't reach the 540 i get on JCE. i'll retry with your exact same settings.
to disable opencl, parameter --no-gpu
also a very important thing, i let opencl allocate resource progressively, so the max hashrate is reached after a few minutes. at start, jce is often at 80% speed. Claymore punch the card to the max immediately. i'll add a message when the miner starts so people are not disapointed.
your results are suprising on 270X on my hd7870 i really was far above Claymore, and Claymore is easy to configure.
against srb, well i probably didn't configure it at max but i couldn't reach the 540 i get on JCE. i'll retry with your exact same settings.
to disable opencl, parameter --no-gpu
also a very important thing, i let opencl allocate resource progressively, so the max hashrate is reached after a few minutes. at start, jce is often at 80% speed. Claymore punch the card to the max immediately. i'll add a message when the miner starts so people are not disapointed.
Thanks for gpu update!
Tested new gpu part of miner...
What can I say... It's very good! Very!
Now my results. Tested on 270X 4Gb and RX 580 8Gb.
On all my cards best alpha is 64. 128 always lower speed, especcially on 270X.
Other greeks have too small affect...
CN-v7
270X - 528 h/s (m.hash - 464), Claymore 11.3 - 550 h/s and NO FEE (-h 460 -dmem 1)
RX580 - 970-975 h/s (m.hash - 1152), Claymore 11.3 - 967 h/s and NO FEE (-h 1152 -dmem 1), SRB miner 1.6.0 - 1025 h/s devfee 0.85% (intensity - 117)
CN-Heavy
270X - 412 h/s (m.hash - 448), Claymore 11.3 - no algo support, SRB miner 1.6.0 - 410-420 h/s devfee 0.85% (intensity - 27-28)
RX580 - 990 h/s (m.hash - 944), Claymore 11.3 - no algo support, SRB miner 1.6.1 - 1120 h/s devfee 0.85% (intensity - 59.5)
I didn't compare with XMRig and Stak because they are slower on my cards than Claymore or SRB. GGS is often between Claymore and SRB...
And another one thing: on RX 580 miner is stable. But on 270X 4Gb it often hangs computer till restart. Claymore 11.3 is very stable for it. So as SRB.
On Claymore and SRB it's more fine tuning of intensity. Your miner supports only multihash devided by 16. It's impossible to set multihash 460 for 270X, but it will be more speedy than 464, as I can see on Claymore.
All cards have modded bioses. And of course all tests was made on the same overclock and voltage settings. Drivers 18.6.1 Windows 10 x64 1803.
Good work! But it's still many improvements need to do.
P.S. Please make an option to disable detecttion of OpenCl devices so miner will be only CPU miner. OpenCL detection can affect on other miners if they allready running during your miner startup.
Tested new gpu part of miner...
What can I say... It's very good! Very!
Now my results. Tested on 270X 4Gb and RX 580 8Gb.
On all my cards best alpha is 64. 128 always lower speed, especcially on 270X.
Other greeks have too small affect...
CN-v7
270X - 528 h/s (m.hash - 464), Claymore 11.3 - 550 h/s and NO FEE (-h 460 -dmem 1)
RX580 - 970-975 h/s (m.hash - 1152), Claymore 11.3 - 967 h/s and NO FEE (-h 1152 -dmem 1), SRB miner 1.6.0 - 1025 h/s devfee 0.85% (intensity - 117)
CN-Heavy
270X - 412 h/s (m.hash - 448), Claymore 11.3 - no algo support, SRB miner 1.6.0 - 410-420 h/s devfee 0.85% (intensity - 27-28)
RX580 - 990 h/s (m.hash - 944), Claymore 11.3 - no algo support, SRB miner 1.6.1 - 1120 h/s devfee 0.85% (intensity - 59.5)
I didn't compare with XMRig and Stak because they are slower on my cards than Claymore or SRB. GGS is often between Claymore and SRB...
And another one thing: on RX 580 miner is stable. But on 270X 4Gb it often hangs computer till restart. Claymore 11.3 is very stable for it. So as SRB.
On Claymore and SRB it's more fine tuning of intensity. Your miner supports only multihash devided by 16. It's impossible to set multihash 460 for 270X, but it will be more speedy than 464, as I can see on Claymore.
All cards have modded bioses. And of course all tests was made on the same overclock and voltage settings. Drivers 18.6.1 Windows 10 x64 1803.
Good work! But it's still many improvements need to do.
P.S. Please make an option to disable detecttion of OpenCl devices so miner will be only CPU miner. OpenCL detection can affect on other miners if they allready running during your miner startup.
JCE GPU to be released very soon. My code is done, i just need to polish some error messages and we go.
It will be an early protototype with very little doc and no autoconfig, but functional.
Performance : i thinks there's a difference in config in both case, there's no -34% or +80% perf difference on Ryzen, maybe 5-6%.
Be careful, the feature names are different, on JCE variation is the fork, while on xmrig it's the multi-hash, that XMRStak call low-power.
It may worth to look exactly at the chosen threads (number, cpu assignment, and multi-hash) on both and double-check it's the same.
However on old CPU like core2, JCE is really +35% faster.
Here's what I expect to be the best manual config on ryzen 1800x
My stock R5 1600 gives ~498 h/s on XMR with JCE, and ~489 with stak, so your 330h/s looks strange, and even the 500 h/s of stak seems low.
JCE is not compatible with any proxy/socks, it must mine direct to pool. That's a security feature to avoid hackers embed the miner into a tunneled botnet. As I already said, I observed Claymore went this way, and I do the same.
edit
GPU prototype available
see first post
There's a little doc example in the github page. Only the manual config can enable the GPU for now. Autoconfig is still cpu-only.
It will be an early protototype with very little doc and no autoconfig, but functional.
Performance : i thinks there's a difference in config in both case, there's no -34% or +80% perf difference on Ryzen, maybe 5-6%.
Be careful, the feature names are different, on JCE variation is the fork, while on xmrig it's the multi-hash, that XMRStak call low-power.
It may worth to look exactly at the chosen threads (number, cpu assignment, and multi-hash) on both and double-check it's the same.
However on old CPU like core2, JCE is really +35% faster.
Here's what I expect to be the best manual config on ryzen 1800x
Code:
"cpu_threads_conf" :
[
{ "cpu_architecture" : "auto", "affine_to_cpu" : 0, "use_cache" : true, "multi_hash":1 },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 2, "use_cache" : true, "multi_hash":1 },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 4, "use_cache" : true, "multi_hash":1 },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 6, "use_cache" : true, "multi_hash":1 },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 8, "use_cache" : true, "multi_hash":1 },
{ "cpu_architecture" : "auto", "affine_to_cpu" :10, "use_cache" : true, "multi_hash":1 },
{ "cpu_architecture" : "auto", "affine_to_cpu" :12, "use_cache" : true, "multi_hash":1 },
{ "cpu_architecture" : "auto", "affine_to_cpu" :14, "use_cache" : true, "multi_hash":1 },
]
[
{ "cpu_architecture" : "auto", "affine_to_cpu" : 0, "use_cache" : true, "multi_hash":1 },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 2, "use_cache" : true, "multi_hash":1 },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 4, "use_cache" : true, "multi_hash":1 },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 6, "use_cache" : true, "multi_hash":1 },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 8, "use_cache" : true, "multi_hash":1 },
{ "cpu_architecture" : "auto", "affine_to_cpu" :10, "use_cache" : true, "multi_hash":1 },
{ "cpu_architecture" : "auto", "affine_to_cpu" :12, "use_cache" : true, "multi_hash":1 },
{ "cpu_architecture" : "auto", "affine_to_cpu" :14, "use_cache" : true, "multi_hash":1 },
]
My stock R5 1600 gives ~498 h/s on XMR with JCE, and ~489 with stak, so your 330h/s looks strange, and even the 500 h/s of stak seems low.
JCE is not compatible with any proxy/socks, it must mine direct to pool. That's a security feature to avoid hackers embed the miner into a tunneled botnet. As I already said, I observed Claymore went this way, and I do the same.
edit
GPU prototype available
see first post
There's a little doc example in the github page. Only the manual config can enable the GPU for now. Autoconfig is still cpu-only.
I gave it a go to see how it compares with XMR-Stack on my dual mining rigs. My results below are for CPU only.
XMR: 500h/s (XMR-Stack) vs 330h/s (JCE)
=> ryzen 1800x
=> 34% decrease in hashrate
LOKI: 100h/s (XMR-Stack) vs 180h/s (JCE)
=> ryzen 1700x
=> 80% increase n hashrate
For both, the config file is the same. Startup batch is different as i mining different coins using different algos on different pools.
I am amazed how huge the hashrate variance is between the two coins. But nevertheless very happy to see the hashrate of Loki go up so much.
Is there any explanation for the variance between the two coins?
I'll stick with XMR-Stack on Monero and see how JCE goes for a few days on Loki.
XMR: 500h/s (XMR-Stack) vs 330h/s (JCE)
=> ryzen 1800x
=> 34% decrease in hashrate
LOKI: 100h/s (XMR-Stack) vs 180h/s (JCE)
=> ryzen 1700x
=> 80% increase n hashrate
For both, the config file is the same. Startup batch is different as i mining different coins using different algos on different pools.
I am amazed how huge the hashrate variance is between the two coins. But nevertheless very happy to see the hashrate of Loki go up so much.
Is there any explanation for the variance between the two coins?
I'll stick with XMR-Stack on Monero and see how JCE goes for a few days on Loki.
Yes it works, i tested, but use --low on the cpu miner or it can annoy the gpu one. As a general rule, always use --low. it should have been the default value, but that's too late now i don't want to break interface.
to disable all cpu config and mining on the gpu version, parameter --no-cpu
the reciprocal --no-gpu exists too, but in such case, better stay on the pure cpu release.
to disable all cpu config and mining on the gpu version, parameter --no-cpu
the reciprocal --no-gpu exists too, but in such case, better stay on the pure cpu release.
When do you plan to release the GPU version for testing?
can i use this miner with xmr-proxy?
https://imgur.com/a/Pb3Zps0
https://github.com/xmrig/xmrig-proxy
rem All is good ! Let's mine
@echo on
jce_cn_cpu_miner%BITS%.exe --auto --any --forever --nicehash --variation %FORK% --low -o %POOL%:%PORT% -u %WALLET% -p %PASSWORD% %SSL% %*
@pause
https://imgur.com/a/Pb3Zps0
https://github.com/xmrig/xmrig-proxy
rem All is good ! Let's mine
@echo on
jce_cn_cpu_miner%BITS%.exe --auto --any --forever --nicehash --variation %FORK% --low -o %POOL%:%PORT% -u %WALLET% -p %PASSWORD% %SSL% %*
@pause
Yes it works, i tested, but use --low on the cpu miner or it can annoy the gpu one. As a general rule, always use --low. it should have been the default value, but that's too late now i don't want to break interface.
to disable all cpu config and mining on the gpu version, parameter --no-cpu
the reciprocal --no-gpu exists too, but in such case, better stay on the pure cpu release.
to disable all cpu config and mining on the gpu version, parameter --no-cpu
the reciprocal --no-gpu exists too, but in such case, better stay on the pure cpu release.
New version will allow to run several instances? If I want to mine on CPU other olgo than on GPU...
GPU version done.
Now entering polishing and test phase.
A prototype with no autoconfig will be released soon. There will be only the Windows 64 bits version for GPU+CPU, but CPU-only releases will continue on all platforms.
Can you give me the perf ratio loss when you switch from CN-v7 to CN-Heavy ? I mean, on other miners.
My rx goes down from 528 to 355 which is pretty disapointing, I expected the Heavy hashrate to be similar.
Heavy needed twice amount of video memory. And intensity usual twice less than in CN v7.Now entering polishing and test phase.
A prototype with no autoconfig will be released soon. There will be only the Windows 64 bits version for GPU+CPU, but CPU-only releases will continue on all platforms.
Can you give me the perf ratio loss when you switch from CN-v7 to CN-Heavy ? I mean, on other miners.
My rx goes down from 528 to 355 which is pretty disapointing, I expected the Heavy hashrate to be similar.
On 4Gb 270X max speed on CN-v7 with Claymore 11.3 - 550 h/s (manual modded bios). Intensity 460 (-h 460 -dmem 1)
Heavy on SRB Miner with 26-27 intensity got 400-420 h/s and many HW errors.
Heavy very strange algo... On RX 580 8Gb heavy gives about 10% more speed than CN-v7. But on 4Gb cards heavy gives less speed. Looks like heavy can give the same or even better speed only with 8Gb+ cards.
Thanks for the tip bro, I tested on my very only 4GB card, a RX560 Sapphire and... yes it mines Heavy faster than CN-v7 when i push the memory to max allocation (~3.8G). 380 against 360 (which is a bad score, but that card has very bad memory).
I do the ultimate tests then I release a prototype. As I said, it will be single-algo (mean all gpu and cpu on same pool, same algo) with no GPU autoconfig yet.
GPU fee will be 0.9% (same as the future complete release) and no change for CPU. If you mine with both, it will do a fair linear adjustement.
Code:
22:11:57 | Hashrate CPU Thread 0: 61.29 h/s
22:11:57 | Hashrate CPU Thread 1: 2.93 h/s
22:11:57 | Hashrate CPU Thread 2: 2.93 h/s
22:11:57 | Hashrate CPU Thread 3: 61.65 h/s
22:11:57 | Hashrate CPU Thread 4: 61.81 h/s
22:11:57 | Hashrate CPU Thread 5: 2.94 h/s
22:11:57 | Hashrate CPU Thread 6: 2.94 h/s
22:11:57 | Hashrate CPU Thread 7: 61.68 h/s
22:11:57 | Hashrate GPU Thread 8: 174.52 h/s
22:11:57 | Hashrate GPU Thread 9: 174.04 h/s
22:11:57 | Hashrate GPU Thread 10: 167.87 h/s
22:11:57 | Hashrate GPU Thread 11: 167.84 h/s
22:11:57 | Hashrate GPU Thread 12: 190.95 h/s
22:11:57 | Hashrate GPU Thread 13: 191.54 h/s
22:11:57 | Total: 1324.86 h/s - Max: 1324.86 h/s
22:12:03 | GPU Thread 10 Lane 357 finds a Share, value 16650
22:12:03 | Accepted by the pool.
That's from my Ryzen 1600 (4 cached threads + 4 uncached) + 3x rx560 rig, only the last card (thread 12+13) being a 4G. All cards use dual-mem, and JCE gpu has been developped to use dual-mem on every card, even the small 1G ones. At least, my implementation is always a lot faster with dual-mem than without, even on my old 7790 or 7850.
The "Lane" thing means the Nth parralel compute has found the share. It's stable in memory, during a mining session, the same Lane of same thread use the same memory cells. So it you get bad share from always the same Lane, it's a good way to check if you memory is broken. Yes, JCE has also an indirect video-memtest feature
i was testing an optim on cn-heavy than gave negligible perf increase. then i backtested on previous algos and gpu to look for regression.
and, and don't know why, but on Pitcairn the perf has skyrocketed.
my 7870 now mine at 540 on v7, on par with my 7950, and far above any other miner, even Claymore 9.7
the gain on Tahiti is smaller, i jumped from 540 to 545
and, and don't know why, but on Pitcairn the perf has skyrocketed.
my 7870 now mine at 540 on v7, on par with my 7950, and far above any other miner, even Claymore 9.7
the gain on Tahiti is smaller, i jumped from 540 to 545
Great Job man, please post the GPU version for testing, i have a variety of RX550/570/580 2GB/4GB/8GB cards i would happily test with and provide comparison results with other miners
i was testing an optim on cn-heavy than gave negligible perf increase. then i backtested on previous algos and gpu to look for regression.
and, and don't know why, but on Pitcairn the perf has skyrocketed.
my 7870 now mine at 540 on v7, on par with my 7950, and far above any other miner, even Claymore 9.7
the gain on Tahiti is smaller, i jumped from 540 to 545
It's good news... I waiting to test it... and, and don't know why, but on Pitcairn the perf has skyrocketed.
my 7870 now mine at 540 on v7, on par with my 7950, and far above any other miner, even Claymore 9.7
the gain on Tahiti is smaller, i jumped from 540 to 545
i was testing an optim on cn-heavy than gave negligible perf increase. then i backtested on previous algos and gpu to look for regression.
and, and don't know why, but on Pitcairn the perf has skyrocketed.
my 7870 now mine at 540 on v7, on par with my 7950, and far above any other miner, even Claymore 9.7
the gain on Tahiti is smaller, i jumped from 540 to 545
and, and don't know why, but on Pitcairn the perf has skyrocketed.
my 7870 now mine at 540 on v7, on par with my 7950, and far above any other miner, even Claymore 9.7
the gain on Tahiti is smaller, i jumped from 540 to 545
In wikipedia no info about L1/L2 cache on Epyc. Only L3. Does L1/L2 cache exists on it or not? Just interesting...
P.S. 2Mb L3 cache per thread allready too low... AMD can add more L3 cache on Epyc... Especcially if L1/L2 cache is absent...
My AMD Epyc 7351P has 64 MB shared L3 cache, besides of 16x 512 KB L2 cache dedicated to each core.P.S. 2Mb L3 cache per thread allready too low... AMD can add more L3 cache on Epyc... Especcially if L1/L2 cache is absent...
http://www.cpu-world.com/CPUs/Zen/AMD-EPYC%207351P.html
Nope, it must mine connected direct to real Internet on a real pool. No stratum or proxy or socks support. This is the exact same rule that for Claymore netcode, it proved to be right, so i do the same.
Hi !
Is there support/option for socks5 proxy (like Tor) in config ?
in a way similar to various version of cpuminer
Is there support/option for socks5 proxy (like Tor) in config ?
in a way similar to various version of cpuminer
Code:
-x SOCKS5://127.0.0.1:9050
I tested on a 2G card, my best one is a 4G, i'll give a look, to check i can have same perf on cn-v7 and heavy when i use the whole 4G.
thanks for reply
thanks for reply
GPU version done.
Now entering polishing and test phase.
A prototype with no autoconfig will be released soon. There will be only the Windows 64 bits version for GPU+CPU, but CPU-only releases will continue on all platforms.
Can you give me the perf ratio loss when you switch from CN-v7 to CN-Heavy ? I mean, on other miners.
My rx goes down from 528 to 355 which is pretty disapointing, I expected the Heavy hashrate to be similar.
Heavy needed twice amount of video memory. And intensity usual twice less than in CN v7.Now entering polishing and test phase.
A prototype with no autoconfig will be released soon. There will be only the Windows 64 bits version for GPU+CPU, but CPU-only releases will continue on all platforms.
Can you give me the perf ratio loss when you switch from CN-v7 to CN-Heavy ? I mean, on other miners.
My rx goes down from 528 to 355 which is pretty disapointing, I expected the Heavy hashrate to be similar.
On 4Gb 270X max speed on CN-v7 with Claymore 11.3 - 550 h/s (manual modded bios). Intensity 460 (-h 460 -dmem 1)
Heavy on SRB Miner with 26-27 intensity got 400-420 h/s and many HW errors.
Heavy very strange algo... On RX 580 8Gb heavy gives about 10% more speed than CN-v7. But on 4Gb cards heavy gives less speed. Looks like heavy can give the same or even better speed only with 8Gb+ cards.
GPU version done.
Now entering polishing and test phase.
A prototype with no autoconfig will be released soon. There will be only the Windows 64 bits version for GPU+CPU, but CPU-only releases will continue on all platforms.
Can you give me the perf ratio loss when you switch from CN-v7 to CN-Heavy ? I mean, on other miners.
My rx goes down from 528 to 355 which is pretty disapointing, I expected the Heavy hashrate to be similar.
Now entering polishing and test phase.
A prototype with no autoconfig will be released soon. There will be only the Windows 64 bits version for GPU+CPU, but CPU-only releases will continue on all platforms.
Can you give me the perf ratio loss when you switch from CN-v7 to CN-Heavy ? I mean, on other miners.
My rx goes down from 528 to 355 which is pretty disapointing, I expected the Heavy hashrate to be similar.
When I try the latest version on an AMD Epyc (basically four Ryzen dice on a package) I get the following error:
Thread 30 successfully bound to CPU 30
Allocated 2MB Cached Large Page Scratchpad Buffer for CPU 30 of NUMA node 3 at: 0000021b3c200000
Starting CPU Mining thread 31, affinity: CPU 31
Thread 31 successfully bound to CPU 31
GetNumaProcessorNode failed for cpu 32, error code: 87
Retrying with no NUMA
Allocated 2MB Cached Large Page Scratchpad Buffer at: 0000021b3c400000
Connecting to mining pool support.ipbc.io:17777 ...
Devfee is 1.5%
That's strange because I only defined threads for the CPUs 0 to 31 in the config file.
Why does the miner try to access a CPU (core) 32, which is not present? Apart from that the miner starts mining and has better hashrate than XMR-stak with Bittube: 5200 H/s vs 4900 H/s. 
In wikipedia no info about L1/L2 cache on Epyc. Only L3. Does L1/L2 cache exists on it or not? Just interesting...Thread 30 successfully bound to CPU 30
Allocated 2MB Cached Large Page Scratchpad Buffer for CPU 30 of NUMA node 3 at: 0000021b3c200000
Starting CPU Mining thread 31, affinity: CPU 31
Thread 31 successfully bound to CPU 31
GetNumaProcessorNode failed for cpu 32, error code: 87
Retrying with no NUMA
Allocated 2MB Cached Large Page Scratchpad Buffer at: 0000021b3c400000
Connecting to mining pool support.ipbc.io:17777 ...
Devfee is 1.5%
That's strange because I only defined threads for the CPUs 0 to 31 in the config file.
Why does the miner try to access a CPU (core) 32, which is not present? Apart from that the miner starts mining and has better hashrate than XMR-stak with Bittube: 5200 H/s vs 4900 H/s. P.S. 2Mb L3 cache per thread allready too low... AMD can add more L3 cache on Epyc... Especcially if L1/L2 cache is absent...
L1 -> Level 1
L2 -> Level 2
L3 -> Level 3
as the levels get higher, the cache is slower but larger. Maybe AMD is using some clever technique so L1/L2 caches are more shared than they are already, so mentioning it is useless. But absend L1 or L2 cache would have a huge impact on performance.
I just look in wiki and there no info about L1/L2 on Epyc... Just stays "N\A"...
Not sure which Wikipedia you are looking at, but on https://en.wikipedia.org/wiki/Epyc you can see L2 cache
or even better, on https://en.wikichip.org/wiki/amd/epyc you have even more information
And if you use logic, there is no way a cpu will have L3 cache and not have L2/L1, since in that case L3 becomes L1...
Then you can make a small effort of clicking on a specific CPU and checking the stats... like here: https://en.wikichip.org/wiki/amd/epyc/7351p
Jump to: