Hi JCE. I`m using your miner for the last 2 weeks and it's very good. The best for CN-Lite
But I have a annoying issue: my internet connection is bad (Thanks, Brazil) and when I lost connection, after some time, JCE miner stops trying to connect and stucks.
Is there a argument to avoid it and try to connect forever?
Topic: [XMR] JCE Miner Cryptonight/forks, now with GPU! - page 107. (Read 90815 times)
oh yeah, all bench i give is assumed deditated cpu mining, not shared with gpu miner.
i retested last xmrig 2.6 and on one thread double hash it's stable at 137 and jce variable between 136.8 and 139.3
I rewrote my assembly to get more stable rate between 138.7 and 138.9
So next version should have more stable Hashrate, +1% faster than xmrig on cn v7
on cn-classic we're both at 139
Bug found: if one config line sets multi-hash, all subsequent lines has multihash
workaround: change order of lines, or explicitely set multi_hash: 1
i retested last xmrig 2.6 and on one thread double hash it's stable at 137 and jce variable between 136.8 and 139.3
I rewrote my assembly to get more stable rate between 138.7 and 138.9
So next version should have more stable Hashrate, +1% faster than xmrig on cn v7
on cn-classic we're both at 139
Bug found: if one config line sets multi-hash, all subsequent lines has multihash
workaround: change order of lines, or explicitely set multi_hash: 1
max speed of ryzen 1600 is 8 threads simple with smt enabled. you should get 2.7% more than xmrig or stak on monero v7.
In my case with 2 gpu miners running (ccminer and srbminer) I got performance degradation running 8 threads instead of 6. Either cache got flooded with gpu-miners or not enough compute power of ryzen 1600 to get benefit. I think it is the second.
i measured jce 1h/s faster than xmrig on doublehash on my ryzen, but maybe i don't use the very last xmrig, i need to look again for a new version, it's fair to compare latest vs latest.
even if i'm right, that little +1h doesn't compensate the +0.5% fee. i say i worth them more than xmrig because my code is not a rip of Wolf0 but technically i don't beat it on one doublehash. jce is noticeably faster on full speed with all threads, on one thread, difference is negligible.
@warningbtc: whatever are the fees, i worth them more than stak and xmrig because my code is really original, not a copy of Wolf0 miner like others.
even if i'm right, that little +1h doesn't compensate the +0.5% fee. i say i worth them more than xmrig because my code is not a rip of Wolf0 but technically i don't beat it on one doublehash. jce is noticeably faster on full speed with all threads, on one thread, difference is negligible.
@warningbtc: whatever are the fees, i worth them more than stak and xmrig because my code is really original, not a copy of Wolf0 miner like others.
should double hash provide advantage for ryzen 1600? it has more than 2 mb L3 cache per physical core
max speed of ryzen 1600 is 8 threads simple with smt enabled. you should get 2.7% more than xmrig or stak on monero v7. should double hash provide advantage for ryzen 1600? it has more than 2 mb L3 cache per physical core
Try religion does not allow? 0.25 version is not bad. Doublehash mode works good. Hashrate is not slower than XMRig, but i didn't noticed that JCE faster... Looks like it gives the same speed but with 1,5% devfee against 1% XMRig...
No, I was wrong. More time shows that XMRig is still better 2-3%.
fees are crazy
what you think about that
what you think about that
should double hash provide advantage for ryzen 1600? it has more than 2 mb L3 cache per physical core
0.25 version is not bad. Doublehash mode works good. Hashrate is not slower than XMRig, but i didn't noticed that JCE faster... Looks like it gives the same speed but with 1,5% devfee against 1% XMRig...
Ohh, yeah, that's a larger topic you talk about.
One-word answer : niche
xmrig and stak are good miners. Just borrowing code from Wolf0 with no value added, but they are good. JCE beats them by a few percent, that's probably not enough to make everyone move to me, like the Vega users moved to Cast because it's a lot faster. JCE remains the most profitable cpu miner, even on AES-64, even fees deduced, but the difference is like 2%.
But.. on 32-bits and non-aes (which include a lot of cpu) JCE is a lot faster, enough to make users switch, or even mine with otherwise unused CPU, because with +40% free compute hash power, even a Core2 is profitable again.
(And also technically that's a good challenge to optimize on 32-bits. 64 bits assembly is boring to write)
So here you are.
To make you happier, note that JCE netcode on purpose is locked to explicit mine to explicit pools on real internet. A botnet using some dark proxies to mine in the hood would be blocked, unless the botnet really manages to bypass every protection. Claymore did the same on his miners, and he was probably right.
0.25 online - major update
Multi-hash is never used by autoconfig for now, you must rely on manual config, example from my Xeon 12M cache:
One-word answer : niche
xmrig and stak are good miners. Just borrowing code from Wolf0 with no value added, but they are good. JCE beats them by a few percent, that's probably not enough to make everyone move to me, like the Vega users moved to Cast because it's a lot faster. JCE remains the most profitable cpu miner, even on AES-64, even fees deduced, but the difference is like 2%.
But.. on 32-bits and non-aes (which include a lot of cpu) JCE is a lot faster, enough to make users switch, or even mine with otherwise unused CPU, because with +40% free compute hash power, even a Core2 is profitable again.
(And also technically that's a good challenge to optimize on 32-bits. 64 bits assembly is boring to write)
So here you are.
To make you happier, note that JCE netcode on purpose is locked to explicit mine to explicit pools on real internet. A botnet using some dark proxies to mine in the hood would be blocked, unless the botnet really manages to bypass every protection. Claymore did the same on his miners, and he was probably right.
0.25 online - major update
Code:
multi-hash (max multi: 2 for now)
optimization on all algos, with variable increase (aes-32 gets +5h, aes-64 +1h, other less than 1h)
more coins:
Alloy (XAO)
BBSCoin (BBS)
BitcoiNote (BTCN)
Elya (ELYA)
Iridium (IRD)
Italo (ITA)
Lines (LNS)
Niobio (NBR)
Ombre (OMB)
Solace (SOL)
Triton (TRIT)
Truckcoin (TRKC)
Qwertycoin (QWC)
optimization on all algos, with variable increase (aes-32 gets +5h, aes-64 +1h, other less than 1h)
more coins:
Alloy (XAO)
BBSCoin (BBS)
BitcoiNote (BTCN)
Elya (ELYA)
Iridium (IRD)
Italo (ITA)
Lines (LNS)
Niobio (NBR)
Ombre (OMB)
Solace (SOL)
Triton (TRIT)
Truckcoin (TRKC)
Qwertycoin (QWC)
Multi-hash is never used by autoconfig for now, you must rely on manual config, example from my Xeon 12M cache:
Code:
"cpu_threads_conf" :
[
{ "cpu_architecture" : "auto", "affine_to_cpu" : 0, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 1, "use_cache" : true, "multi_hash": 2 },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 2, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 3, "use_cache" : true, "multi_hash": 2 },
]
[
{ "cpu_architecture" : "auto", "affine_to_cpu" : 0, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 1, "use_cache" : true, "multi_hash": 2 },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 2, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 3, "use_cache" : true, "multi_hash": 2 },
]
I mean what is the reason to release 32-bit code ? It will be useful only for botnets or non-honest sysadmins to run on large old networks.
No miner uses win32 nowadays. Legacy cpus consume more than earn. Only if you steal computer power it will be profitable
If you don't needed 32-bit, it didn't means that nobody needs them. No miner uses win32 nowadays. Legacy cpus consume more than earn. Only if you steal computer power it will be profitable
I mean what is the reason to release 32-bit code ? It will be useful only for botnets or non-honest sysadmins to run on large old networks.
No miner uses win32 nowadays. Legacy cpus consume more than earn. Only if you steal computer power it will be profitable
No miner uses win32 nowadays. Legacy cpus consume more than earn. Only if you steal computer power it will be profitable
i don't get it... 
JCE itself is not a botnet, not malicious at all. Just a miner. So what's the point with botnets? do you think it will be emmbeded into botnets by some hackers? Maybe, but it could be done with any other miner, just JCE is faster on old CPUs. Faster, but not malicious. And i'm probably the only dev not to have stolen code from Wolf0, among with Claymore who also wrote his one from scratch in 2014.
JCE itself is not a botnet, not malicious at all. Just a miner. So what's the point with botnets? do you think it will be emmbeded into botnets by some hackers? Maybe, but it could be done with any other miner, just JCE is faster on old CPUs. Faster, but not malicious. And i'm probably the only dev not to have stolen code from Wolf0, among with Claymore who also wrote his one from scratch in 2014.
speaking about 32 bit code for legacy cpus - are you hoping to get some fees from botnet runners? Isn't it bad? ))
On JCE, 32-bits doublehash does give a noticeable perf boost, at least that's what i observed on my Core2. My assembly code is completely different than other miners in non-aes and 32 bits
on aes 64, well, there's a dedicated instruction for every step of cryptonight (AES, Multiply-128 and for Heavy, also Divide-64) so my assembly is pretty the same than a compiler result, except a few optim than makes me ~3% faster.
Very interresting info about turbo, i'll redo some test with double hash and no CPU core assignment to check
thanks
on aes 64, well, there's a dedicated instruction for every step of cryptonight (AES, Multiply-128 and for Heavy, also Divide-64) so my assembly is pretty the same than a compiler result, except a few optim than makes me ~3% faster.
Very interresting info about turbo, i'll redo some test with double hash and no CPU core assignment to check
thanks
32-bits and non aes are different, the AES/cryptonight compute is so costly here than compute power is more important than cache. you have better result with more threads, period.
but his i7 has AES, so that's very surprising...
note : the upcoming double hash on non-aes 32-bits will give a big perf boost compared to 0.24d, and seems you're using that mode
No, on 32-bit no-EAS double mode gives nothing in speed on other miners. So I just use usual threads on Core i3.but his i7 has AES, so that's very surprising...
note : the upcoming double hash on non-aes 32-bits will give a big perf boost compared to 0.24d, and seems you're using that mode
Double threads I use at home on my FX8320.
Reason why I use double threads on 8320 is next:
1 thread gives about 50-60 h/s, 2 threads - 100-120 h/s, etc. L3 cache is 8Mb. When cache is full - on 4-5 threads CPU gives hashspeed about 250 h/s.
1 double thread gives about 75 h/s. What i'm do - I'm use 1 double thread and 2 single threads or 2 double and 1 single. Result is the up to 225-235 h/s. 3 single threads gives only 150-180 h/s.
In help of double threads I win nearly 1 thread - so less power usage and temperature.
All this possible because of using AMD turbo technology. When CPU uses less than 4 cores it set's on some cores higher frequency and increase hashspeed on them.
If CPU uses 4+ cores turbo technology didn't enables.
Other important notice to use my method - it's not assign threads to cores, or turbo wouldn't work!
And don't forget that it's possible to overclock only turbo frequency, leaving usual frequency the same )))) F.e. my FX8320 is 3,5GHz and 4GHz on turbo. But it's safe to OC turbo clock up to 4,5GHz without any issues and didn't require to up CPU core voltage))))
32-bits and non aes are different, the AES/cryptonight compute is so costly here than compute power is more important than cache. you have better result with more threads, period.
but his i7 has AES, so that's very surprising...
note : the upcoming double hash on non-aes 32-bits will give a big perf boost compared to 0.24d, and seems you're using that mode
but his i7 has AES, so that's very surprising...
note : the upcoming double hash on non-aes 32-bits will give a big perf boost compared to 0.24d, and seems you're using that mode
Sure it's an important detail, but here i think his report is fair. Just to see the 4 threads is faster than the 2 thraeds is crazy, on my core2 and ryzen that's the opposite, going above the cache is counter-productive. But on his Strange i7 low power U, he continualy gets more perfs with more threads, far above cache limit.
New version done, it will be 0.25 major update. I now reach on CN-v7 the perf the 0.24d had on CN classic. I'm right now mining at 504 h/s some CN-v7 with Claymore GPU running in background. stak max at 491 in such condition.
Also 32-bits AES will have a huge perf increase, i jump from 435 to 441
64-bits non aes and 32-bits non aes will have no noticeable increase, just +0.1h/s, beraly noticeable outside a test bench.
I add some more coins on the fly, and i do a last test session. Ready in a few hours.
On my Core i3 on my work 32-bit also this situation. 1 thread gives about 12-15 h/s, 2 threads - about 24-27 h/s, 3 threads - 35-42, 4 threads - 37-45.New version done, it will be 0.25 major update. I now reach on CN-v7 the perf the 0.24d had on CN classic. I'm right now mining at 504 h/s some CN-v7 with Claymore GPU running in background. stak max at 491 in such condition.
Also 32-bits AES will have a huge perf increase, i jump from 435 to 441
64-bits non aes and 32-bits non aes will have no noticeable increase, just +0.1h/s, beraly noticeable outside a test bench.
I add some more coins on the fly, and i do a last test session. Ready in a few hours.
As you can see only after 3 threads hashspeed drop significant. But up to 3 threads speed grows normal. But how it's possible? Core i3 have only 3Mb L3 cache. It must drop speed allready on 2 threads.
Sure it's an important detail, but here i think his report is fair. Just to see the 4 threads is faster than the 2 thraeds is crazy, on my core2 and ryzen that's the opposite, going above the cache is counter-productive. But on his Strange i7 low power U, he continualy gets more perfs with more threads, far above cache limit.
New version done, it will be 0.25 major update. I now reach on CN-v7 the perf the 0.24d had on CN classic. I'm right now mining at 504 h/s some CN-v7 with Claymore GPU running in background. stak max at 491 in such condition.
Also 32-bits AES will have a huge perf increase, i jump from 435 to 441
64-bits non aes and 32-bits non aes will have no noticeable increase, just +0.1h/s, beraly noticeable outside a test bench.
I add some more coins on the fly, and i do a last test session. Ready in a few hours.
New version done, it will be 0.25 major update. I now reach on CN-v7 the perf the 0.24d had on CN classic. I'm right now mining at 504 h/s some CN-v7 with Claymore GPU running in background. stak max at 491 in such condition.
Also 32-bits AES will have a huge perf increase, i jump from 435 to 441
64-bits non aes and 32-bits non aes will have no noticeable increase, just +0.1h/s, beraly noticeable outside a test bench.
I add some more coins on the fly, and i do a last test session. Ready in a few hours.
jce here ya go: anymore testing let me know.
xmr-stak HASHRATE REPORT - CPU
| ID | 10s | 60s | 15m | ID | 10s | 60s | 15m |
| 0 | 37.6 | 39.1 | 36.8 | 1 | 28.9 | 30.0 | 30.3 |
| 2 | 29.5 | 30.4 | 30.3 |
Totals (CPU): 96.1 99.5 97.4 H/s
-----------------------------------------------------------------
Totals (ALL): 96.1 99.5 97.4 H/s
Highest: 101.9 H/s
-----------------------------------------------------------------
jce -t 2
22:19:11 | Hashrate Thread 0: 28.62 h/s
22:19:11 | Hashrate Thread 1: 28.99 h/s
22:19:11 | Total: 57.60 h/s
jce -t 3
22:24:11 | Hashrate Thread 0: 11.98 h/s
22:24:11 | Hashrate Thread 1: 23.96 h/s
22:24:11 | Hashrate Thread 2: 25.70 h/s
22:24:11 | Total: 61.62 h/s
jce -t 4
22:20:30 | Hashrate Thread 0: 11.02 h/s
22:20:30 | Hashrate Thread 1: 18.85 h/s
22:20:30 | Hashrate Thread 2: 16.13 h/s
22:20:30 | Hashrate Thread 3: 23.03 h/s
22:20:30 | Total: 69.02 h/s
Huge pages are availible? Maybe it's through normal memory work? xmr-stak HASHRATE REPORT - CPU
| ID | 10s | 60s | 15m | ID | 10s | 60s | 15m |
| 0 | 37.6 | 39.1 | 36.8 | 1 | 28.9 | 30.0 | 30.3 |
| 2 | 29.5 | 30.4 | 30.3 |
Totals (CPU): 96.1 99.5 97.4 H/s
-----------------------------------------------------------------
Totals (ALL): 96.1 99.5 97.4 H/s
Highest: 101.9 H/s
-----------------------------------------------------------------
jce -t 2
22:19:11 | Hashrate Thread 0: 28.62 h/s
22:19:11 | Hashrate Thread 1: 28.99 h/s
22:19:11 | Total: 57.60 h/s
jce -t 3
22:24:11 | Hashrate Thread 0: 11.98 h/s
22:24:11 | Hashrate Thread 1: 23.96 h/s
22:24:11 | Hashrate Thread 2: 25.70 h/s
22:24:11 | Total: 61.62 h/s
jce -t 4
22:20:30 | Hashrate Thread 0: 11.02 h/s
22:20:30 | Hashrate Thread 1: 18.85 h/s
22:20:30 | Hashrate Thread 2: 16.13 h/s
22:20:30 | Hashrate Thread 3: 23.03 h/s
22:20:30 | Total: 69.02 h/s
Jump to: