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

[rednoW]

should double hash provide advantage for ryzen 1600? it has more than 2 mb L3 cache  per physical core

[warning_btc]

fees are crazy
what you think about that

[UnclWish]

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%.

[UnclWish]

should double hash provide advantage for ryzen 1600? it has more than 2 mb L3 cache  per physical core

Try religion does not allow?

[JCE-Miner]

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.

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.

[rednoW]

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.

[JCE-Miner]

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

[Larvitar]

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?

[JCE-Miner]

Hi !
Nice i've users from all the world Bitcointalk magic

I advise to use the -q parameter : it quits at first network problem. And with a .bat you can loop forever:

Code:

:MineXmr
jce_cn_cpu_miner64 -q --low ......
goto :MineXmr

this way at each connection problem you restart miner, you'll loose just a few seconds at each problem, probably negligible.
And the default wait between two network attemps is 5s, so restarting the miner or waiting for 5s is just the same delay.

I'm doing a huge refactoring of my assembly for factorize more, to provide multi-hash from triple- to hexa- at the same time. Current version provides only simple and double.

[Larvitar]

Hi !
Nice i've users from all the world Bitcointalk magic

I advise to use the -q parameter : it quits at first network problem. And with a .bat you can loop forever:

Code:

:MineXmr
jce_cn_cpu_miner64 -q --low ......
goto :MineXmr

this way at each connection problem you restart miner, you'll loose just a few seconds at each problem, probably negligible.
And the default wait between two network attemps is 5s, so restarting the miner or waiting for 5s is just the same delay.

I'm doing a huge refactoring of my assembly for factorize more, to provide multi-hash from triple- to hexa- at the same time. Current version provides only simple and double.

I'm from the newest Brazil's province. Yeah, Bitcointalk magic

Just for feedback:
Ryzen 7 1700 at 3.6GHz and 3200MHz memory (16-16-16-36 1T) can reach 2400H/s mining CN-Lite. I'm having problems to stabilize at this. At 2933 memory I can reach around 2200H/s. So, the bottleneck is clairly de memory.

Is there a specific timing that improve CN mining? I know the L3 cache runs at memory frequency and takes advantage of main latencies. For GPUs I know it likes FAW lowered.

[Titipong007]

JCE Cryptonote CPU Miner

Welcome to the Fastest Cryptonote CPU Miner ever!

Github page: https://github.com/jceminer/cn_cpu_miner
You can download it from the GitHub page or directly here:
https://github.com/jceminer/cn_cpu_miner/raw/master/jce_cn_cpu_miner.025.zip



Is that a Virus? No!

Like all miners, JCE gets detected as a virus by most Antiviruses, including Windows Defender. But it's not. Read more about Privacy and Security below.

Is it just yet-another fork of a common miner? No!

You're not losing your time testing a made-up rip of a common miner, JCE is brand new, using 100% new code.

Are the new Monero-V, Cryptolight-V7 and Cryptonight-Heavy forks supported? Yes!

The --variation parameter let you choose the fork. More details below.

Speed

In short, JCE is:

• Crazy fast on non-AES 64-bits, usually 35-40% faster than other miners
• Still faster on non-AES 32-bits, usually beating even the other miners 64-bits versions
• And still faster on non-AES 32-bits Cryptonight-Heavy, with usually +50% speed.
• Barely faster than the other best on AES 64-bits, beating them by ~1%, +2.8% on V7 fork
• Also a lot faster on AES 32-bits, but it's a rare case (mostly seen on Intel Atom tablets)

   
Here's a benchmark against three other common miners.
The test is fair: run on the exact same Win10 Pro computer, all Huge Pages enabled, no background task, best configuration.

• XMRStak means: the released Unified binary from github (not recompiled myself)
• XMRig means: the respective best released binary gcc (32-bits) and msvc (64-bits) from github (not recompiled myself)
• Claymore means: best Claymore CPU (3.4 for 32-bits, 3.9 for 64-bits)
• When not supported, score is zero, if not tested yet, score is ?
• Fees are included in the score

Core2 Quad 2.666 GHz, 4 threads, 64-bits, Cryptonight

JCE	XMRStak	XMRig	Claymore
116	80	85	57

Core2 Quad 2.666 GHz, 4 threads, 32-bits, Cryptonight

JCE	XMRStak	XMRig	Claymore
93	0	68	50

Ryzen 1600, 8 threads, 64-bits, Cryptonight

JCE	XMRStak	XMRig	Claymore
506	502	502	443

Ryzen 1600, 8 threads, 32-bits, Cryptonight

JCE	XMRStak	XMRig	Claymore
434	0	327	275

Ryzen 1600, 8 threads, 64-bits, Cryptonight V7

JCE	XMRStak	XMRig	Claymore
503	492	491	?

Ryzen 1600, 8 threads, 32-bits, Cryptonight V7

JCE	XMRStak	XMRig	Claymore
424	0	320	?

Core2 Quad 2.666 GHz, 4 threads, 64-bits, Cryptonight Heavy

JCE	XMRStak	XMRig	Claymore
50	33	36	0

Ryzen 1600, 4 threads, 64-bits, Cryptonight Heavy

JCE	XMRStak	XMRig	Claymore
252	169	250	0

Ryzen 1600, 4 threads, 32-bits, Cryptonight Heavy

JCE	XMRStak	XMRig	Claymore
191	0	174	0

Basic topics

Q. Is it free (as in beer, as in freedom)?
No and no. It has fees, and is not open source. But the program itself is free to distribute.

Q. How much cost the fees?
Current fees are:

    3.0% when using at least one mining thread with non-AES architecture, or 32-bits
    1.5% when using only 64-bits AES architecture

The fees are twice higher in non-AES mode and/or 32-bits because JCE offers a huge performance gain here.

Q. Can I avoid fees?
Not really. I plan to offer a paying per-licence-no-fee (pay-once-for-all) version, but it's a lot more complicated to set up than a fee-based miner.
Also, JCE never takes any fee during the first minute, so if you run it, and kill it after one minute, and repeat again and again, then you'll never pay any fee, but JCE takes a few seconds to start, and your Pool probably won't let your reconnect continuously.

Q. Will it work on my computer?
Minimum is Windows 7 32-bits, with a SSE2 capable CPU. 64-bits is faster, prefer it.
For best performance, Huge Pages must be enabled, JCE will try to auto-configure them, but it may work or not depending on your Windows version and security configuration.

Q. What currency can I mine? On which pools?
You can mine any coin on any pool.
If your coin is listed, all is automatic.
Run the miner with --coins parameter to get the up-to-date list. Current list is:

    Monero (XMR)
    Monero-V (XMV)
    Electroneum (ETN)
    Karbowanec (KRB)
    Bytecoin (BCN)
    Sumokoin (SUMO)
    Bitcoal (COAL)
    Bitcedi (BXC)
    Dinastycoin (DCY)
    Leviarcoin (XLC)
    Fonero (FNO)
    Turtlecoin (TRTL)
    Graft (GRFT)
    Dero (DERO)
    Stellite (XTL)
    UltraNote (XUN)
    Intense (INTS)
    Crepcoin (CREP)
    Pluracoin (PLURA)
    Haven (XHV)
    FreelaBit (FBF)
    BlueberriesCoin (BBC)
    B2BCoin (B2B)
    Bitsum (BSM)
    Masari (MSR)
    SuperiorCoin (SUP)
    EDollar (EDL)
    Interplanetary Broadcast (IPBC)
    Masari (MSR)
    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)
    Nicehash Cryptonight v7
    Minergate Cryptonight
    MiningPoolHub Cryptonight
    MiningRigRentals Cryptonight v7
    Suprnova Cryptonight

Otherwise, use the --any parameter, plus the --variation N parameter, with N the fork number, see list below. The fork detection is automatic on known coins, but manual on unknown coins. The coin list is periodically updated.

Q. Is Nicehash supported?
Yes, see list above. The Nicehash-specific Nonce is then automatically enabled.

Q. Is SSL supported?
Yes, with parameter --ssl

Q. I get only bad shares, what happens?
Your coin has probably forked. Add --variation N parameter, with N as listed below, until you find the one that works.

Q. Is there a HTTP server to monitor the miner?
No, modern pools provide all you need to monitor your miners (average hashrate, worker-id...). Monitoring is now a pool's job.

Advanced topics

Q. Are there requirements or dependencies?
No. JCE is just a big standalone .exe

Q. Is there a Linux version?
Not yet.

Q. Is there a GPU version?
Not yet.

Q. Is there a 32-bits version?
Yes, both 32 and 64 are always in the same release.

Q. How many threads can I setup?
Maximum is 64 threads on 64 CPUs.

Q. Do I get a discount on fees if I use SSL?
I'm not Claymore.

Q. What is that value logged when I find a share?
The amount of hashes your pool will credit you. This is not the amount of crypto-coins.

Q. How is developed JCE?
The network and stratum handling is C++14, and the mining algos are assembly (to be precise, GNU Extended Assembly). Hence the speed increase.

Q. Can I plug it to a stratum proxy?
No, it must mine on a real pool on Internet.

Q. Is it really new? It looks familiar to me...
Yes it is. But it reuses, on purpose, some de-facto conventions from other common miners, like a XMRStak-style cpu configuration, and the colors of Claymore (green=share, red=error, blue=hashrate, yellow=status).

Q. How is the hashrate calculated?
That's the average speed of the last 512 hashes (not shares found, computed hashes), rounded at 0.01. And it's fair, the displayed number has no tweak, and includes the fees. The total is first summed from exact per-thread values, then rounded (said differently, it's a rounded sum, not sum of rounded).

Q. Can I get a long-time speed average?
Better look at your pool's reports, but JCE also gives the average effective net hashrate when pressing R. It's usually slightly lower than the physical hashrate because of outdated shares and fees.

Q. Can I do multi-pool auto-switch in case of failure? Or periodically?
Not directly, but the -q and/or the --autoclose parameters, with the help of a simple .bat, can do the job. The .zip comes with an example, open and edit it to match your needs.

Q. Can I mix architectures when mining (i.e. thread 1 uses core2, thread 2 uses pentium4)?
It sounds strange, but yes. However, that's mostly useful for tests.

Q. I used "use_cache":false and it still has a strong negative impact on other threads
The no-cache mode means the cache is instantly invalidated once used, not always entirely bypassed, depending on your hardware. And a mining thread always has an impact on TLB. So don't try to use extra mining threads playing with the no-cache mode, rather use the dual-thread mining, which is made for that precise purpose.

Q. What a great job! Can I make a donation?
Thanks bro. You can, with the --donate parameter which raise the fees to 80%, or by sending coins to the donation wallet (the one in the start.bat file included).

Cryptonight Forks

All current forks are supported:

    N=0 Automatic
    N=1 Original Cryptonight
    N=2 Original Cryptolight (for AEON)
    N=3 Cryptonight V7 fork of April-2018
    N=4 Cryptolight V7 fork of April-2018
    N=5 Cryptonight-Heavy
    N=6 Cryptolight-IPBC

The current Automatic mode behaves the old way on alt-coins:

    Monero, Monero-V and Stellite are now Cryptonight V7,
    Sumokoin is now Cryptonight-Heavy,
    Aeon is still Cryptolight
    TurtleCoin is now Cryptolight V7
    Interplanetary Broadcast has is own Cryptolight-IPBC
    Everything else is still assumed Cryptonight

More will be updated once all coins have forked (~May-2018)

To use the new forks right now, set the --variation N parameter, with N as stated above.
If you mine an unlisted coin with --any, you have to provide the --variation parameter with N>=1, otherwise JCE cannot choose the good fork.

Configuration

Almost everything is configured with command-line parameters. The config file is for cpu fine tuning only. See the embedded .bat for an example.
Mandatory parameters are:

    -u the Wallet/Login
    -p the password ("x" usually works)
    -o the pool:port
    --auto or -c for CPU configuration

Important extra parameters are:

    --ssl if you use SSL
    --low not to freeze your PC if you mine with all cores
    --variation to use one of the new Cryptonight forks

Type --help to get the complete list.

Super Easy CPU configuration

Use --auto and you're good.

Normal Easy CPU configuration

Use --auto with:

    --archi to set the CPU architecture (if you force SSE4 or AES on a CPU with no support, it will crash).
    and/or -t to set the number of threads.

The list of architectures is in the config.example.txt file in the Zip.

Advanced CPU configuration

Use -c
See the config.example.txt file in the Zip for details.

Dual-thread mining

This is an exclusive feature of JCE!
It is not like the double-hash found on Stak, with one thread on two hashes. That's two threads on two hashes, but sharing the cache and the Huge Page, for CPUs with very low cache.
The principle is closer to Claymore Dual: use the smooth parts of the Cryptonight algo to let another thread use the cache and memory, then take it back. It allows the main thread to run at ~90% and the side thread at ~25%, totaling a speed increase of ~15%.
However, if this mode is powerful, it offers a gain only on some rare, old CPU:

• With no hardware AES (hardware AES is so fast that the master thread has no time to share)
• Not using Cryptonight-Heavy (it's so... heavy that the master thread has no resource to share)
• With low cache but decent compute power (read: no Atom or antique P4)

Remains some entry-level Core2, Athlons and Celeron/Pentium.

Large Pages

To be explained...

Privacy and Security

Q. Is it a virus?
No. There's no malicious code at all, but since the source code is closed, I cannot prove it. The best I can do is to give a complete list of what the program does and doesn't.

Q. So, what does it do or not?
It does:

• Read the configuration file, if asked to (parameter -c)
• Scan your CPU and cache to autoconfigure and/or check the manual configuration
• Connect to pools on Internet to mine
• Write the log, if asked to (parameter --log)
• Try to autoconfigure the Huge Pages privileges if they're not working at first. That's the only intrusive action, but when it does it, it says so.

It doesn't:

• Write anything to your computer, except its own log, when enabled (default is disabled)
• Send any information, to me nor anywhere else
• Identify your computer or miner instance, not even using a hash
• Punch through your firewall: you have to open it manually if needed

Q. I see the JCE process punching the attrib command, what is it doing?
JCE does never run attrib, nor any other command, but it disguises its mining process into a attrib to avoid being detected and erased by antiviruses. Again, JCE does nothing malicious, and like all other miners it's detected as a virus so I've to do such a trick. That's the normal behavior of the 64-bits version. I never had the 32-bits detected, so I don't use that trick with it.

[Bazzaar]

Nice results with IPBC on Xeon cpus.

E5 2630L @2000MHz;

1100h/s using 14 of the 16 cores

E5 5640 @3333MHz;

700h/s using 10 of the 12 cores.

These are the processors in my two mining rigs, running 4x RX Vegas and 3x GTX1070 respectively.
Each rig needs two cores to run the gpu miners.

Baz

[JCE-Miner]

Hi !
Nice i've users from all the world Bitcointalk magic

I advise to use the -q parameter : it quits at first network problem. And with a .bat you can loop forever:

Code:

:MineXmr
jce_cn_cpu_miner64 -q --low ......
goto :MineXmr

this way at each connection problem you restart miner, you'll loose just a few seconds at each problem, probably negligible.
And the default wait between two network attemps is 5s, so restarting the miner or waiting for 5s is just the same delay.

I'm doing a huge refactoring of my assembly for factorize more, to provide multi-hash from triple- to hexa- at the same time. Current version provides only simple and double.

I'm from the newest Brazil's province. Yeah, Bitcointalk magic

Just for feedback:
Ryzen 7 1700 at 3.6GHz and 3200MHz memory (16-16-16-36 1T) can reach 2400H/s mining CN-Lite. I'm having problems to stabilize at this. At 2933 memory I can reach around 2200H/s. So, the bottleneck is clairly de memory.

Is there a specific timing that improve CN mining? I know the L3 cache runs at memory frequency and takes advantage of main latencies. For GPUs I know it likes FAW lowered.

except if you go over your cache limits, memory shoudn't have big impact. it's better to play with Performance or similar modes in Bios which lower cache timings and give huge cryponight speed boost.

thanks for the report baz, i'm working on multi hash over 2, that's good for you the cn-light and ipbc miners

to the guy who quoted the full doc : it makes the topic harder to read

[Larvitar]

Hi !
Nice i've users from all the world Bitcointalk magic

I advise to use the -q parameter : it quits at first network problem. And with a .bat you can loop forever:

Code:

:MineXmr
jce_cn_cpu_miner64 -q --low ......
goto :MineXmr

this way at each connection problem you restart miner, you'll loose just a few seconds at each problem, probably negligible.
And the default wait between two network attemps is 5s, so restarting the miner or waiting for 5s is just the same delay.

I'm doing a huge refactoring of my assembly for factorize more, to provide multi-hash from triple- to hexa- at the same time. Current version provides only simple and double.

I'm from the newest Brazil's province. Yeah, Bitcointalk magic

Just for feedback:
Ryzen 7 1700 at 3.6GHz and 3200MHz memory (16-16-16-36 1T) can reach 2400H/s mining CN-Lite. I'm having problems to stabilize at this. At 2933 memory I can reach around 2200H/s. So, the bottleneck is clairly de memory.

Is there a specific timing that improve CN mining? I know the L3 cache runs at memory frequency and takes advantage of main latencies. For GPUs I know it likes FAW lowered.

except if you go over your cache limits, memory shoudn't have big impact. it's better to play with Performance or similar modes in Bios which lower cache timings and give huge cryponight speed boost.

thanks for the report baz, i'm working on multi hash over 2, that's good for you the cn-light and ipbc miners

to the guy who quoted the full doc : it makes the topic harder to read

The Ryzen's L3 cache runs at memory clock. There is a huge gain from 2133 to 2800, and smaller gains at 2800+ for Cryptonight V7. For Lite, as I can see, there is more room to improvements clocking high memory (and, of course, L3 cache). 10% from 2933 to 3200.

[JCE-Miner]

ryzen L3 is at mem clock ? hoo, i didn't know, even if i have one. it reminds me the old pentium and motherboard L2 clocked at bus speed. i edit my post, thanks

[UnclWish]

ryzen L3 is at mem clock ? hoo, i didn't know, even if i have one. it reminds me the old pentium and motherboard L2 clocked at bus speed. i edit my post, thanks

Hmmm, what is the situation with L3 cache on FX83xx ?

[s0ftcorn]

ryzen L3 is at mem clock ? hoo, i didn't know, even if i have one. it reminds me the old pentium and motherboard L2 clocked at bus speed. i edit my post, thanks

Hmmm, what is the situation with L3 cache on FX83xx ?

http://www.cpu-world.com/CPUs/Bulldozer/AMD-FX-Series%20FX-8350.html

[UnclWish]

ryzen L3 is at mem clock ? hoo, i didn't know, even if i have one. it reminds me the old pentium and motherboard L2 clocked at bus speed. i edit my post, thanks

Hmmm, what is the situation with L3 cache on FX83xx ?

http://www.cpu-world.com/CPUs/Bulldozer/AMD-FX-Series%20FX-8350.html

Not info about cache speed.

FX83xx proccessors have 8Mb L3 cache shared between all cores and L2 cache 2Mb per 2 cores.
Questions:
1. Miner uses both L2 and L3 caches?
2. If miner uses L2 cache and affinity threads to cores is not set, this means that L2 cache can be shared 1Mb to thread used for mining and 1Mb to thread not used for miner.

Or I misunderstand something?

[JCE-Miner]

if you let "use_cache" to its default true, all levels of cache are used. otherwise, none. as said in the doc, not used doesn't always implies not impacted.

ryzen L3 is at mem clock ? hoo, i didn't know, even if i have one. it reminds me the old pentium and motherboard L2 clocked at bus speed. i edit my post, thanks

Hmmm, what is the situation with L3 cache on FX83xx ?

i've a Bulldozer (an Excavator to be precise) on my rig to test, but broken for now. i'll do complete tests once possible.

[UnclWish]

if you let "use_cache" to its default true, all levels of cache are used. otherwise, none. as said in the doc, not used doesn't always implies not impacted.

ryzen L3 is at mem clock ? hoo, i didn't know, even if i have one. it reminds me the old pentium and motherboard L2 clocked at bus speed. i edit my post, thanks

Hmmm, what is the situation with L3 cache on FX83xx ?

i've a Bulldozer (an Excavator to be precise) on my rig to test, but broken for now. i'll do complete tests once possible.

I'm answered because imho L2 cache didn't use by miner... Maybe I'm wrong.
But after 4 threads (4x2=8Mb) speed stops to grow with adding threads, it just reduces in every threads so speed stays nearly the same...