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

[Larvitar]

sounds logical, jce api is either its own, or xmr-stak compatible, but not cpumineropt-compatible.
Maybe ask Awsomeminer to support jce, it should be simple since it has command line similar to cpuminerot (and to claymore) and api just like stak.

i got bad report about 0.29c algo selection, haven is broken, bixbite seems too, need to hot release a fix.

Done

I suggested him to add JCE-Miner to Awesome too. Let's see what happens. I really love your miner.

[robminer80]

thanks for the test, it seems my autoconfig is bad on the A10, it allocates too many threads. I'll fix it, thanks.

The multihash (double hash is the 2-case, you can set from 1- to 6- ) is also called low-power in stak IIRC. It's about using, on one CPU core, twice the register and twice the cache to get sometimes twice the speed. The trick is that it let the other cores free, so it consume less power and allows the Turbo to enable, for CPU with turbo.

Technically, it's good, sure when you want to save power, but also when you run out of cores and not of cache. If you have a CPU with 2 cores but 8M cache, normal config would give only 2x2M = 4M cache used.

you may enable double-hash to use 2x2x2M cache = 8M of cache, and get some extra perf.
It works more or less depending on the CPU. It's very efficient on Ryzen, and not at all on Core2.

I looked closer at the A10, and yeah that's a little APU with little cache.
I give you an experimental config that could let you get some extra perf, but not sure, i cannot test, i've no A10.

"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 },
]

now finishing 0.29c, the last CPU-only version, with some updates.

12:52:22 | Hashrate Thread 0: 59.71 h/s
12:52:22 | Hashrate Thread 1: 2.57 h/s
12:52:22 | Hashrate Thread 2: 54.01 h/s
12:52:22 | Hashrate Thread 3: 2.44 h/s
12:52:22 | Total: 118.71 h/s
12:52:23 | Pool changes Difficulty to 2634.


limited to two threads with -t 2:

12:47:53 | Pool changes Difficulty to 2376.
12:47:59 | Hashrate Thread 0: 62.49 h/s
12:47:59 | Hashrate Thread 1: 60.26 h/s
12:47:59 | Total: 122.74 h/s

Try:

"cpu_threads_conf" :  
[  
     { "cpu_architecture" : "trinity", "affine_to_cpu" : 1, "use_cache" : true },    
     { "cpu_architecture" : "trinity", "affine_to_cpu" : 3, "use_cache" : true },
]

[KriptoGuruTR]

@JCE-Miner

Another great idea for you: Can you please make an option that can read CPU temperature via a file and report it? Something like that:

--tempFile=/home/rig3/cpuTemp.txt

contents of cpuTemp.txt (comma separated temperature of cores)

52,56,50,54

Thanks

[whotheff]

@JCE-Miner

Another great idea for you: Can you please make an option that can read CPU temperature via a file and report it? Something like that:

--tempFile=/home/rig3/cpuTemp.txt

contents of cpuTemp.txt (comma separated temperature of cores)

52,56,50,54

Thanks

Or even better - display it with hashrate.

[JCE-Miner]

Hi all,

I'm now building 0.29d which will invalidate the 0.29c because the Haven was badly applied in some case, and Bixbite wallets conflict with IPBC. So i drop native support of bixbite (but it's still mineable with forced --variation 5 for Heavy) and rename IPBC into BitTube, its new name.

CPU temperature : it's pretty hard and not portable, dedicated software like HWInfo have lots of PLL and sensor database to read temp correctly, i don't have time enough to handle all of this, compared to what i still have to do about GPU. I'll add it for GPU, but not in early releases to save dev time.

Max hashrate is not useful for CPU since hashrate is ultra-stable on them (unless the PC is used for something else) but that's a great idea for GPU, i like it. In case of CPU+GPU mine, the total and max will be the ones of all cpu + all gpu.
said differently, once i release the gpu-capable versions, max hashrate will be displayed, even if you use zero GPU

[KriptoGuruTR]

Hi all,

I'm now building 0.29d which will invalidate the 0.29c because the Haven was badly applied in some case, and Bixbite wallets conflict with IPBC. So i drop native support of bixbite (but it's still mineable with forced --variation 5 for Heavy) and rename IPBC into BitTube, its new name.

CPU temperature : it's pretty hard and not portable, dedicated software like HWInfo have lots of PLL and sensor database to read temp correctly, i don't have time enough to handle all of this, compared to what i still have to do about GPU. I'll add it for GPU, but not in early releases to save dev time.

Max hashrate is not useful for CPU since hashrate is ultra-stable on them (unless the PC is used for something else) but that's a great idea for GPU, i like it. In case of CPU+GPU mine, the total and max will be the ones of all cpu + all gpu.

If you read CPU temperature via a text file, you will not write anything low level. Just a simple text file read. Lm-sensors take care of it. A simple cron jon, sensors output to text file and voila.

[4ward]

Hi all,

I'm now building 0.29d which will invalidate the 0.29c because the Haven was badly applied in some case, and Bixbite wallets conflict with IPBC. So i drop native support of bixbite (but it's still mineable with forced --variation 5 for Heavy) and rename IPBC into BitTube, its new name.

CPU temperature : it's pretty hard and not portable, dedicated software like HWInfo have lots of PLL and sensor database to read temp correctly, i don't have time enough to handle all of this, compared to what i still have to do about GPU. I'll add it for GPU, but not in early releases to save dev time.

Max hashrate is not useful for CPU since hashrate is ultra-stable on them (unless the PC is used for something else) but that's a great idea for GPU, i like it. In case of CPU+GPU mine, the total and max will be the ones of all cpu + all gpu.

If you read CPU temperature via a text file, you will not write anything low level. Just a simple text file read. Lm-sensors take care of it. A simple cron jon, sensors output to text file and voila.

its linux only and thats exactly the definition of "not portable"

[KriptoGuruTR]

It is portable since it reads from a text file. For linux lm-sensors can create such a file. I am sure there are plenty windows applications aswell.

[JCE-Miner]

out of context, reading a file is portable. But i cannot legitimately (and don't want to) grab some external app from somewhere and make it write a text file that JCE would read, that's a pretty dirty way of working.

However that's rather a GUI/Monitor job, a GUI tool could use JCE to mine and in the same time monitor the cpu temperatures. Get the hashrate, get the temperature, and display both.

[Iamtutut]

out of context, reading a file is portable. But i cannot legitimately (and don't want to) grab some external app from somewhere and make it write a text file that JCE would read, that's a pretty dirty way of working.

However that's rather a GUI/Monitor job, a GUI tool could use JCE to mine and in the same time monitor the cpu temperatures. Get the hashrate, get the temperature, and display both.

Hi, just  mined a bit of Masari with the Ryzen 2400G, hashrate in "auto'" config was around 280H/s.

[JCE-Miner]

Masari works, that's Haven which may be broken. Now testing 0.29d, I added the Max hashrate, even if it's still a pure CPU version

Code:

21:00:10 | Hashrate CPU Thread 0: 11.42 h/s
21:00:10 | Hashrate CPU Thread 1: 11.54 h/s
21:00:10 | Hashrate CPU Thread 2: 11.67 h/s
21:00:10 | Hashrate CPU Thread 3: 11.71 h/s
21:00:10 | Total: 46.33 h/s - Max: 47.44 h/s

That's haven on my core2-quad

[whotheff]

thanks for the test, it seems my autoconfig is bad on the A10, it allocates too many threads. I'll fix it, thanks.

The multihash (double hash is the 2-case, you can set from 1- to 6- ) is also called low-power in stak IIRC. It's about using, on one CPU core, twice the register and twice the cache to get sometimes twice the speed. The trick is that it let the other cores free, so it consume less power and allows the Turbo to enable, for CPU with turbo.

Technically, it's good, sure when you want to save power, but also when you run out of cores and not of cache. If you have a CPU with 2 cores but 8M cache, normal config would give only 2x2M = 4M cache used.

you may enable double-hash to use 2x2x2M cache = 8M of cache, and get some extra perf.
It works more or less depending on the CPU. It's very efficient on Ryzen, and not at all on Core2.

I looked closer at the A10, and yeah that's a little APU with little cache.
I give you an experimental config that could let you get some extra perf, but not sure, i cannot test, i've no A10.

"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 },
]

now finishing 0.29c, the last CPU-only version, with some updates.

12:52:22 | Hashrate Thread 0: 59.71 h/s
12:52:22 | Hashrate Thread 1: 2.57 h/s
12:52:22 | Hashrate Thread 2: 54.01 h/s
12:52:22 | Hashrate Thread 3: 2.44 h/s
12:52:22 | Total: 118.71 h/s
12:52:23 | Pool changes Difficulty to 2634.


limited to two threads with -t 2:

12:47:53 | Pool changes Difficulty to 2376.
12:47:59 | Hashrate Thread 0: 62.49 h/s
12:47:59 | Hashrate Thread 1: 60.26 h/s
12:47:59 | Total: 122.74 h/s

Try:

"cpu_threads_conf" :  
[  
     { "cpu_architecture" : "trinity", "affine_to_cpu" : 1, "use_cache" : true },    
     { "cpu_architecture" : "trinity", "affine_to_cpu" : 3, "use_cache" : true },
]

Another +10hashes gained this way! It might be a temporary thing, but if
I dont' touch anything on the PC the hashrate goes to 137 H/s.

I'm not sure why it did it, since in both cases it uses generic aes avx , large cache
and two cores.

[JCE-Miner]

impressive tip from robminer80 who gives better advices than the dev !
Probably thanks to the repartition on cores 1 and 3

I postpone 0.29d to make more tests and add coin BLOC (another CN-Heavy coin)

[robminer80]

impressive tip from robminer80 who gives better advices than the dev !
Probably thanks to the repartition on cores 1 and 3

I postpone 0.29d to make more tests and add coin BLOC (another CN-Heavy coin)

Apu's L2 cache is 2MB + 2MB in two modules, Cpu 0 and 1 have access to the first 2MB, Cpu 2 and 3 to the other 2MB

[JCE-Miner]

0.29d online - Windows and Linux

Code:

Max hashrate when you press r
BLOC added
Bixbite removed
Haven algo selection fixed

This is probably the last CPU-only version

[4ward]

0.29d - api is returning invalid json (missing "," before the max speed)
xmr-stak api mode is fine

[KriptoGuruTR]

Intel G4560 - Stock
DDR 2133
Linux JCE 0.29c w/hugepages

61 Kh/s

[JCE-Miner]

there's a very light optim between 0.29b and 0.29c but gain is barely noticeable. not between 0.29c and d. d is a bugfix version.
On the g4560 the best config should be -t 2 if you mine cn-v7 or -t 4 if cryptolight/turtle/ipbc/aeon


json : right, a typo in my code… how lame, i'm good to rebuild it again, thanks for report!

[siroliver]

29c not releasing hugepages

[JCE-Miner]

I admit i focused my test on Haven for the 0.29d to save time to release the gpu version asap. ok i note the problem with huge page release.