Pages:
Author

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

newbie
Activity: 301
Merit: 0
Hi,

Have your software work in ryzen apu?

Thanks
newbie
Activity: 88
Merit: 0
Quote
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! Smiley  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'! Smiley

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.



newbie
Activity: 33
Merit: 0
JCE CPU 0.33e . Windows 7 x64. Monero V8. Core2Quad and Core2Xeon increased even +3 h/s. Good job!
member
Activity: 77
Merit: 10
Quote
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.
member
Activity: 350
Merit: 22
Quote
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.
newbie
Activity: 88
Merit: 0
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?  Smiley


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)...  Roll Eyes
just login was painful Cry
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
Huh!
newbie
Activity: 17
Merit: 0
Quote
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  Grin

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 Sad

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
member
Activity: 350
Merit: 22
Quote
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  Grin

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 Sad
newbie
Activity: 17
Merit: 0
will there be a linux gpu version at all
newbie
Activity: 33
Merit: 0
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 Cheesy
I've been waiting for you to do this for a long time.
Quote
+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
member
Activity: 350
Merit: 22
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 Cheesy

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
Quote
+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
newbie
Activity: 24
Merit: 0
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.
member
Activity: 350
Merit: 22
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?

Quote
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.
newbie
Activity: 24
Merit: 0
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!

member
Activity: 190
Merit: 59
Hi all,

can somebody share good config for heavy algo, or bittube (cn-haven) for Vega cards. Thanks!
newbie
Activity: 33
Merit: 0

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?
member
Activity: 190
Merit: 59
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  Grin
gvb
jr. member
Activity: 140
Merit: 9
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)
member
Activity: 350
Merit: 22
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.

Quote
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
jr. member
Activity: 140
Merit: 9
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?
Pages:
Jump to: