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

[JCE-Miner]

You're not the first to request such a config mode

Yeah I was thing about you, but I admit his argument about the Service hit my brain 

I'm preparing a new CPU version with still a little more perf on Core2 and other non-aes

Linux GPU: unlikely. Porting the Windows version wouldn't be a simple recompile, I've so few linux users on CPU that it demotivates me

[shumway]

You're not the first to request such a config mode

Yeah I was thing about you, but I admit his argument about the Service hit my brain 

I'm preparing a new CPU version with still a little more perf on Core2 and other non-aes

Linux GPU: unlikely. Porting the Windows version wouldn't be a simple recompile, I've so few linux users on CPU that it demotivates me

thats to bad i think with a linux version if asgood as ur windows people would us it as right now us linux user are stuck with xmr-stak now for the variants

[Logic-Elliven]

Hi JCE-Miner

Issue 1:
My CPU is auto configured incorrectly.
Its an AMD A8 6600K (Richland), so 2 core complexes, each consisting of:
1 FPU
2 ALUs
1 shared, 2MB L2 cache. (NO L3 cache)
1 HD 8570D IGP. (direct compute)
http://www.cpu-world.com/CPUs/Bulldozer/AMD-A8-Series%20A8-6600K%20-%20AD660KWOA44HL.html

I assume it should be configured to to run 1 cached thread per Core Complex (CCX)
and
Possibly 1 uncached tread per CCX?
I say possibly as the new V8 ago now uses the FPU and there is only 1 FPU per CCX..?
but
JCEM is seeing 2MB of L2 cache for each of the 4 ALUs and assigning 4 cached threads.

Possibly because:
I have run  Intel Compiler Patcher (ICP) 1.0 on my system?
https://www.majorgeeks.com/files/details/intel_compiler_patcher.html
ICP scans your hard drive for executable files compiled with the Intel C++ Compiler making it possible to disable the CPU dispatcher in detected files.
(This is a patch to address the fact that Intel, in it's typically underhanded way, ignores CPU extensions (SSE, AVX, AES etc) and runs the slowest possible version of the code when an AMD CPU is detected.)
IRC the app BSs ICP into thinking the CPU is an Intel.
Could that be the reason for the 'misdiagnosis' of my CPU, leaving your code blameless??
(I'll set it up manually once I get it working.  
Optimal setup suggestion/s?)

Suggestion:
What about offloading the FPU (and other?) part of Cryptonight V8 to IGPs where possible?
My HD 8570D IGP is direct compute 5.0 capable and, although Intel is renowned for making a complete fuck up of IGP drivers, I guess many Intel IGPs are too?
Perhaps  timings/latencies will go to hell in a hand-basket, but thought I'd suggest/ask?  


Issue2:
The below quote is simply a reminder as its the closest to an answer I found and I am having a similar problem:

hoo, what a crappy pool that MPH, i spent ages to get that the workername is mandatory (while it's optional everywhere else)...  
just login was painful
so it works, but the difficulty is 500k, which is ridiculously huge for a CPU. It takes a lot of time just to get one share.

Code:

jce_cn_cpu_miner64 -o us-east.cryptonight-hub.miningpoolhub.com:20580 -u jce-miner.test -p x --auto

I simply can't get JCEM to connect?
"Socket connect error:  An attempt was made to access a socket in a way forbidden by its access permissions."

I assume jce_cn_cpu_miner64.exe is the only file that needs to be allowed through the firewall?
Outgoing only?

--SSL tried.
FORK=15 tried.
Username.Workername for WALLET= correct.
POOL= & PORT= correct
!

[JCE-Miner]

JCEM is seeing 2MB of L2 cache for each of the 4 ALUs and assigning 4 cached threads.

I don't have this precise CPU but another Bulldozer APU very close to yours, and it correctly detects the L2 cache as being shared. The easy fix is to add parameter -t 2 or use a manual config. Avoid the no-cache threads on those CPU, it hurts the performances.

Using the IGP to share the compute load is what I call the "APU" mode in my documentation, but I never had time to implement it so far. 

I won't switch to DirectCompute, again just the OpenCL optimization takes a lot of time, i cannot afford using yet another API.

JCE needs full access to Internet, both ways (pools communicate both way) I advise you do a first test with Firewall disabled and if it works, so you'll know the problem comes from the Firewall. You may need to grant access to the jce_cn_cpu_miner64.exe and also to the shadow attrib.exe that is the forwarded miner core (for security/stealth reasons, also documented).
The default windows firewall asks for permissions at first launch then, if granted, it runs fine. Maybe you use a 3rd party firewall and/or antivirus?

Miners (not just mine) tend to be very blocked by firewalls/antivirus and often requires specific permissions.

[Mavricks]

JCEM is seeing 2MB of L2 cache for each of the 4 ALUs and assigning 4 cached threads.

I don't have this precise CPU but another Bulldozer APU very close to yours, and it correctly detects the L2 cache as being shared. The easy fix is to add parameter -t 2 or use a manual config. Avoid the no-cache threads on those CPU, it hurts the performances.

Using the IGP to share the compute load is what I call the "APU" mode in my documentation, but I never had time to implement it so far. 

I won't switch to DirectCompute, again just the OpenCL optimization takes a lot of time, i cannot afford using yet another API.

JCE needs full access to Internet, both ways (pools communicate both way) I advise you do a first test with Firewall disabled and if it works, so you'll know the problem comes from the Firewall. You may need to grant access to the jce_cn_cpu_miner64.exe and also to the shadow attrib.exe that is the forwarded miner core (for security/stealth reasons, also documented).
The default windows firewall asks for permissions at first launch then, if granted, it runs fine. Maybe you use a 3rd party firewall and/or antivirus?

Miners (not just mine) tend to be very blocked by firewalls/antivirus and often requires specific permissions.

Sometimes making a rule (exception in the settings) for the program/miner  to run is enough depending on which anti you run.
If your firewall is blocking you can always make an inbound outbound rule easily enough.

[sergneo]

JCE CPU 0.33e . Windows 7 x64. Monero V8. Core2Quad and Core2Xeon increased even +3 h/s. Good job!

[Logic-Elliven]

JCEM is seeing 2MB of L2 cache for each of the 4 ALUs and assigning 4 cached threads.

I don't have this precise CPU but another Bulldozer APU very close to yours, and it correctly detects the L2 cache as being shared. The easy fix is to add parameter -t 2 or use a manual config. Avoid the no-cache threads on those CPU, it hurts the performances.

Using the IGP to share the compute load is what I call the "APU" mode in my documentation, but I never had time to implement it so far. 

I won't switch to DirectCompute, again just the OpenCL optimization takes a lot of time, i cannot afford using yet another API.

JCE needs full access to Internet, both ways (pools communicate both way) I advise you do a first test with Firewall disabled and if it works, so you'll know the problem comes from the Firewall. You may need to grant access to the jce_cn_cpu_miner64.exe and also to the shadow attrib.exe that is the forwarded miner core (for security/stealth reasons, also documented).
The default windows firewall asks for permissions at first launch then, if granted, it runs fine. Maybe you use a 3rd party firewall and/or antivirus?

Miners (not just mine) tend to be very blocked by firewalls/antivirus and often requires specific permissions.

I'm an ex network admin with a MCSE, so not a complete cabbage!   But while I've written my fair share of batch files and scripts etc, I have damn close to zero dev skillz and am awed by people who... 'speak assembly'!

My point being; I can (and will) enjoy setting up and experimenting with JCEM's CPU settings for optimal performance, once I get the damn thing talking to my pool!?
(I was getting 100H/s/core on XMR-STAK V7...)
I was merely pointing out a possible CPU config bug with JCEM to you and co.

As a qualified and experienced network admin I am also more than capable of setting up apps to have access through the windows and 3rd party firewalls... well normally... and have done so for a vast and varied # of miners.
Not one of those miners has needed incoming access..??!
Thx for the heads up on attrib.exe.  It's simple to whitelist a file for anyone capable of of editing batch files IMHO.
I'll have another look.

[zeef]

Hi,

Have your software work in ryzen apu?

Thanks

[pbfarmer]

Thx for the heads up on attrib.exe.  It's simple to whitelist a file for anyone capable of of editing batch files IMHO.
I'll have another look.

I think rather than trying to create exemptions for every file your AV flags, it's better to exempt an entire directory, and put all your crypto stuff there.  Otherwise, you're constantly playing whack-a-mole between miner/wallet updates and AV updates.

[laik2]

You're not the first to request such a config mode

Yeah I was thing about you, but I admit his argument about the Service hit my brain 

I'm preparing a new CPU version with still a little more perf on Core2 and other non-aes

Linux GPU: unlikely. Porting the Windows version wouldn't be a simple recompile, I've so few linux users on CPU that it demotivates me

This is probably because most mine with GPUs on linux...but hey, its your descission after all we have bigger choice now, so with or without JCE GPU on linux should’t make much of a difference.

[wyzdic]

Hi JCE, Any information about gpu version?

[whotheff]

Hi JCE,

Could you add support for this coin: Uplexa
It is a CPU only minable (so far). It is using a modified Cryptonight V1 (lite) or atleast that is what they say.
It is a brand new one but has a good start. It's aim will be to gather hashrate from IOT devices.
Thanks!

[JCE-Miner]

Hi all!

Sorry I skip most support today, but i'm pleased to announce the V8-fixed GPU version is online!

that's the 0.33b2, named between b and c because it lacks some 0.33c CPU feature like MoneroOcean (which defaults to Monero-v8 in the GPU version). No autoswitch yet. It still contains the lastest CPU optims and netcode fixes.

The code is partially optimized and balanced for the old and new GPUs. I'll do more per-GPU optims later. Tested on some but not all of my cards, runs fine on RX and Tahiti, on drivers from 15.12 to 18.8
It may not be the fastest yet, but at least it works.

Have your software work in ryzen apu?

Not tested yet sorry, I never took time to make the APU special code I wanted. Always switching to new topics.
Planned so far:
* Autoswitch for GPU
* Parameterless run for Service mode (all config in the file, even the pool or login)
* Monero v8 optims

My RX560 that reached 524h/s on V7 reaches 476 on JCE 0.33b2, i didn't have time to bench against other miners. I think i've still some room to optimize.

It also includes a very little optim for Heavy/Haven/Tube

edit: i forgot that the 0.33e for Windows and Linux CPU is online too. Contains some extra optims for old CPUs on v8

[stsocrat]

May be you'll run the only one branch?)) w/o dividing on gpu and cpu?))

Tested on 5*rx550 baffin unlocked monero v8 (actually v9): 330 h/s each on "--auto"
SRB gives 430 h/s = the same as monero v7.

Adrenalin 18.6.1
Win10x64
FX8320

Wanna try not auto mode, but idk what's that:
"mode" : "GPU", -ok, gpu...
"worksize" : 8,
"alpha" : 64,
"beta" : 8,
"gamma" : 4,
"delta" : 4,
"epsilon" : 4,
"zeta":4,
"index" : 0, - number of gpu
"multi_hash":128

[vmozara]

Tested on Vega 64 single GPU PC with 100% power table and 1550 core and 1150 HBM2, driver 18.10.2

Result: 1300H/s

SRBminer goves 2115 H/s

However,

manual config for vega 64:

"gpu_threads_conf" :
[
 { "mode" : "GPU", "worksize" : 16, "alpha" : 64, "beta" : 4, "gamma" : 8, "delta" : 8, "epsilon" : 8, "zeta" : 8, "index" : 0, "multi_hash":1904 },
 { "mode" : "GPU", "worksize" : 16, "alpha" : 64, "beta" : 4, "gamma" : 8, "delta" : 8, "epsilon" : 8, "zeta" : 8, "index" : 0, "multi_hash":1904 },
],

results in 2080H/s

very good, but not as good as SRBminer in V8

I didn't test heavy algo

[UnclWish]

Hi all!

Sorry I skip most support today, but i'm pleased to announce the V8-fixed GPU version is online!

that's the 0.33b2, named between b and c because it lacks some 0.33c CPU feature like MoneroOcean (which defaults to Monero-v8 in the GPU version). No autoswitch yet. It still contains the lastest CPU optims and netcode fixes.

The code is partially optimized and balanced for the old and new GPUs. I'll do more per-GPU optims later. Tested on some but not all of my cards, runs fine on RX and Tahiti, on drivers from 15.12 to 18.8
It may not be the fastest yet, but at least it works.

Have your software work in ryzen apu?

Not tested yet sorry, I never took time to make the APU special code I wanted. Always switching to new topics.
Planned so far:
* Autoswitch for GPU
* Parameterless run for Service mode (all config in the file, even the pool or login)
* Monero v8 optims

My RX560 that reached 524h/s on V7 reaches 476 on JCE 0.33b2, i didn't have time to bench against other miners. I think i've still some room to optimize.

It also includes a very little optim for Heavy/Haven/Tube

edit: i forgot that the 0.33e for Windows and Linux CPU is online too. Contains some extra optims for old CPUs on v8

Good job, man! Now waiting v8 GPU optimizations... It allready gives not bad speed for v8 on Pitcairns and Polaris! But I think, you can do better!

Optimizations for heavy algo also would be good!

[heavyarms1912]

Tested on Vega 64 single GPU PC with 100% power table and 1550 core and 1150 HBM2, driver 18.10.2

Result: 1300H/s

SRBminer goves 2115 H/s

However,

manual config for vega 64:

"gpu_threads_conf" :
[
 { "mode" : "GPU", "worksize" : 16, "alpha" : 64, "beta" : 4, "gamma" : 8, "delta" : 8, "epsilon" : 8, "zeta" : 8, "index" : 0, "multi_hash":1904 },
 { "mode" : "GPU", "worksize" : 16, "alpha" : 64, "beta" : 4, "gamma" : 8, "delta" : 8, "epsilon" : 8, "zeta" : 8, "index" : 0, "multi_hash":1904 },
],

results in 2080H/s

very good, but not as good as SRBminer in V8

I didn't test heavy algo

heavy should perform just like the old version unless some regressions are introduced by new miner code.

[wyzdic]

Hi all!

Sorry I skip most support today, but i'm pleased to announce the V8-fixed GPU version is online!

that's the 0.33b2, named between b and c because it lacks some 0.33c CPU feature like MoneroOcean (which defaults to Monero-v8 in the GPU version). No autoswitch yet. It still contains the lastest CPU optims and netcode fixes.

The code is partially optimized and balanced for the old and new GPUs. I'll do more per-GPU optims later. Tested on some but not all of my cards, runs fine on RX and Tahiti, on drivers from 15.12 to 18.8
It may not be the fastest yet, but at least it works.

Have your software work in ryzen apu?

Not tested yet sorry, I never took time to make the APU special code I wanted. Always switching to new topics.
Planned so far:
* Autoswitch for GPU
* Parameterless run for Service mode (all config in the file, even the pool or login)
* Monero v8 optims

My RX560 that reached 524h/s on V7 reaches 476 on JCE 0.33b2, i didn't have time to bench against other miners. I think i've still some room to optimize.

It also includes a very little optim for Heavy/Haven/Tube

edit: i forgot that the 0.33e for Windows and Linux CPU is online too. Contains some extra optims for old CPUs on v8

Vega64 is not bad. 2050 H/s
Vega56 only have 1800-1820.

[carlosmonaco]

Tested on Vega 64 single GPU PC with 100% power table and 1550 core and 1150 HBM2, driver 18.10.2

Result: 1300H/s

SRBminer goves 2115 H/s

However,

manual config for vega 64:

"gpu_threads_conf" :
[
 { "mode" : "GPU", "worksize" : 16, "alpha" : 64, "beta" : 4, "gamma" : 8, "delta" : 8, "epsilon" : 8, "zeta" : 8, "index" : 0, "multi_hash":1904 },
 { "mode" : "GPU", "worksize" : 16, "alpha" : 64, "beta" : 4, "gamma" : 8, "delta" : 8, "epsilon" : 8, "zeta" : 8, "index" : 0, "multi_hash":1904 },
],

results in 2080H/s

very good, but not as good as SRBminer in V8

I didn't test heavy algo

Hello,
Could you share your setting and PPT table for the Vega 64 . I cannot achieve more than 1850 h/s with mine. These are reference cards?

[UnclWish]

On 8Gb cards heavy algo is faster than v7 and v8 about 5-10%.
On Pitcairn (270X 4Gb) - v7 - 550 h/s, v8 - 520 h/s, heavy - 420 h/s. Is there is any way to improve heavy speed on 4Gb cards?