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

[ljglug]

Can't the 033j version run on ubuntu 18.04?

[JCE-Miner]

the drop of 1-2 h/s is due to the auto legacy, but it tends to cause either a negligible drop or a big hashrate restore, so it's now enabled most of the time.
thanks again for the report!

CPU video: you uploaded a second one, about config, thanks!
overlooked topics are Bittube v2 mining (my miner is a lot faster, like +30%, on all cpus) and other Heavy algo (still have better perf on most cpu, with a tighter gain). but Heavy is rather an algo for gpu.

i'll release a new cpu version for win and linux soon, with the Bulldozer assembly, fixed thank to Unclwish.

[Uaciuganadu]

Hey Jce,

What's the current status of the GPU miner? There have been so many changes and reverts, its confuzing. For V8, is the miner in the same ballpark with SRB and TRM? Last time i checked i could not even get close. What are the best settings for vega 64 and 580 8G?

[JCE-Miner]

yeah my hybrid thing caused more regressions than performance, in the b14 all is somehow fixed.
i still consider TeamRed the best deal for v8 on big RX, thanks to its low power draw.
otherwise, well configured, i should provide performances very close, in a 2% margin. taking the power and fees into account, TeamRed remains the best on cards they support, but my miner works down to the HD6000


{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "index" : ..., "multi_hash":1632 },
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "index" : ..., "multi_hash":1632 },

try this for RX 8G, with adjustments by step of 16 for multi_hash

for vega:
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "index" : ..., "multi_hash":1904 },
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "index" : ..., "multi_hash":1904 },

ditto, and try beta=16 too

[aazmega]

Hey JCE!

I`m mining with your CPU miner about 5 months. I got 2 AMD FX 8350. Picked v8 forks, as cryptonight heavy looks bad for my cpus.
I`m getting about 300-330h/s on 7 cores(keeping 1 core for GPUs). Do you think it`s better to switch CPUs on light or some other algo for better efficiency?

Thanks!

[JCE-Miner]

Hi!

About the Athlon-FX, i'm about to release a CPU version with the backport of the Bulldozer fix and optim, as detected by Unclwish.
Compared to the 33j, it should give you a few extra hashes, on par with the older version 33h

Best CPU algo:
Some maths. The Cryptonight algo is made of three main parts, and a few negligible other:
* Explode
* Scratchpad
* Implode

The 1st and 3rd are simple AES rounds on predictable memory addresses. A non-AES cpu will make it slow, unless using JCE where it would be 35% faster, but still quite slow, and an AES Cpu like the Athlon-FX will make it almost instantly. An AES CPU is like an AES cypher ASIC.

GPU do these steps quite slow, because an EAS round on GPU involves dozens of computations and LDS memory accesses.

The step 2 is slow in both cases.
The CPU are overall very fast, but they compute something like 4, 8, 12 CN hashes at the same time, on a common CPU (ultra-pimped Threadrippers/Xeons of course can do 64 or more, JCE supports up to 256).
GPU do like 500 to 4000 at the same time, so they are overall more efficient.

The trick is to choose for CPU the biggest steps 1 and 3 and the smallest step 2.
The best algo for this are:
* Cryptonight MKT (slightly smaller step 2 than Monero)
* Cryptonight Fast/Masari (better, the step 2 is half of Monero)
* Uplexa (still better, the step 2 is quarter of Monero)

Also, while the normal cache allocation is 2M, Heavy-like algo (Ryo, Haven, Tube...) use 4M and Uplexa use 1M. GPU have such a large memory to work with that the difference is tight, in both case they use all their memory and computing power.
But modern CPUs tend to run out of cache (while old CPUs like Core2 had a lot of cache but lacked cores). Use a twice smaller cache allocation allows to use twice more cores, and often double the performance.

This is why mining Monero on CPU often makes it run at 50% or 66%, while mining on GPU always makes it run at 100%.
GPUs dont' run out of cache because they simply don't really use it (*), they rely on their fast memory. They are designed for this. A CPU has a much slower memory but a very efficient cache.

My advice: technically, mine uPlexa. Just i don't know if its market value will get good, but the algo is fine for CPU.

(*) A typical real-life GPU operation is blitting a 64M texture in a game. In such case, having 256K or 512K cache or even 16M cache is useless. This is why GPUs are designed to work with async uncached fast memory, while CPU are cached and sync.

edit:
Here's the 0.33k CPU Windows (linux comes next)

Very minor revision, with a fix for Bulldozer family on x64 for v8. No other change.

Fork status:
AscendingNight: done but hidden, and likely to be dropped since the devs no longer reply on Github and the only 2 pools are offline. Sad, it was a good CPU algo, like uPlexa.
Stellite v8: done but hidden, i want a real pool to validate my devs, and haven't found any.
Turtle v2: ditto
Hycon: not started yet and i don't like this coin, looks like a normal CN algo with pedantic netcode changes. I may add it but not sure. I don't see a reason to mine it neither on GPU or CPU.

[UnclWish]

I didn't use CPU and old GPU for mining at now. 100-125 Watt CPU too much energy cost for 300-350 h/s on heavy. It's too much even for 500 h/s on v8...

[GKumaran]

Yeah Uplexa seems extremely well rounded and spot on with the cpu/gpu usage margins !!
Congrats to the devs.

[ILYA_Zzz]

Sorry in advance if the question is stupid.
JCE miner has the ability to remotely control, like Clamore remote manager? Start, stop, edit config ...
If not, is such an upgrade planned?

[ganzocrypt]

I am testing this miner and I am getting the following results:

on 6 RX 580 8Gb + 1 RX580 4 Gb, a 21.1K h/s mining uPlexa, and what surprise me is that I am consuming 220 Watts!?

Does it make sense or can be better?

Any settings to improve hash rate?

Thx

[JCE-Miner]

I won't comment your minning speed with no comparison point. Just uPlexa is very like TurtleCoin but still a lot faster in the step 2, as described before. I consider uPlexa better suited for big CPU mining like Ryzen 1600 and above, those with 12, 16 or more cores.

@Unclwish: i admit than even with the extra perf my miner provide on old hardware like Core2 or Pitcairn, those devices will be no longer profitable unless you have free electricity. I've shut down my own old rigs for now, including my lovely Core2Quad + penta-Pitcairn The best rig... of the previous decade.

@ILYA_Zzz:
i read your comment in Claymore's topic but avoided to answer there because... well that topic belongs to Claymore, not me.
That's very interresting since i didn't get the sense of managing

* Monitor: yes, with a JSON http server (disabled by default, can be enabled with --mport)
* Start/Stop : nope, but that's both very simple and smart. More below.
* Configure : you can put the config in a separate JSON file (a text file), and if edited between a stop and a start, it will be applied, so i consider that's a yes.

An example of this config file is the serviceconfig.txt packed in the .zip
edit, run JCE with no param, and you're good.
The CPU/GPU fine tuning is also done with a file, the command line params like --auto or -t are for the simple mining for begginers. The params -p, -u, -o are inspired from Claymore config, to be precise, that's on purpose.

Start/stop: when i was still a miner using Claymore 9.7, that marvel of software, there were like 6 CN coins including one or two non-scam, and always profitable. And one fork. So then you run Claymore, on CN-classic, and that's it. No need for management.
Meanwhile i see all got more complex, and one would like to switch algo or coin on the fly, or stop the minning when it gets no longer profitable.

So that's ok, i'll add a HTTP signal handler to pause, resume, restart or stop the miner. Not hard.
To switch algo, you will edit the config file, and restart. JCE starts very fast, both on CPU and GPU, so it will be a valid way to switch coin.

[Iamtutut]

Seems MASARI will also change their algo, with CN FASTV2:
 https://www.reddit.com/r/masari/comments/a917ic/oh_snap_cnfastv2/

[ljglug]

Hi!

About the Athlon-FX, i'm about to release a CPU version with the backport of the Bulldozer fix and optim, as detected by Unclwish.
Compared to the 33j, it should give you a few extra hashes, on par with the older version 33h

Best CPU algo:
Some maths. The Cryptonight algo is made of three main parts, and a few negligible other:
* Explode
* Scratchpad
* Implode

The 1st and 3rd are simple AES rounds on predictable memory addresses. A non-AES cpu will make it slow, unless using JCE where it would be 35% faster, but still quite slow, and an AES Cpu like the Athlon-FX will make it almost instantly. An AES CPU is like an AES cypher ASIC.

GPU do these steps quite slow, because an EAS round on GPU involves dozens of computations and LDS memory accesses.

The step 2 is slow in both cases.
The CPU are overall very fast, but they compute something like 4, 8, 12 CN hashes at the same time, on a common CPU (ultra-pimped Threadrippers/Xeons of course can do 64 or more, JCE supports up to 256).
GPU do like 500 to 4000 at the same time, so they are overall more efficient.

The trick is to choose for CPU the biggest steps 1 and 3 and the smallest step 2.
The best algo for this are:
* Cryptonight MKT (slightly smaller step 2 than Monero)
* Cryptonight Fast/Masari (better, the step 2 is half of Monero)
* Uplexa (still better, the step 2 is quarter of Monero)

Also, while the normal cache allocation is 2M, Heavy-like algo (Ryo, Haven, Tube...) use 4M and Uplexa use 1M. GPU have such a large memory to work with that the difference is tight, in both case they use all their memory and computing power.
But modern CPUs tend to run out of cache (while old CPUs like Core2 had a lot of cache but lacked cores). Use a twice smaller cache allocation allows to use twice more cores, and often double the performance.

This is why mining Monero on CPU often makes it run at 50% or 66%, while mining on GPU always makes it run at 100%.
GPUs dont' run out of cache because they simply don't really use it (*), they rely on their fast memory. They are designed for this. A CPU has a much slower memory but a very efficient cache.

My advice: technically, mine uPlexa. Just i don't know if its market value will get good, but the algo is fine for CPU.

(*) A typical real-life GPU operation is blitting a 64M texture in a game. In such case, having 256K or 512K cache or even 16M cache is useless. This is why GPUs are designed to work with async uncached fast memory, while CPU are cached and sync.

edit:
Here's the 0.33k CPU Windows (linux comes next)

Very minor revision, with a fix for Bulldozer family on x64 for v8. No other change.

Fork status:
AscendingNight: done but hidden, and likely to be dropped since the devs no longer reply on Github and the only 2 pools are offline. Sad, it was a good CPU algo, like uPlexa.
Stellite v8: done but hidden, i want a real pool to validate my devs, and haven't found any.
Turtle v2: ditto
Hycon: not started yet and i don't like this coin, looks like a normal CN algo with pedantic netcode changes. I may add it but not sure. I don't see a reason to mine it neither on GPU or CPU.

Hi, developer
I hope you can release a version of the ubuntu18.04 system that can be run, thank you very much for your hard work.

[JCE-Miner]

Sure, online is the 0.33k CPU Linux

Masari: yeah, yet another fork
And again with no reference dedicated miner and no test pool.
Otherwise it looks like just Masari with the v2 additions, so if that's it, it will be easy to add.

I've still found no pool for test on Stellite v8 or Turtle v2.

[migo77]

Sure, online is the 0.33k CPU Linux

Masari: yeah, yet another fork
And again with no reference dedicated miner and no test pool.
Otherwise it looks like just Masari with the v2 additions, so if that's it, it will be easy to add.

I've still found no pool for test on Stellite v8 or Turtle v2.

Hi JCE, seems that k version restored speed of g  version. But I can't still see +30%  improvement over xmr-stak on my old non-AES hardware 

[JCE-Miner]

Surprising.
Just benched, between last JCE and last xmrstak, official release, not recompiled myself.
Using autoconfig to mine Monero v8 in both cases, 4 threads on my Core2Quad Xeon oc@ 2.666G

Code:

[2018-12-25 20:23:41] : Your CPU doesn't support hardware AES. Don't expect high hashrates.
[2018-12-25 20:23:41] : Mining coin: cryptonight_v8
[2018-12-25 20:23:41] : Starting 2x thread, affinity: 0.
[2018-12-25 20:23:41] : hwloc: memory pinned
[2018-12-25 20:23:41] : Starting 1x thread, affinity: 1.
[2018-12-25 20:23:41] : hwloc: memory pinned
[2018-12-25 20:23:41] : Starting 2x thread, affinity: 2.
[2018-12-25 20:23:41] : hwloc: memory pinned
[2018-12-25 20:23:41] : Starting 1x thread, affinity: 3.
[2018-12-25 20:23:41] : hwloc: memory pinned
[2018-12-25 20:25:15] : New block detected.
HASHRATE REPORT - CPU
| ID |    10s |    60s |    15m | ID |    10s |    60s |    15m |
|  0 |   12.5 |   11.5 |   (na) |  1 |   14.2 |   13.5 |   (na) |
|  2 |   13.6 |   13.0 |   (na) |  3 |   14.8 |   14.4 |   (na) |
Totals (CPU):    55.2   52.4    0.0 H/s

Code:

For Windows 64-bits
Analyzing Processors topology...
Intel(R) Xeon(R) CPU L5408 @ 2.13GHz
Assembly codename: core2_sse4
Preparing 4 Mining Threads...
20:26:36 | Hashrate CPU Thread 0: 22.92 h/s
20:26:36 | Hashrate CPU Thread 1: 23.79 h/s
20:26:36 | Hashrate CPU Thread 2: 24.33 h/s
20:26:36 | Hashrate CPU Thread 3: 24.52 h/s
20:26:36 | Total: 95.55 h/s - Max: 96.24 h/s

So that's even more than +30%.

What CPU and algo did you test on?

[Iamtutut]

Sure, online is the 0.33k CPU Linux

Masari: yeah, yet another fork
And again with no reference dedicated miner and no test pool.
Otherwise it looks like just Masari with the v2 additions, so if that's it, it will be easy to add.

I've still found no pool for test on Stellite v8 or Turtle v2.

Turtle fork will happen in roughly 100K blocks.

[UnclWish]

JCE, what optimal parameters for Core i3 6100 3M L3 cache cn-v8?
I can reach 64 h/s on JCE and 75 h/s on XMRig.

[migo77]

Surprising.
Just benched, between last JCE and last xmrstak, official release, not recompiled myself.
Using autoconfig to mine Monero v8 in both cases, 4 threads on my Core2Quad Xeon oc@ 2.666G

Code:

[2018-12-25 20:23:41] : Your CPU doesn't support hardware AES. Don't expect high hashrates.
[2018-12-25 20:23:41] : Mining coin: cryptonight_v8
[2018-12-25 20:23:41] : Starting 2x thread, affinity: 0.
[2018-12-25 20:23:41] : hwloc: memory pinned
[2018-12-25 20:23:41] : Starting 1x thread, affinity: 1.
[2018-12-25 20:23:41] : hwloc: memory pinned
[2018-12-25 20:23:41] : Starting 2x thread, affinity: 2.
[2018-12-25 20:23:41] : hwloc: memory pinned
[2018-12-25 20:23:41] : Starting 1x thread, affinity: 3.
[2018-12-25 20:23:41] : hwloc: memory pinned
[2018-12-25 20:25:15] : New block detected.
HASHRATE REPORT - CPU
| ID |    10s |    60s |    15m | ID |    10s |    60s |    15m |
|  0 |   12.5 |   11.5 |   (na) |  1 |   14.2 |   13.5 |   (na) |
|  2 |   13.6 |   13.0 |   (na) |  3 |   14.8 |   14.4 |   (na) |
Totals (CPU):    55.2   52.4    0.0 H/s

Code:

For Windows 64-bits
Analyzing Processors topology...
Intel(R) Xeon(R) CPU L5408 @ 2.13GHz
Assembly codename: core2_sse4
Preparing 4 Mining Threads...
20:26:36 | Hashrate CPU Thread 0: 22.92 h/s
20:26:36 | Hashrate CPU Thread 1: 23.79 h/s
20:26:36 | Hashrate CPU Thread 2: 24.33 h/s
20:26:36 | Hashrate CPU Thread 3: 24.52 h/s
20:26:36 | Total: 95.55 h/s - Max: 96.24 h/s

So that's even more than +30%.

What CPU and algo did you test on?

Hi JCE, here is my comparsion:

{
  "hashrate":
  {
    "thread_0": 19.08,
    "thread_1": 19.08,
    "thread_2": 19.07,
    "thread_3": 19.08,
    "thread_4": 19.12,
    "thread_5": 19.11,
    "thread_6": 19.12,
    "thread_7": 19.12,
    "thread_all": [19.08, 19.08, 19.07, 19.08, 19.12, 19.11, 19.12, 19.12],
    "total": 152.72,
    "max": 152.74
  },
  "result":
  {
     "wallet": "xxx",
     "pool": "xxx",
     "ssl": false,
     "reconnections": 0,
     "currency": "Monero (XMR/XMV)",
     "difficulty": 5000,
     "shares": 1554,
     "hashes": 7797738,
     "uptime": "14:38:16",
     "effective": 147.98
  },
  "miner":
  {
     "version": "jce/0.33k/cpu",
     "platform": "Dual Intel(R) Xeon(R) CPU E5520 @ 2.27GHz",
     "system": "Linux 64-bits",
     "algorithm": "15"
  }
}

and

XMR-Stak Monero Miner
Hashrate
Results
Connection
Hashrate Report
Thread ID   10s   60s   15m   H/s
0   9.4   9.4   9.4
1   9.4   9.4   9.4
2   9.4   9.4   9.4
3   9.4   9.4   9.4
4   9.3   9.3   9.4
5   9.3   9.3   9.4
6   15.3   15.3   15.3
7   9.4   9.4   9.4
8   9.4   9.4   9.4
9   9.4   9.4   9.4
10   9.4   9.4   9.4
11   9.3   9.4   9.4
12   9.3   9.4   9.4
13   4.3   4.4   4.4
14   9.4   9.4   9.4
15   4.3   4.4   4.4
Totals:   146.9   147.0   147.2
Highest:   148.9   

Your miner is marginally faster, but no 30% in this case   I'm not complaining but want to find problem.

[JCE-Miner]

Turtle:

CN_Turtle Testnet – Now that PoW algo [1] has been announced for block 1,200,000 lets start testing it all out. The project needs some people to run some infrastructure (seed nodes, pool, explorer). We’ll also need some testers to send a few hundred hashes at it and check the miners are all OK as they get updated. In the next day or two we’ll be able to compile the testnet bits [2] and even just run straight from containers [3] then we’ll aim for an upgrade height for around midnight Saturday UTC specifically block 1,060,600. So anyone that wants to help out with infrastructure bits please ping me SoreGums#8071 in discord [4] to get added to #dev_testnet, everyone has access to view this channel if you’re curious as well. – soregums

Sure, i'm waiting for their test pool.
Source: https://blog.turtlecoin.lol/archives/this-week-last-week-in-turtlecoin-dec-10th-17th-2018/

@migo:
Looks like my miner uses 8 threads and stak uses 16, and stak is probably right to do such.
Can you copy-paste the beginning of my log, where it detects the CPUs ?

Otherwise, try this manual config, which is very like the one of stak:

Code:

"cpu_threads_conf" : 
[ 
     { "cpu_architecture" : "auto", "affine_to_cpu" : 0, "use_cache" : true },
     { "cpu_architecture" : "auto", "affine_to_cpu" : 1, "use_cache" : true },
     { "cpu_architecture" : "auto", "affine_to_cpu" : 2, "use_cache" : true },
     { "cpu_architecture" : "auto", "affine_to_cpu" : 3, "use_cache" : true },
     { "cpu_architecture" : "auto", "affine_to_cpu" : 4, "use_cache" : true },
     { "cpu_architecture" : "auto", "affine_to_cpu" : 5, "use_cache" : true },
     { "cpu_architecture" : "auto", "affine_to_cpu" : 6, "use_cache" : true },
     { "cpu_architecture" : "auto", "affine_to_cpu" : 7, "use_cache" : true },
     { "cpu_architecture" : "auto", "affine_to_cpu" : 8, "use_cache" : true },
     { "cpu_architecture" : "auto", "affine_to_cpu" : 9, "use_cache" : true },
     { "cpu_architecture" : "auto", "affine_to_cpu" : 10, "use_cache" : true },
     { "cpu_architecture" : "auto", "affine_to_cpu" : 11, "use_cache" : true },
     { "cpu_architecture" : "auto", "affine_to_cpu" : 12, "use_cache" : true },
     { "cpu_architecture" : "auto", "affine_to_cpu" : 13, "use_cache" : true },
     { "cpu_architecture" : "auto", "affine_to_cpu" : 14, "use_cache" : true },
     { "cpu_architecture" : "auto", "affine_to_cpu" : 15, "use_cache" : true },
]

@Unclwish:
try those:

Code:

"cpu_threads_conf" : 
[ 
     { "cpu_architecture" : "auto", "affine_to_cpu" : 0, "use_cache" : true },
     { "cpu_architecture" : "auto", "affine_to_cpu" : 1, "use_cache" : true },
     { "cpu_architecture" : "auto", "affine_to_cpu" : 2, "use_cache" : true },
     { "cpu_architecture" : "auto", "affine_to_cpu" : 3, "use_cache" : true },
]

Code:

"cpu_threads_conf" : 
[ 
     { "cpu_architecture" : "auto", "affine_to_cpu" : 0, "use_cache" : true },
     { "cpu_architecture" : "auto", "affine_to_cpu" : 1, "use_cache" : false },
     { "cpu_architecture" : "auto", "affine_to_cpu" : 2, "use_cache" : true },
     { "cpu_architecture" : "auto", "affine_to_cpu" : 3, "use_cache" : false },
]

But on a small AES intel CPU, i'm not that faster, when i am. Except on Bittube. It's possible i don't even compensate for the 1.5% fees, assuming you compiled xmrig with no fees.