[JCE]Fast & stable CN/v8/Heavy/Tube/XHV miner, CPU+GPU, Vega56 1800+ RX580 1200+

[JCE-Miner]

It doesn't work yet, my netcode needs direct connection to the pool. I could fix, but again, it won't be my top priority.

[1715139300]

1715139300

[1715139300]

1715139300

[khairulryan]

Thanks man. I wasn't kidding about the speed, it's really all written in assembly, instruction after instruction. For every Cryptonight variation, for 32 and 64 bits, with or without AES, with or withour dual-mining... Dozens of assembly codes, hence the large binary size.

The hardest to beat was the Original Cryptonight + AES : it's so simple, a big loop that does AES and 64-bits multiply, that there were no room for improvement. I beat a compiler by a small 1% The new, more complex variations let JCE have a real gain over C-based miners.

I'm making 0.18 right now, with support of TRTL version Cryptolight-v7. If you need support of more coins and/or pools, just ask

I know i'm a new member here, but no danger, the miner is not a virus not a trojan, and all hashrate values are real.

Carry on the good work buddy, anyway.. would you include Ultranote (XUN) with the miner? Appreciate it..!!!

[JCE-Miner]

Ok ultranote, in next release.
I found a way to make doublehash but in 64 bits only, in 32 bits i run out of registers very fast, i don't see how to do it well.
I'll give a try.

[UnclWish]

Ok ultranote, in next release.
I found a way to make doublehash but in 64 bits only, in 32 bits i run out of registers very fast, i don't see how to do it well.
I'll give a try.

Please, add Intense coin (ITNS) support.

P.S. I don't see any substantial difference in speed from XMRig on 32-bit nonAES CPU Core i3.

[JCE-Miner]

Ok, Intense to be added too.
I'm writing assembly to add double-hash feature, starting with Aes 64 bits.

I see a huge gain on 32 bits core2, never tested on i3. Is the configuration the same (number of threads, Huge pages...) ? there should be a gap of at least 25%, however the gap is smaller than on 64 bits.

[alivanich]

Monero
-t 7
amd fx 8350@4100MHZ 405h/s
amd fx 8320e@3200MHZ 343h/s

[Nehemoth]

Can please somebody help me out to extract the best performance from my rig?
E-5 2660 v4 @2GHz x2
I can clearly see that there's a lot room for performance as the CPU tab on the Windows task manager only Top 60%
I ran the process twice

Monero
jce_cn_cpu_miner64.1.exe -o stratum+tcp://Pool -u Address -p x --elevate --variation 3 -t 27 --auto
jce_cn_cpu_miner64.1.exe -o stratum+tcp://Pool -u Address -p x --elevate --variation 3 -t 27 --auto

The Affinity jce_cn_cpu_miner64.1.exe run on the CPU 0 only and jce_cn_cpu_miner64.2.exe run on the CPU 1

Definitely I'm getting better performance but if possible would like to extract more.

Thank you

[CryptoCoin101]

When I run the default "start_as_admin" in one thread (-t 1), cryptonight I got small improvement 1-2h/s vesus xmrig (1 minute average h/s). AMD A8-5600K. Should I increase the thread? or avoid the cryptonight algo?

[JCE-Miner]

That's a Piledriver, i haven't one but have an Excavator, i could use it as a test base for that archi. Current optimized assembly is for Ryzen only. And i never tested Intel Aes yet, but got tester reports of mitigate improvement, very close to xmrig.

On forks, jce is better, but on pure Cryptonight aes 64 i beat the compilers by 1%, so if you use one thread only, i'm not suprised the gain is only 1h. When i implement double hash, i may be better.

P.S. I don't see any substantial difference in speed from XMRig on 32-bit nonAES CPU Core i3.

You were right, i re-read my assembly and found a bit optimization mistake. Retested i got a big +5% perf increase. My test core2 gives 93 instead of 88. You can expect 0.19 to be significantly faster on non-aes 32, and slightly on non-aes 64.

Don't start several jce on the same computer, rather use parameter -t or config file to enable more threads. Just there's a limit at 32 threads per jce instance.

[JCE-Miner]

Can please somebody help me out to extract the best performance from my rig?
E-5 2660 v4 @2GHz x2
I can clearly see that there's a lot room for performance as the CPU tab on the Windows task manager only Top 60%

Compute limit tends to be cpu on old ones (core2, p4...) but cache on newer ones. If you run too many threads, you'll flood the cache and get worse performance. My ryzen is a lot better at 8 threads than 9 for example.

Also on you big xeon dual, use the config file to ensure no core is used twice, once by jce 1, once by jce 2. Otherwise perf will be very bad.
The rule is
One thread per 2M cache L3
No two threads on same core

I'm affraid the -t 27 you set affined cpu 0-26 for both jce, which is bad perf.

[Mind163]

Good day. Is it possible to mine coins that are not on the list?

[Lonnegan64]

Hi,

just tried the miner on a test machine. May I ask, why the miner runs Windows' attrib command C:\Windows\System32 all the time? 

[nsummy]

Putting in a request for jceminer to take advantage of L4 cache in a future version

[JCE-Miner]

The binary mimics to be attrib to bypass some antivirus protection, because otherwise the .exe may get deleted, including by Windows Defender. This is an explicit trick, the miner itself does absolutly nothing malicious, i promise. It mines fees 1.5% of time, but that's also an explicit feature.
AV are smart enough to detect mining routines, all miners like claymore are detected as virus and need to trick, that's the game.

Edit : I got this problem with 64 bit version only, 32 bits always gets undetected, probably because asm code is completly different, so i don't do the attrib trick on it.

Version 0.19 on the way, with huge perf gain on 32 bits.

If you need more coins that in the list, just ask here, i filter coin types to make autoconfig and check config consistancy, otherwise the miner behaves the same with any coin.
Claymore did a Monero-or-Anythingelse config style, i prefer check every wallet format to make good error message. But again, jce does not send your wallet to anybody, not even me. Just to your pool to login.

[Lonnegan64]

Thank you for explaining the phenomenon. Perhaps you should document the attrib trick somewhere so people don't get suspicious.

Apropos phenom The 64-bit miner seems to have a bug in combination with AMD K10 arch. I tested your miner because of the fast non-AES-code. On an Intel Core i7 "Lynnfield" everything works fine (except the wrong auto detection as Skylake), but AMD Athlon II X2 "Regor" as well as AMD Phenom II X4 "Deneb" get rejected by the pool due to "low difficulty share". Tested Aeon, Monero, Turtle and Leviar. Something is wrong with the K10 implementation. 

The 32-bit miner seems to be ok, even with Regor and Deneb.

[JCE-Miner]

Sure the attrib explanation worth to be documented. In short, JCE does never call attrib, it disguises into attrib. Hence why you see an attrib process at 100% cpu. To confuse antiviruses, and you too obviously

That's the magic of assembly, some asm code may work or not depending on cpu. I wanted to bypass compiler, i must deal with it.
Also the cpu detection needs tuning, I already saw errors about Yorkfield detection. Without owning the cpu itself, it may be hard to debug

I need to dig up my test Excavator, which should be close enough to your K10 to test.

[JCE-Miner]

0.19 available:

Code:

Big perf improvement for 32-bits
Light improvement for non-aes 64-bits
Support of Intense
Support of UltraNote
Stellite is now Cryptonight V7
new parameter --elevate-and-quit to close parent process

dual-share not ready yet

[Lonnegan64]

I need to dig up my test Excavator, which should be close enough to your K10 to test.

Well, I'm afraid that Excavator has absolutely nothing common with K10. Excavator is the 4th Bulldozer variant with modules instead of cores (CMT), shared L2 caches, AES and AVX, whereas K10 is the last incarnation of good old K8 with classic cores, dedicated L2s, no AES and max SSS3. 

But if I can helf, I would setup a K10 testsystem for you, which you can use via Teamviewer, Anydesk or RDP (depending of your preferences) to fix the issues with this arch

[aGeoM]

... but AMD Athlon II X2 "Regor" as well as AMD Phenom II X4 "Deneb" get rejected by the pool due to "low difficulty share". Tested Aeon, Monero, Turtle and Leviar. Something is wrong with the K10 implementation. 

....

That's the magic of assembly, some asm code may work or not depending on cpu. I wanted to bypass compiler, i must deal with it.
Also the cpu detection needs tuning, I already saw errors about Yorkfield detection. Without owning the cpu itself, it may be hard to debug

I need to dig up my test Excavator, which should be close enough to your K10 to test.

Hi

Same here PhenomII X6 1090T, rejected by the pool due to "low difficulty share", Ryzen7 1700 doing ok (8 threads @725H/s). on v0.18. Going to test 0.19 now-

Thanks and be well...

[bluspirit]

Great job !

XMR ( v0.18 )
-t 2 CPU G4600 @ 3.60GHz ~ 70 h/s
-t 4 CPU i7-3820 @ 3.60GHz ~ 285 h/s

it's probably not the best but I don't like stressing too much my cpus.