[XMR] JCE Miner Cryptonight/forks, now with GPU! - page 46.

JCE-Miner

member

Activity: 350

Merit: 22

On my HD6950 flashed into a 6970 i could go above 430, using custom GDDR straps for its Elpida memory.
Is the 6990 a double 6950 or a double 6970? i don't remember Sad

Once I can dev back on GPU, my first step will be to have a working version, at least on par with xmrig. Then i'll optimize more.

Meanwhile,
Linux CPU version 0.33c
is out.

I also fixed the AVX bad detect UnclWish had found, now Vishera and later should default to aes-avx.

With this version, if you mine on MoneroOcean with --auto, you get a fully functional Pool-managed autoswitch miner.
I added a new example of config in the package for the three new arrays.
I still need to write a formal doc.

JCE-Miner

member

Activity: 350

Merit: 22

Pool managed autoswitch tests almost done.

Planned new features in the 0.33c CPU

Quote

Pool-managed Autoswitch, à la MoneroOcean, --variation 16
Little perf optim for Monero v8, for 32 and 64 bits
Two new assemblies: generic_fpu and generic_sse4_fpu to compute the Monero v8 square-root with the FPU instead of the SSE2 unit. For older CPUs. Ignored for non-v8 algos.

edit:

Windows CPU version 0.33c
is online, Linux version comes soon.

MoneroOcean defaults to the new Pool-managed autoswitch mode. That's --variation 16
I still need to update the doc.

JCE-Miner

member

Activity: 350

Merit: 22

There are two different things:

The algo switch after a fork on a precise coin, like Monero on 18-October, this is not supported by JCE and probably won't be, since it's useful twice a year at best, on some coins.

And the Autoswitching pool, which make your miner change the algo every 5 min to target the most profitable coin. Like MoneroOcean. I'm adding this feature.

Currently I default Minergate and Nicehash and other to V7, but as stated in the doc, and in the log when your first share is rejected, you then should change the fork by hand if you get only bad shares, this is a very common case.

Code:

17:10:55 | Rejected by the pool in 304 ms.
17:10:55 | Message from the pool: Low difficulty share
17:10:55 | Your first share was rejected, you probably need to change the fork
17:10:55 | with parameter --variation N, try different values for N in [1-16]
17:10:55 | until you find the one that works.

From the FAQ, first page and Github page

Quote

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.

stsocrat

newbie

Activity: 24

Merit: 0

No, i think Minergate is not autoswitching pool. Some my workers are on it.
As you know, statisticaly the most popupal gpus on Cryptonight are Vega56 and 550 (baffin and lexa). So don't forget to test you gpu version on 550

sergneo

newbie

Activity: 33

Merit: 0

Quote from: JCE-Miner on October 20, 2018, 12:41:27 PM

Stupid question: is Minergate an algo-switching pool, in the same sens as MoneroOcean ?
If yes, i didn't find how.
The doc:

https://minergate.com/altminers/claymore-cpu

provides a different address for each coin, like a normal pool.

After the fork V8 XMR put --variation 0 (default=0) 0 = Automatic, he began to use the old algo v7 and has done me Invalid shares:894, yet I force not set --variation 15. And it's on Minergate and JCE cpu 0.33a

xmr stak 2.5.1 successfully autoparallel, xmrig fixed urgent bug in version 2.8.3 #813 Fixed critical bug with Minergate pool and variant 2. Your miner doesn't switch algo. Sad

JCE-Miner

member

Activity: 350

Merit: 22

Five GPU: check you have enough of virtual memory, that's about using a very large swap file under windows, like 64GB
Also retry with lower values for multi_hash, and if it works, re-up them by step of 16

Remote rig: Thanks but I already excluded this option, dev'ing on a remote rig, in addition to be dangerous because my intermediate code may crash your rig, implies that i upload debug versions of JCE through internet, which i exclude for obvious security reasons. I'll make the GPU v8 in early november, once i'm back to my rigs and normal dev environment. Meanwhile, i can work on other topics like the netcode.
I've also an HD6950, HD7950, HD7850 and HD7790 on my rig (even if the 6950 doesn't mine except for tests) so I should be able to make good quality mining even for those cards.

Does anybody knows if Minergate is an autoswitch pool? i read all their website and didn't find. Cry

zeconadailytyclaymore

newbie

Activity: 8

Merit: 0

Hey JCE, check out your github on your GPU miner, I wrote to you there in an issue, I can offer you a rig and system to work on, developing your miner so you can get that deployed for the good of us all asap

The system has HD 6990s, HD 7970, HD 7850. It's currently on Win 10 64, running 14.4 drivers. I see that you're good with Pitcairn cards and that's why I'd like you to make some progress with your miner because at the moment, I've got all those cards just sitting there and not mining as xmr stak gives invalid shares, and no one over there is willing to look into the issue.

wyzdic

newbie

Activity: 46

Merit: 0

Quote from: JCE-Miner on October 20, 2018, 11:20:20 AM

The old Core2 suffer also from the new algo...

I'm done with the Algo-autoselect switch version for CPU. I write here a preview of the features. The final doc will be on the Github page.
I need to test more, but the code itself is done. I'll test on MoneroOcean, betting other pools are compatible

Config
Autoswitch is --variation 16
If you mine with --auto, that's it.
Otherwise, the manual config is a lot more complicated: there are three new arrays:

Code:

"cryptolight_cpu_threads_conf"
"cryptonight_cpu_threads_conf"
"cn_heavy_cpu_threads_conf"

Respectively for the
Cryptolight algo family (Turtle, Red...)
Cryptonight algo family (Monero, Stellite, Masari...)
Heavy family (Loki, Haven, Tube...)

Each array is filled the same way as the legacy "cpu_threads_conf", but is algo family specialized. They don't overlap, "cpu_threads_conf" is used for and only for the normal single-algo mining, and the three other for and only for the Autoswitch.
Not the three are mandatory, only one is, an indirect way to disable algo families you don't want to mine. For example, not to mine heavy-class algos, just don't set any "cn_heavy_cpu_threads_conf" in your config. MoneroOcean, however, requires at least the Cryptonight family to be enabled.
I advise, for readability, to use separate config files for single-algo and Autoswitch, but the same file can hold the four arrays, no problem.

Preview

Code:

"cryptonight_cpu_threads_conf" : 
[ 
      { "cpu_architecture" : "core2_sse4", "affine_to_cpu" : 0, "use_cache" : true, "multi_hash":1 },
      { "cpu_architecture" : "core2_sse4", "affine_to_cpu" : 1, "use_cache" : true, "multi_hash":1 },
],

"cryptolight_cpu_threads_conf" : 
[ 
      { "cpu_architecture" : "core2_sse4", "affine_to_cpu" : 1, "use_cache" : true, "multi_hash":1 },
],

Code:

+-- Thread 0 config ------------------------+
| Dedicated to:          Cryptolight/forks  |
| Run on CPU:            1                  |
| Use cache:             yes                |
| Multi-hash:            no                 |
| Assembly module:       core2_sse4         |
+-------------------------------------------+

+-- Thread 1 config ------------------------+
| Dedicated to:          Cryptonight/forks  |
| Run on CPU:            0                  |
| Use cache:             yes                |
| Multi-hash:            no                 |
| Assembly module:       core2_sse4         |
+-------------------------------------------+

+-- Thread 2 config ------------------------+
| Dedicated to:          Cryptonight/forks  |
| Run on CPU:            1                  |
| Use cache:             yes                |
| Multi-hash:            no                 |
| Assembly module:       core2_sse4         |
+-------------------------------------------+

Dedicated: for the threads that starts or stops depending on the algo family. Here, either thread 0 or 1+2 will mine, but not all.

Code:

22:08:37 | Connected to pool. Now logging in...
22:08:37 | Algo-autoswitch Pool gets proposed:
22:08:37 | * Original Cryptonight
22:08:37 | * Original Cryptolight
22:08:37 | * Cryptonight V7 fork of April-2018
22:08:37 | * Cryptolight V7 fork of April-2018
22:08:37 | * Cryptonight-XTL fork of May-2018
22:08:37 | * Cryptonight-Alloy fork of May-2018
22:08:37 | * Cryptonight-MKT/B2N fork of May-2018
22:08:37 | * Cryptonight-Arto fork of May-2018
22:08:37 | * Cryptonight-Fast MSR fork of June-2018
22:08:37 | * Cryptolight-Red fork of July-2018
22:08:37 | * Cryptonight V8 fork of Oct-2018
22:08:38 | Successfuly logged as .......
22:08:38 | Auto-select algo switched to: Cryptonight V8 fork of Oct-2018
22:08:38 | Pool changes Difficulty to 100.
22:08:38 | CPU Thread 2 for Cryptonight/forks wakes-up.
22:08:38 | CPU Thread 1 for Cryptonight/forks wakes-up.
22:08:43 | Hashrate CPU Thread 1: 0.00 h/s
22:08:43 | Hashrate CPU Thread 2: 0.00 h/s
22:08:43 | Total: 0.00 h/s - Max: 0.00 h/s

The startup is a lot more verbose.
First, JCE lists the algo proposed to the Pool. Of course some may be ignored by this latter, i doubt MoneroOcean will make me mine CN-Red, but that's harmless. Since I configured Cryptonight and Cryptolight, but not Heavy, the Heavy-class are not listed.

The after the login, the Algo chosen by the pool is displayed. It will be displayed each time it changes.
When the algo family changes (to switch from Monero to Turtle for example) the respective threads stop and start.
Only active threads count for the hashrate, the other are ignored.

Here I simulated with my netcode a switch to CN-Light v0 (wich would hardly happen in real life, that's for example):

Code:

22:09:00 | CPU Thread 2 finds a Share, value 100
22:09:00 | Accepted by the pool in 121 ms.
22:09:03 | Pool changes Difficulty to 469.
22:09:24 | CPU Thread 2 finds a Share, value 469
22:09:24 | Accepted by the pool in 126 ms.
22:10:03 | Auto-select algo switched to: Original Cryptolight
22:10:03 | Pool changes Difficulty to 304.
22:10:03 | CPU Thread 1 for Cryptonight/forks suspends.
22:10:03 | CPU Thread 2 for Cryptonight/forks suspends.
22:10:03 | CPU Thread 0 for Cryptolight/forks wakes-up.
22:10:15 | CPU Thread 0 Lane 0 finds a Share, value 304
....

Fees
No change, fees are mined in the same algo than the user. In case of autoswitch, that will be the current algo when the fee sessions starts.

Compatibility
100% backward compatible with previous JCE. About the pool, i'm testing on MoneroOcean.

Release planned for Windows CPU in a few days, when my tests are done. Then Linux CPU. No GPU version until november, for the exact same reasons I cannot provide a working GPU v8

Thanks for your hard work. I just want you to know, We need your GPU version.
SRB give me 15.2K/8 Vegas, But pool report only 12-13.5K, I dont know why.
Use xmr-stak now, But only have 14.6K(better than SRB)

almost30

newbie

Activity: 164

Merit: 0

hi dev , thanks for your hard work .
last update i mange to run 4 vega cards with no problem . (-G 0,1,2,3)
but the miner stuck if i add 5th card (-G 0,1,2,3,4) .

any reason why is this happens !

JCE-Miner

member

Activity: 350

Merit: 22

Stupid question: is Minergate an algo-switching pool, in the same sens as MoneroOcean ?
If yes, i didn't find how.
The doc:

https://minergate.com/altminers/claymore-cpu

provides a different address for each coin, like a normal pool.

sergneo

newbie

Activity: 33

Merit: 0

Test autoselect also on Minergate pool, please

JCE-Miner

member

Activity: 350

Merit: 22

The old Core2 suffer also from the new algo...

I'm done with the Algo-autoselect switch version for CPU. I write here a preview of the features. The final doc will be on the Github page.
I need to test more, but the code itself is done. I'll test on MoneroOcean, betting other pools are compatible

Config
Autoswitch is --variation 16
If you mine with --auto, that's it.
Otherwise, the manual config is a lot more complicated: there are three new arrays:

Code:

"cryptolight_cpu_threads_conf"
"cryptonight_cpu_threads_conf"
"cn_heavy_cpu_threads_conf"

Respectively for the
Cryptolight algo family (Turtle, Red...)
Cryptonight algo family (Monero, Stellite, Masari...)
Heavy family (Loki, Haven, Tube...)

Each array is filled the same way as the legacy "cpu_threads_conf", but is algo family specialized. They don't overlap, "cpu_threads_conf" is used for and only for the normal single-algo mining, and the three other for and only for the Autoswitch.
Not the three are mandatory, only one is, an indirect way to disable algo families you don't want to mine. For example, not to mine heavy-class algos, just don't set any "cn_heavy_cpu_threads_conf" in your config. MoneroOcean, however, requires at least the Cryptonight family to be enabled.
I advise, for readability, to use separate config files for single-algo and Autoswitch, but the same file can hold the four arrays, no problem.

Preview

Code:

"cryptonight_cpu_threads_conf" : 
[ 
      { "cpu_architecture" : "core2_sse4", "affine_to_cpu" : 0, "use_cache" : true, "multi_hash":1 },
      { "cpu_architecture" : "core2_sse4", "affine_to_cpu" : 1, "use_cache" : true, "multi_hash":1 },
],

"cryptolight_cpu_threads_conf" : 
[ 
      { "cpu_architecture" : "core2_sse4", "affine_to_cpu" : 1, "use_cache" : true, "multi_hash":1 },
],

Code:

+-- Thread 0 config ------------------------+
| Dedicated to:          Cryptolight/forks  |
| Run on CPU:            1                  |
| Use cache:             yes                |
| Multi-hash:            no                 |
| Assembly module:       core2_sse4         |
+-------------------------------------------+

+-- Thread 1 config ------------------------+
| Dedicated to:          Cryptonight/forks  |
| Run on CPU:            0                  |
| Use cache:             yes                |
| Multi-hash:            no                 |
| Assembly module:       core2_sse4         |
+-------------------------------------------+

+-- Thread 2 config ------------------------+
| Dedicated to:          Cryptonight/forks  |
| Run on CPU:            1                  |
| Use cache:             yes                |
| Multi-hash:            no                 |
| Assembly module:       core2_sse4         |
+-------------------------------------------+

Dedicated: for the threads that starts or stops depending on the algo family. Here, either thread 0 or 1+2 will mine, but not all.

Code:

22:08:37 | Connected to pool. Now logging in...
22:08:37 | Algo-autoswitch Pool gets proposed:
22:08:37 | * Original Cryptonight
22:08:37 | * Original Cryptolight
22:08:37 | * Cryptonight V7 fork of April-2018
22:08:37 | * Cryptolight V7 fork of April-2018
22:08:37 | * Cryptonight-XTL fork of May-2018
22:08:37 | * Cryptonight-Alloy fork of May-2018
22:08:37 | * Cryptonight-MKT/B2N fork of May-2018
22:08:37 | * Cryptonight-Arto fork of May-2018
22:08:37 | * Cryptonight-Fast MSR fork of June-2018
22:08:37 | * Cryptolight-Red fork of July-2018
22:08:37 | * Cryptonight V8 fork of Oct-2018
22:08:38 | Successfuly logged as .......
22:08:38 | Auto-select algo switched to: Cryptonight V8 fork of Oct-2018
22:08:38 | Pool changes Difficulty to 100.
22:08:38 | CPU Thread 2 for Cryptonight/forks wakes-up.
22:08:38 | CPU Thread 1 for Cryptonight/forks wakes-up.
22:08:43 | Hashrate CPU Thread 1: 0.00 h/s
22:08:43 | Hashrate CPU Thread 2: 0.00 h/s
22:08:43 | Total: 0.00 h/s - Max: 0.00 h/s

The startup is a lot more verbose.
First, JCE lists the algo proposed to the Pool. Of course some may be ignored by this latter, i doubt MoneroOcean will make me mine CN-Red, but that's harmless. Since I configured Cryptonight and Cryptolight, but not Heavy, the Heavy-class are not listed.

The after the login, the Algo chosen by the pool is displayed. It will be displayed each time it changes.
When the algo family changes (to switch from Monero to Turtle for example) the respective threads stop and start.
Only active threads count for the hashrate, the other are ignored.

Here I simulated with my netcode a switch to CN-Light v0 (wich would hardly happen in real life, that's for example):

Code:

22:09:00 | CPU Thread 2 finds a Share, value 100
22:09:00 | Accepted by the pool in 121 ms.
22:09:03 | Pool changes Difficulty to 469.
22:09:24 | CPU Thread 2 finds a Share, value 469
22:09:24 | Accepted by the pool in 126 ms.
22:10:03 | Auto-select algo switched to: Original Cryptolight
22:10:03 | Pool changes Difficulty to 304.
22:10:03 | CPU Thread 1 for Cryptonight/forks suspends.
22:10:03 | CPU Thread 2 for Cryptonight/forks suspends.
22:10:03 | CPU Thread 0 for Cryptolight/forks wakes-up.
22:10:15 | CPU Thread 0 Lane 0 finds a Share, value 304
....

Fees
No change, fees are mined in the same algo than the user. In case of autoswitch, that will be the current algo when the fee sessions starts.

Compatibility
100% backward compatible with previous JCE. About the pool, i'm testing on MoneroOcean.

Release planned for Windows CPU in a few days, when my tests are done. Then Linux CPU. No GPU version until november, for the exact same reasons I cannot provide a working GPU v8

Lonnegan64

jr. member

Activity: 37

Merit: 5

It's interesting, that cn/2 alias Monero v8 has different impact on different CPUs. With Zen it's relatively moderate, AMD Ryzen 7 2700 dropped from 620 H/s to 595 H/s (-4%).

On Bulldozer-based CPUs instead, it's devastating! A8-5600K "Piledriver" dropped from 155 H/s to 119 H/s (-24%), Opteron 4284 "Zambezi" from 280 H/s to 180 H/s (-35%) and A8-7600 "Kaveri" clashed from 177 H/s to 94 H/s Huh

(-47%).

Apparently this are the archs, which were not cache limited, but are limited in execution units, pipelines and/or instructions on the fly, whereas a CPU like Ryzen is wide enough to do the extra instructions on the side. Cool

UnclWish

sr. member

Activity: 1484

Merit: 253

Quote from: kosmoo on October 20, 2018, 04:46:18 AM

нe paбoтaeт нa win7. He oпpeдeляeт GPU. Жaль. Удaляю Huh

100 paз былo cкaзaнo, чтo мaйнep GPU нe paбoтaeт нa Windows 7. Пoд 7-кy yжe дpoвa cкopo пepecтaнyт пиcaть нoвыe, зaчeм нa нeй cидeть...

kosmoo

newbie

Activity: 11

Merit: 0

нe paбoтaeт нa win7. He oпpeдeляeт GPU. Жaль. Удaляю Huh

Bulitt

member

Activity: 108

Merit: 11

Those dang Vishera CPU's have that unmanageable cache there are so many different configurations to try to extract the power from those CPU's and Ive always said there has to be a way to make a thread use a group of selected cores instead of just "false" and letting the OS manage the affinity.

Quote

Analyzing Processors topology...
AMD FX(tm)-8320 Eight-Core Processor
Assembly codename: generic_aes_avx
SSE2 : Yes
SSE3 : Yes
SSE4 : Yes
AES : Yes
AVX : Yes
AVX2 : No

Found CPU 0, with:
L1 Cache: 16 KB
L2 Cache: 2048 KB
L3 Cache: 8192 KB, shared with CPU 1, 2, 3, 4, 5, 6, 7
Found CPU 1, with:
L1 Cache: 16 KB
L2 Cache: 2048 KB
L3 Cache: 8192 KB, shared with CPU 0, 2, 3, 4, 5, 6, 7
Found CPU 2, with:
L1 Cache: 16 KB
L2 Cache: 2048 KB
L3 Cache: 8192 KB, shared with CPU 0, 1, 3, 4, 5, 6, 7
Found CPU 3, with:
L1 Cache: 16 KB
L2 Cache: 2048 KB
L3 Cache: 8192 KB, shared with CPU 0, 1, 2, 4, 5, 6, 7
Found CPU 4, with:
L1 Cache: 16 KB
L2 Cache: 2048 KB
L3 Cache: 8192 KB, shared with CPU 0, 1, 2, 3, 5, 6, 7
Found CPU 5, with:
L1 Cache: 16 KB
L2 Cache: 2048 KB
L3 Cache: 8192 KB, shared with CPU 0, 1, 2, 3, 4, 6, 7
Found CPU 6, with:
L1 Cache: 16 KB
L2 Cache: 2048 KB
L3 Cache: 8192 KB, shared with CPU 0, 1, 2, 3, 4, 5, 7
Found CPU 7, with:
L1 Cache: 16 KB
L2 Cache: 2048 KB
L3 Cache: 8192 KB, shared with CPU 0, 1, 2, 3, 4, 5, 6

I configure 4 standard threads to cores 7-5-3-1, then 2 "double cache" mode threads with affinity set to false. If only those 2 threads could be assigned to split their loads among cores 0-2-4-6 only I suspect theres an additional 60 or so more H/sec for a full CPU.

Code:

"cpu_threads_conf" : 
[ 
     { "cpu_architecture" : "vishera", "affine_to_cpu" : 1, "use_cache" : true },
     { "cpu_architecture" : "vishera", "affine_to_cpu" : 3, "use_cache" : true },
     { "cpu_architecture" : "vishera", "affine_to_cpu" : 5, "use_cache" : true },
     { "cpu_architecture" : "vishera", "affine_to_cpu" : 7, "use_cache" : true },
     { "cpu_architecture" : "vishera", "affine_to_cpu" : 2, "use_cache" : true,},
     { "cpu_architecture" : "vishera", "affine_to_cpu" : 4, "use_cache" : true,},
     { "cpu_architecture" : "vishera", "affine_to_cpu" : 6, "use_cache" : true,}

]

Quote

Code:

"cpu_threads_conf" : 
[ 
     { "cpu_architecture" : "vishera", "affine_to_cpu" : 1, "use_cache" : true },
     { "cpu_architecture" : "vishera", "affine_to_cpu" : 3, "use_cache" : true },
     { "cpu_architecture" : "vishera", "affine_to_cpu" : 5, "use_cache" : true },
     { "cpu_architecture" : "vishera", "affine_to_cpu" : 7, "use_cache" : true },
     { "cpu_architecture" : "vishera", "affine_to_cpu" : false, "use_cache" : true,},
     { "cpu_architecture" : "vishera", "affine_to_cpu" : false, "use_cache" : true,},

]

Quote

Code:

"cpu_threads_conf" : 
[ 
     { "cpu_architecture" : "vishera", "affine_to_cpu" : 1, "use_cache" : true },
     { "cpu_architecture" : "vishera", "affine_to_cpu" : 3, "use_cache" : true },
     { "cpu_architecture" : "vishera", "affine_to_cpu" : 5, "use_cache" : true },
     { "cpu_architecture" : "vishera", "affine_to_cpu" : 7, "use_cache" : true },
     { "cpu_architecture" : "vishera", "affine_to_cpu" : false, "use_cache" : true, "multi_hash": 2 },
     { "cpu_architecture" : "vishera", "affine_to_cpu" : false, "use_cache" : true, "multi_hash": 2 }

]

Quote

Code:

"cpu_threads_conf" : 
[ 
     { "cpu_architecture" : "vishera", "affine_to_cpu" : 7, "use_cache" : true },
     { "cpu_architecture" : "vishera", "affine_to_cpu" : 5, "use_cache" : true },
     { "cpu_architecture" : "vishera", "affine_to_cpu" : 3, "use_cache" : true },
     { "cpu_architecture" : "vishera", "affine_to_cpu" : 1, "use_cache" : true },
     { "cpu_architecture" : "vishera", "affine_to_cpu" : 0, "use_cache" : true },
     { "cpu_architecture" : "vishera", "affine_to_cpu" : 2, "use_cache" : true },

]

Quote

And this is the way you're "supposed" to do it based on the L3 cache amount

Code:

"cpu_threads_conf" : 
[ 
     { "cpu_architecture" : "vishera", "affine_to_cpu" : 7, "use_cache" : true },
     { "cpu_architecture" : "vishera", "affine_to_cpu" : 5, "use_cache" : true },
     { "cpu_architecture" : "vishera", "affine_to_cpu" : 3, "use_cache" : true },
     { "cpu_architecture" : "vishera", "affine_to_cpu" : 1, "use_cache" : true },

]

Quote

JCE-Miner

member

Activity: 350

Merit: 22

Hi all,

Still no way to fix openCL, but i've time to do some support here

Quote

HD7850 Radeon15.12Win7-64Bit

Win7 not supported, minimum is Win8.1, that's what I use for my Pitcairn rig.
But if you planned to mine Monero v8, it wouldn't have worked neither, my current v8 is broken on Pitcairn. other algo work fine, and CPU too.

Quote

a good and easier solution than eg. awesome miner for controlling the miners if they are alive?

My side, i provide a JSON server, that you can request to know if the miner is alive. Then some external tools can add a layer of abstraction over it. Try Forager, i know it supports JCE for a long time.

Quote

CPU version is working!

Nice to read Grin

Quote

Vishera

I configure it by deafult as EAS but non-AVX, are all Vishera AVX-capable? I'll check and update my autoconfig.

Stuck at dev'ing only non-algo parts, i'm working on the MoneroOcean-style autoswitch on CPU version. Almost 60% done.

edit:

Quote

are all Vishera AVX-capable?

Yes they are. I fixed, and fixed also some other CPU where i did the same mistake. But don't expect a noticeable speed increase, except in no-cache mode.

Nightworker88

newbie

Activity: 64

Merit: 0

few weeks ago i switched to this awesome cpu miner.

Does anybody have a good and easier solution than eg. awesome miner for controlling the miners if they are alive?

I used to use for more than two years now claymore, and ethman was perfect to see on my desktop in my office whats going on with my rigs.

i was searching last days here in forum, but i did not find something, but i thinkthis is on one side myenglish and on other side i am an technician engineer and all this software is with less time little bit complicated for me Huh

stsocrat

newbie

Activity: 24

Merit: 0

CPU version is working!
I have 8*8320E, 2*8320 and 6*8350. Now w/o oc.
On some Vishera auto uses only 5 cores, so i'm gonna -c config.txt with
"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 },
],

Adding
   { "cpu_architecture" : "auto", "affine_to_cpu" : 7, "use_cache" : true },
Slower

Adding
   { "cpu_architecture" : "auto", "affine_to_cpu" : 7, "use_cache" : false },
Plus 2h/s

Changing cpu6 into
   { "cpu_architecture" : "auto", "affine_to_cpu" : 6, "use_cache" : true, "multi_hash": 2 },
Nothing interesting.

What's with v9?
Ok, nothing new.

JCE-Miner

member

Activity: 350

Merit: 22

There may be room for perf increase, even on non-AES. The 0.33a is already optimized, but not at max.

Quote

vishera

I'll take a look at my table of assemblies, I may have flagged Vishera to eas non-avx, which is safe, but wrong. If all vishera have AVX (i guess they have) so i'll fix. However the difference between aes and aes+avx is berely noticeable, except on the no-cache threads, where it gives a light boost (read: you go from 2h/s to 2.5h/s or something) Tongue

Topic: [XMR] JCE Miner Cryptonight/forks, now with GPU! - page 46. (Read 90814 times)