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

[JCE-Miner]

sure, let me finish 0.27 with XTL fork (i'm writting assembly right now) and i give all my config i use for benchmark.
Again, i've no big Intel CPU so it may be possible JCE underperform against xmrig on some i7 or Xeon. Assembly requires fine adjustement, that's the game.
I could cheat by stealing xmrig code and compile it, but no. The perf difference of JCE against xmrig/stak, even when negative, is a proof i really write my own code

Note that on Ryzen, 0.26 with autoconfig --auto should already give the best config i found on Ryzen.
I reach 1850 on Turtle and, surprisingly, only 1755 on IPBC while there's only two extra ASM instructions between both.

best config for Ryzen 1600 (should apply to similar Ryzen too like 1600X)

CN-Light, Turtle, IPBC

Code:

"cpu_threads_conf" : 
[ 
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 0, "use_cache" : true, "multi_hash":2 },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 1, "use_cache" : true, "multi_hash":1 },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 2, "use_cache" : true, "multi_hash":1 },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 3, "use_cache" : true, "multi_hash":1 },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 4, "use_cache" : true, "multi_hash":1 },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 5, "use_cache" : true, "multi_hash":1 },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 6, "use_cache" : true, "multi_hash":2 },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 7, "use_cache" : true, "multi_hash":1 },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 8, "use_cache" : true, "multi_hash":1 },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 9, "use_cache" : true, "multi_hash":1 },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" :10, "use_cache" : true, "multi_hash":1 },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" :11, "use_cache" : true, "multi_hash":1 },
]

CN-Classic, V7, Stellite

Code:

"cpu_threads_conf" : 
[ 
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 0, "use_cache" : true, "multi_hash":1 },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 1, "use_cache" : true, "multi_hash":1 },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 2, "use_cache" : true, "multi_hash":1 },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 4, "use_cache" : true, "multi_hash":1 },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 6, "use_cache" : true, "multi_hash":1 },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 7, "use_cache" : true, "multi_hash":1 },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 8, "use_cache" : true, "multi_hash":1 },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" :10, "use_cache" : true, "multi_hash":1 },
]

CN-Heavy

Code:

"cpu_threads_conf" : 
[ 
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 0, "use_cache" : false, "multi_hash":1 },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 1, "use_cache" : false, "multi_hash":1 },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 2, "use_cache" : true, "multi_hash":1 },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 4, "use_cache" : true, "multi_hash":1 },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 6, "use_cache" : true, "multi_hash":1 },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 8, "use_cache" : true, "multi_hash":1 },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" :10, "use_cache" : false, "multi_hash":1 },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" :11, "use_cache" : false, "multi_hash":1 },
]

Not the "use_cache" : false that gives a boost for CN-Heavy, that's a new feature of 0.26+
On previous versions, no-cache was only for super-super-low power mode (one core @10% speed). Now it's also a speed enhancer.

[UnclWish]

Did you tried to not set affinity for threads? But it can affect only when not all cores used...

[JCE-Miner]

i tried, but always got a few h/s less than with affinity set. The autoconfig always assign one CPU.
Did you find a case where no assignment really gave better result ?

[UnclWish]

i tried, but always got a few h/s less than with affinity set. The autoconfig always assign one CPU.
Did you find a case where no assignment really gave better result ?

No assignment can rise hashrate only with enabled Turbo technology and when less or equal half of cores used for mining. If more than half cores used Turbo didn't work...

[JCE-Miner]

i get it, but how non-assignment can help ?
If i've 8 cores for example, isn't it better to assign 4 cores to get the turbo, rather than having 8 cores running anywhere at 50% each, with no turbo ?

edit: a user kindly reported me the speed increase on his Ryzen 1700 with JCE 0.26 compared with JCE 0.25 +5% on CN-Heavy, with optimal config

Code:

"cpu_threads_conf" :  
[  
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 1, "use_cache" : true },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 2, "use_cache" : false },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 3, "use_cache" : false },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 5, "use_cache" : true },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 6, "use_cache" : false },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 7, "use_cache" : false },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 9, "use_cache" : true },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 10, "use_cache" : false },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 11, "use_cache" : false },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 13, "use_cache" : true },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 14, "use_cache" : false },    
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 15, "use_cache" : false },    
]

[JCE-Miner]

0.27 online - major update

Code:

Fix a possible crash when mining IPBC with assembly "generic"
New fork: XTL for Stellite, that's --variation 7
Fixed Loki wallet detection
Updated the documentation and examples in the .zip

[Iamtutut]

0.27 online - major update

Code:

Fix a possible crash when mining IPBC with assembly "generic"
New fork: XTL for Stellite, that's --variation 7
Fixed Loki wallet detection
Updated the documentation and examples in the .zip

What's the purpose of the variation for stellite ? I'm mining it with your 0.25 version.

[UnclWish]

i get it, but how non-assignment can help ?
If i've 8 cores for example, isn't it better to assign 4 cores to get the turbo, rather than having 8 cores running anywhere at 50% each, with no turbo ?

If use all 8 cores there is no way to use turbo and there is no effect on no assigning. And, of course, it's no matter.
I mean for these who not use all CPU to mining, like me ))))
Especially on CPU's on wich almost max speed can be achieved without using all cores, like my FX8320. Max speed is about 250 h/s. It's need to say that this result can be recieved with 8 single cores, or 6 single cores, due to small cache result between 8 threads and 6 differes not much.
200+ h/s can be achieved with 3 threads - thanks to double threads and turbo techno... But with assigning threads to cores turbo techno works not so efficient as without assignment.

Result is 70-80% of max hashspeed + only 40-50% of CPU usage + low power consumption + user can normal work with computer. Even play not hard games.

[JCE-Miner]

Unclewish: ok got it, but that's a special case, autoconfig aims to give max perf in a rig condition.

Stellite: that's a planned fork, today XTL still use CN-v7, but jce 0.27 already flag it as forked. keep 0.25 or use 0.27 with --variation 3 until XTL really forks.

[JCE-Miner]

Bug found! I used a few AVX2 instructions in my aes_avx assembly. And there are some CPUs with AES and AVX but not AVX2

Will be fixed soon, this bug occurs in a pretty rare case, the AVX2 instruction is enabled by autoconfig only for CN-Heavy.

edit: next features
* http server to ease integration into 3rd party tools
* option to reconnect forever, for people with bad Internet access.

edit: 0.27a online - minor revision
fix AVX2 and add --forever parameter
also merge the Monero forks, and stepback XTL to CN-v7, will be XTL-fork later

[UnclWish]

Bug found! I used a few AVX2 instructions in my aes_avx assembly. And there are some CPUs with AES and AVX but not AVX2

Will be fixed soon, this bug occurs in a pretty rare case, the AVX2 instruction is enabled by autoconfig only for CN-Heavy.

edit: next features
* http server to ease integration into 3rd party tools
* option to reconnect forever, for people with bad Internet access.

edit: 0.27a online - minor revision
fix AVX2 and add --forever parameter
also merge the Monero forks, and stepback XTL to CN-v7, will be XTL-fork later

Thanks for update! And very nice name "forever" for parameter. I like it!

[JCE-Miner]

Version 0.27b done, entering test phase.
New feature : HTTP Local Server

new parameter: --mport P (P in [1:65535])
default: disabled

simple JSON output, somehow human readable
example:

Code:

{
  "hashrate":
  {
    "thread_0": 13.75,
    "thread_1": 18.29,
    "thread_2": 21.19,
    "thread_3": 18.85,
    "total": 72.06
  },
  "result":
  {
     "pool": "pool.minexmr.com:4444",
     "ssl": false,
     "currency": "Monero (XMR/XMV/XMC/XMO)",
     "difficulty": 23684,
     "shares": 5,
     "hashes": 84473,
     "uptime": "0:08:28",
     "effective": 166.29
  }
}

edit:
0.27b online - minor revision

change: HTTP server to get monitoring json.
Updated documentation.
No other change.

[sergneo]

Version 0.27b done, entering test phase.
New feature : HTTP Local Server

new parameter: --mport P (P in [1:65535])
default: disabled

simple JSON output, somehow human readable

And it was possible to make json compatible with xmr-stak or xmrig cpu?

Code:

	
	
{"version":"xmr-stak/2.4.3/26a5d65f/master/win/nvidia-amd-cpu/aeon-cryptonight-monero/20","hashrate":{"threads":[[21.0,22.4,null],[22.7,22.8,null]],"total":[43.7,45.1,null],"highest":46.9},"results":{"diff_current":606,"shares_good":2,"shares_total":2,"avg_time":31.5,"hashes_total":2126,"best":[6258,1362,0,0,0,0,0,0,0,0],"error_log":[]},"connection":{"pool": "xmr.pool.minergate.com:45700","uptime":63,"ping":64,"error_log":[]}}

Code:

{
    "id": "6104bea31afab1dc",
    "worker_id": "Home",
    "version": "2.5.3",
    "kind": "cpu",
    "ua": "XMRig/2.5.3 (Windows NT 6.1; Win64; x64) libuv/1.19.0 gcc/7.3.0",
    "cpu": {
        "brand": "Intel(R) Core(TM)2 Duo CPU     E8500  @ 3.16GHz",
        "aes": false,
        "x64": true,
        "sockets": 1
    },
    "algo": "cryptonight",
    "hugepages": true,
    "donate_level": 5,
    "hashrate": {
        "total": [
            37.34,
            0.0,
            0.0
        ],
        "highest": 0.0,
        "threads": [
            [
                16.95,
                0.0,
                0.0
            ],
            [
                20.38,
                0.0,
                0.0
            ]
        ]
    },
    "results": {
        "diff_current": 1063,
        "shares_good": 0,
        "shares_total": 0,
        "avg_time": 0,
        "hashes_total": 0,
        "best": [
            0,
            0,
            0,
            0,
            0,
            0,
            0,
            0,
            0,
            0
        ],
        "error_log": []
    },
    "connection": {
        "pool": "xmr.pool.minergate.com:45700",
        "uptime": 3,
        "ping": 0,
        "failures": 0,
        "error_log": []
    }
}

for example , you do not have ping, miner version, donate level, shares_good, shares_total, avg_time, hashes_total.
Can you add that? and what is effective ?

[Iamtutut]

Bug found! I used a few AVX2 instructions in my aes_avx assembly. And there are some CPUs with AES and AVX but not AVX2

Will be fixed soon, this bug occurs in a pretty rare case, the AVX2 instruction is enabled by autoconfig only for CN-Heavy.

edit: next features
* http server to ease integration into 3rd party tools
* option to reconnect forever, for people with bad Internet access.

edit: 0.27a online - minor revision
fix AVX2 and add --forever parameter
also merge the Monero forks, and stepback XTL to CN-v7, will be XTL-fork later

Will the miner have to be restarted for XTL fork ?

I tried Loki, due to my current weak CPU, i've been kicked out of the community pool after 30mn or so. I'll get my Ryzen 2400G monday, at long last....

[NZ-Moonman]

Any update on a Linux version?

[JCE-Miner]

hi all !

json : lots of values from xmrstak just don't exist in jce, i don't measure ping for example, that's a miner, not a Quake server. i could make something closer but not the same.

I claim continuously that jce is not a fork of xmrstak, on purpose, so i'd prefer avoid disguising jce into stak.
the clean way would be to have mining tools adapted to jce json, like Forager did.

i however note some good ideas from stak json, like telling the fee level, aes, version or wallet.
i'll add that, but not things like best share values, that's cosmetical and useless i don't want jce spend compute power managing that.

no fork autoswitch, i know xmrig does it, that's very smart, but it's a lot of code for a feature that's useful once per year. and technically in jce that's the --variation switch that's the Master fork switch, nothing dynamic. the fork is chosen before connection to the pool, i guess xmrig does the opposite.

effective is the net Hashrate, the same that's reported by your pool. from the physical Hashrate (total) it deduces/add fees, bad/good luck and outdated shares. mathematically it converges to the physical Hashrate on the long term, since mining is a random game.

if you mine 90000 worth of shares in 600s, so effective is 90000/600 = 150 H/s

kicked : try new parameter --forever to retry to connect forever (5s between each attempt)

next things planned:
* json closer (but not same) to stak
* Alloy fork (will be --variation 8 )
* linux version, to answer Moonman

[Danil1982]

Hi!
At some PC I see like thise in log:

01:02:13 | Accepted by the pool.
01:02:33 | Pool changes Difficulty to 5000.
01:03:07 | Thread 3 finds a Share, value 5000
01:03:11 | Thread 4 finds a Share, value 5000
01:03:11 | Thread 4 finds a Share, value 5000
01:03:19 | Connection failed: Pool response timeout.
01:03:19 | Connection interrupted, waiting 5s then retry.
01:03:21 | Hashrate Thread 0: 2.98 h/s
01:03:21 | Hashrate Thread 1: 2.98 h/s
01:03:21 | Hashrate Thread 2: 51.92 h/s
01:03:21 | Hashrate Thread 3: 52.09 h/s
01:03:21 | Hashrate Thread 4: 52.12 h/s
01:03:21 | Hashrate Thread 5: 52.11 h/s
01:03:21 | Hashrate Thread 6: 51.79 h/s
01:03:21 | Hashrate Thread 7: 2.99 h/s
01:03:21 | Hashrate Thread 8: 2.99 h/s
01:03:21 | Hashrate Thread 9: 2.99 h/s
01:03:21 | Hashrate Thread 10: 2.96 h/s
01:03:21 | Hashrate Thread 11: 2.92 h/s
01:03:21 | Total: 280.78 h/s
01:03:23 | Connecting to mining pool loki.miner.rocks:5555 ...
01:03:31 | Connection failed: Socked connect error: DNS resolve failed.
01:03:31 | Connection interrupted, waiting 5s then retry.
01:03:36 | Connecting to mining pool loki.miner.rocks:5555 ...
01:03:42 | Connection failed: Socked connect error: DNS resolve failed.
01:03:42 | Connection interrupted, waiting 5s then retry.
01:03:47 | Connecting to mining pool loki.miner.rocks:5555 ...
01:03:57 | Connection failed: Socked connect error: DNS resolve failed.
01:03:57 | Connection interrupted, waiting 5s then retry.
01:04:02 | Connecting to mining pool loki.miner.rocks:5555 ...
01:04:11 | Connection failed: Socked connect error: DNS resolve failed.
01:04:11 | Maximum pool connection attempts reached, give up and quit.
01:04:11 | Large Page Scratchpad 4MB Buffer 000001cfc7e00000 released.
01:04:12 | Large Page Scratchpad 4MB Buffer 000001cfc8600000 released.
01:04:12 | Large Page Scratchpad 4MB Buffer 000001cfc7600000 released.
01:04:12 | Large Page Scratchpad 4MB Buffer 000001cfc7a00000 released.
01:04:12 | Large Page Scratchpad 4MB Buffer 000001cfc8200000 released.
01:04:12 | Large Page Scratchpad 4MB Buffer 000001cfc9200000 released.
01:04:12 | Large Page Scratchpad 4MB Buffer 000001cfc7200000 released.
01:04:12 | Large Page Scratchpad 4MB Buffer 000001cfc8a00000 released.
01:04:12 | Large Page Scratchpad 4MB Buffer 000001cfc8e00000 released.
01:04:12 | Large Page Scratchpad 4MB Buffer 000001cfc9a00000 released.
01:04:12 | Large Page Scratchpad 4MB Buffer 000001cfc6e00000 released.
01:04:12 | Large Page Scratchpad 4MB Buffer 000001cfc9600000 released.
01:04:12 | Pool connection socket closed.
01:04:12 | Mining thread 0 stopped.
01:04:12 | Mining thread 1 stopped.
01:04:12 | Mining thread 2 stopped.
01:04:12 | Mining thread 3 stopped.
01:04:12 | Mining thread 4 stopped.
01:04:12 | Mining thread 5 stopped.
01:04:12 | Mining thread 6 stopped.
01:04:12 | Mining thread 7 stopped.
01:04:12 | Mining thread 8 stopped.
01:04:12 | Mining thread 9 stopped.
01:04:12 | Mining thread 10 stopped.
01:04:12 | Mining thread 11 stopped.
01:04:12 | Shared Large Page 000001cfc6c00000 released.

after thise miner is closed

In one network 4 PC continued to work and 2 is closed JCE, can you recommend what to do and how not to close the miner in such situations

THNX!

[KriptoGuruTR]

hi all !

json : lots of values from xmrstak just don't exist in jce, i don't measure ping for example, that's a miner, not a Quake server. i could make something closer but not the same.

I claim continuously that jce is not a fork of xmrstak, on purpose, so i'd prefer avoid disguising jce into stak.
the clean way would be to have mining tools adapted to jce json, like Forager did.

i however note some good ideas from stak json, like telling the fee level, aes, version or wallet.
i'll add that, but not things like best share values, that's cosmetical and useless i don't want jce spend compute power managing that.

no fork autoswitch, i know xmrig does it, that's very smart, but it's a lot of code for a feature that's useful once per year. and technically in jce that's the --variation switch that's the Master fork switch, nothing dynamic. the fork is chosen before connection to the pool, i guess xmrig does the opposite.

effective is the net Hashrate, the same that's reported by your pool. from the physical Hashrate (total) it deduces/add fees, bad/good luck and outdated shares. mathematically it converges to the physical Hashrate on the long term, since mining is a random game.

if you mine 90000 worth of shares in 600s, so effective is 90000/600 = 150 H/s

kicked : try new parameter --forever to retry to connect forever (5s between each attempt)

next things planned:
* json closer (but not same) to stak
* Alloy fork (will be --variation 8 )
* linux version, to answer Moonman

An xmrstak compatible JSON output can be useful for using existing remote monitoring applications. You may use a static value for unused variables.

[sergneo]

next things planned:
* json closer (but not same) to stak

It is good even if it looks like json xmr-stak, not necessarily exactly

[UnclWish]

Pool intense.hashvault.pro tried ports 80 and 443 (ssl). Coins Intense (ITNS). Allways poool rejects shares - low difficaulty share.
Maybe Intense have forked?