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

[wyzdic]

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)

[1715659624]

1715659624

[1715659624]

1715659624

[1715659624]

1715659624

[1715659624]

1715659624

[1715659624]

1715659624

[1715659624]

1715659624

[zeconadailytyclaymore]

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.

[JCE-Miner]

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.

[sergneo]

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.

[stsocrat]

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

[JCE-Miner]

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

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.

[JCE-Miner]

Pool managed autoswitch tests almost done.

Planned new features in the 0.33c CPU

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]

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

[gvb]

Howdy,

I think there's a problem with the lastest cpu+gpu version.

When starting it it was haning at compiling the gpu codes and my machine became unresponsive.

When having a closer look at it some windows thing that executes the exe (attribute helper?) was using more than 9 gigabyte of memory and still raising.

When I run is with --no-gpu it only uses 53Mb.

Seems like a momory leak somewhere in the GPU part?

[JCE-Miner]

Hi,

Yes the 0.33 GPU, when mining Monero v8, is broken, i put a warning on the github page and explained why. For short, i hadn't have time enough to finish it, and now i'm away of any GPU dev environment, until november.

The older algos, and the CPU part, should be fine.
I apologize for the long delay, I had to choose between finishing the CPU or GPU part, and JCE being mostly a CPU miner, I chose the CPU.

attribute helper?

It's an explicit antivirus bypass, explained in the doc (read the Github page or the file "is_it_a_virus.txt" in the .zip)

[gvb]

ok, thanks. I'll use the cpu only mode then.

F-Secure deepguard still sees it as a virus tho even when having the path and exe excluded.
(I turn off the F-Secure services before I start it and once the mined is started I start them again)

[vmozara]

JCE, It was an ok call. You started as CPU miner so the only fair thing to do is now keep CPU up to date. Still, you can understand us GPU guys as well after you spoiled us with your awesome GPU (especially Vega) performance. So here we are, eagerly waiting for your magic CN8 GPU version 

[sergneo]

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.

Core2Quad 6M, Xeon E5440 12M
when you enable cpu_architecture: generic_sse4_fpu, the hashrate drops to -2 h/s Monero V8. For which old CPU is it made?

[vmozara]

Hi all,

can somebody share good config for heavy algo, or bittube (cn-haven) for Vega cards. Thanks!

[stsocrat]

Can somebody explain me, if it possible to just run EXE file w/o any parameters with config file? (as i see it's impossible now)
I need it. I wanna run just exe file w/o any bat/cmd.

Now i'm having: Missing pool parameter -o

Better just run jce_cn_gpu_miner64.exe and it takes all parameters from config.txt!

[JCE-Miner]

You're not the first to request such a config mode, which I call the "xmr-stack style" but i'm dubtious:

* With your idea, you'd need two files, the .exe and one text file, which happens to be a .txt
* Currently, you need two files, the .exe and one text file, which happens to be a .bat

So what's the value added of using a .txt as config, and not a .bat with the exact same content, just in another format?

For which old CPU is it made?

I was thinking about the older CPU with a weak SSE2 unit, like the early P4. Otherwise, it's more for science than for production, that's to compare the two floating point units.
It may be useful also on CPU with some shared units, like the Athlon FX, with one thread on SSE2 and one on FPU. But i never tested, and doubt there would be a noticeable change.
That's for 64-bits, on 32 bits the SSE2 unit is always used, since v8 involves some extra 64 bits arithmetics only the SSE2 unit can decently do. In this case, the _fpu assemblies are just aliases of the normal assemblies.

I'm preparing CPU 0.33d, with a whooping +0.5% performance on non-aes-64
again, still no GPU dev possible for now.

[stsocrat]

1. About  "xmr-stack style": we're naming it Claymore style.
The reason we need it is that we're having many rigs (100+), and for upgrade old Claymore 3.9/4.0 into new your or another one, better just change some files w/o changing somethins in working machines.
On some pc's cn miner works as service through nssm (non-sucking service manager) or through some another.
And in all of that machines and rigs we're just having exe file in startup or in services.

2. Why win7 is not supported? On old pc we have winXP, it's ok, they are old and can mine only 20-60 h/s. Nobody have win8... some have win10... But the most other PCs are running Win7! Why not? Nobody have win8... a little have win10...

3. Found little bug.
Press P
Wait >2 min
Press P
Rejected share((
I think, miner doesn't clear old job after resuming.

[JCE-Miner]

No .bat to be able to run it as a service?
Yeah, that's a very good answer! Ok i may make a zero-param version based only on a config file

Windows7 : it is not supported for GPU mining, but CPU mining is supported back to Vista32
The reason is security, my OpenCL is injected into the OpenCL runtime, with no valid intermediate code that could be dumped on the fly, and this technique just doesn't work on Windows 7. It works on windows 8.1 and later.

Pause: i'll take a look, it may depend on what the miner was doing when you pressed p, and if it finds a share just after. there may be cases I missed.
edit: yeah i found a case that may make a stale (invalid) share, probably (but not sure) the same case that you experienced.

edit:
Online is
0.33d CPU Windows

+0.6% performance for Non-AES 64 bits
Fixed the possible stale share after a long pause

Also, the documentation for the Pool-managed autoswitch is online
https://github.com/jceminer/cn_cpu_miner#pool-managed-autoswitch

[sergneo]

No .bat to be able to run it as a service?
Yeah, that's a very good answer! Ok i may make a zero-param version based only on a config file

I've been waiting for you to do this for a long time.

+0.6% performance for Non-AES 64 bits
Fixed the possible stale share after a long pause

Yes on Core2Quad and Xeon more on +1 H/s

[shumway]

will there be a linux gpu version at all