Pages:
Author

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

jr. member
Activity: 46
Merit: 1
Hello
I use proxy XNP.
jCE version 32j
Count shares and hashrate don't equal in proxy and miner
How can you explain it?
http://prntscr.com/kozqvs
jr. member
Activity: 176
Merit: 2
No nVidia mining sorry Wink
Not yet Smiley

Dual mining with a non-memory intensive coin is a smart idea, but it would require lots of changes in my netcode which is completely bound to Cryptonight-style coin. Again, the first step would be the multi-pool netcode. I'm still working on it.

I pretend to be the fastest on :
* small RX550 and 560 (2G)
* Bittube on some GPU
* old HD6000/7000 if you consider claymore 9.7 as dead
* CPUs, in a more or less large scale depending on the cpu and algo (far beyond on non-aes, Turtle or Tube-v2, noticeably faster on v7 and heavy, close to other on CN-classic). And i provide exclusive features like no-cache mode or 6x multi-hash.
* ratio between displayed hashrate/real hashrate (98%, i benched Claymore 11 to rather ~92%, and got bad reports about others)

But not better at
* CN-heavy
* Vega FE
* large-mem RX

I'm working on 0.32k focused on hashrate consistency, with
* Watchdog
* Shorter warmup but then better re-sync in case:
** The warmup failed to reach 100% (in such case it will have high chances of success during the next minutes if you let it run)
** The GPU was paused or pool got disconnected

rx 580 8gb cn-heavy is the best compare with other miner.
rx vega 56 cn-v7 is the best compare with other miner.
member
Activity: 762
Merit: 35
No nVidia mining sorry Wink
Not yet Smiley

Dual mining with a non-memory intensive coin is a smart idea, but it would require lots of changes in my netcode which is completely bound to Cryptonight-style coin. Again, the first step would be the multi-pool netcode. I'm still working on it.

I pretend to be the fastest on :
* small RX550 and 560 (2G)
* Bittube on some GPU
* old HD6000/7000 if you consider claymore 9.7 as dead
* CPUs, in a more or less large scale depending on the cpu and algo (far beyond on non-aes, Turtle or Tube-v2, noticeably faster on v7 and heavy, close to other on CN-classic). And i provide exclusive features like no-cache mode or 6x multi-hash.
* ratio between displayed hashrate/real hashrate (98%, i benched Claymore 11 to rather ~92%, and got bad reports about others)

But not better at
* CN-heavy
* Vega FE
* large-mem RX

I'm working on 0.32k focused on hashrate consistency, with
* Watchdog
* Shorter warmup but then better re-sync in case:
** The warmup failed to reach 100% (in such case it will have high chances of success during the next minutes if you let it run)
** The GPU was paused or pool got disconnected

I understand your focus. My question was if you can provide settings
for using JCE miner + Roi coin miner combo.
newbie
Activity: 54
Merit: 0
Sure Wink
Again, JCE has protection against everything with is not a direct normal connection to internet :
* proxy
* vpn
* tunnel
* fake DNS
* fake WAN
* ...
This protection could be a problem to me within a few months.
I don't have and don't need a VPN now because my actual ISP does not work with HADOPI (the french anti-piracy establishment) Roll Eyes
But my VDSL2 connection will be replaced by a FTTH one during 2019 or the early 2020 and it should come with another ISP that works with HADOPI, making me to need a VPN 24h/24 and as I mine with my main PC, my mining softwares will be affected by this VPN.

Perhaps you should offer to disable this protection through a parameter or to declare a legit VPN, with the suitable warnings about the dangers.
member
Activity: 350
Merit: 22
Sure Wink
Again, JCE has protection against everything with is not a direct normal connection to internet :
* proxy
* vpn
* tunnel
* fake DNS
* fake WAN
* ...
newbie
Activity: 54
Merit: 0
I'm working on 0.32k focused on hashrate consistency, with
* Watchdog
* Shorter warmup but then better re-sync in case:
** The warmup failed to reach 100% (in such case it will have high chances of success during the next minutes if you let it run)
** The GPU was paused or pool got disconnected
Please do not forget to soften the anti-proxy heuristic feature to settle my connection issue Wink
member
Activity: 350
Merit: 22
No nVidia mining sorry Wink
Not yet Smiley

Dual mining with a non-memory intensive coin is a smart idea, but it would require lots of changes in my netcode which is completely bound to Cryptonight-style coin. Again, the first step would be the multi-pool netcode. I'm still working on it.

I pretend to be the fastest on :
* small RX550 and 560 (2G)
* Bittube on some GPU
* old HD6000/7000 if you consider claymore 9.7 as dead
* CPUs, in a more or less large scale depending on the cpu and algo (far beyond on non-aes, Turtle or Tube-v2, noticeably faster on v7 and heavy, close to other on CN-classic). And i provide exclusive features like no-cache mode or 6x multi-hash.
* ratio between displayed hashrate/real hashrate (98%, i benched Claymore 11 to rather ~92%, and got bad reports about others)

But not better at
* CN-heavy
* Vega FE
* large-mem RX

I'm working on 0.32k focused on hashrate consistency, with
* Watchdog
* Shorter warmup but then better re-sync in case:
** The warmup failed to reach 100% (in such case it will have high chances of success during the next minutes if you let it run)
** The GPU was paused or pool got disconnected
member
Activity: 280
Merit: 10
I explicitly benched my miner against Claymore 9.7, and i also explicitly said i couldn't beat it, by an order of magnitude. It can push my HD7850 1G to 450, i cannot go above 370 Cry but yes, i'm still second, other miners are still worse. But i found jce a lot more stable than Claymore 11.3 and faster on cards with 2G+ memory.

On RX550 and RX560 jce should be the best if configured properly, which include waiting for 5-10 minutes after each start to let it warm up.
On RX460 2G use multi-hash 416, 432, 448 or 464, worksize 8, alpha 4 or 8, beta 64. On 4G, use same and multi_hash 464.

Otherwise try the 0.31e, the most stable so far, it takes ages to compile its opencl but may mine a bit faster than 0.32 in some cases.

It's true. Clay 9.7 knows the secret but no longer works on new algorithms. So now JCE it's the number one miner for old GPU (HD6870 on Clay - 290Hs, JCE - 260Hs (effectiv 240).
 { "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta":4, "index" : 0, "multi_hash":368 },


On RX 460 4G new SRB1.6.6 after 5-10m give 463Hs on each GPU. JCE stuck on 420-440 depending on the card (like old srb 1.30)
I also had that the cards gave out only half of the maximum speed. Noticed once
3*RX460
 { "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta":4, "index" : 0, "multi_hash":464 },
 { "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta":4, "index" : 0, "multi_hash":464 },
 { "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta":4, "index" : 1, "multi_hash":464 },
 { "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta":4, "index" : 1, "multi_hash":464 },
 { "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta":4, "index" : 2, "multi_hash":464 },
 { "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta":4, "index" : 2, "multi_hash":464 },
newbie
Activity: 46
Merit: 0
Just started mining using

NVidia gtx 105ti gpu
i3 7th gen
with 8gb ram

current hash rate 64.5h/s using only the cpu


Sorry Mining is a new thing for me how much coin can I expect from this power. How can I switch the mining to GPU btw?

I already did use the gpu prototype but still it is mining using my cpu power

only AMD cards. You can use xmr-stak for nvidia cards.
hero member
Activity: 1246
Merit: 588
Just started mining using

NVidia gtx 105ti gpu
i3 7th gen
with 8gb ram

current hash rate 64.5h/s using only the cpu


Sorry Mining is a new thing for me how much coin can I expect from this power. How can I switch the mining to GPU btw?

I already did use the gpu prototype but still it is mining using my cpu power
full member
Activity: 729
Merit: 114


1272 H/s on Bittube.  Peaked 1312 H/s on an RX 570 8GB.
member
Activity: 762
Merit: 35
Hi JCE, please check this thread:

https://bitcointalk.org/index.php?topic=2361848.3440;topicseen

And provide a way to dual mine Cryptonight 7 + RoI coin using JCEminer.
Thanks!
member
Activity: 350
Merit: 22
I explicitly benched my miner against Claymore 9.7, and i also explicitly said i couldn't beat it, by an order of magnitude. It can push my HD7850 1G to 450, i cannot go above 370 Cry but yes, i'm still second, other miners are still worse. But i found jce a lot more stable than Claymore 11.3 and faster on cards with 2G+ memory.

On RX550 and RX560 jce should be the best if configured properly, which include waiting for 5-10 minutes after each start to let it warm up.
On RX460 2G use multi-hash 416, 432, 448 or 464, worksize 8, alpha 4 or 8, beta 64. On 4G, use same and multi_hash 464.

Otherwise try the 0.31e, the most stable so far, it takes ages to compile its opencl but may mine a bit faster than 0.32 in some cases.
member
Activity: 280
Merit: 10
After switching to a new algo, all the miners began to work badly on old HD6870. This one is the closest to Clay9.7  Cool
But with RX460, it works worse than the srb. I do not know why
member
Activity: 350
Merit: 22
Ok i got it, thanks to your log. And yes, that's my anti-proxy heuristic that is too strong (unless you're a shadow hacker Wink ) This is why it locks the connection, and then, with no way to mine, the miner stops by itself. I cannot give more explanations or it will cancel the principle of a anti hack protection, but that's it.
I'll relax it in next version.
newbie
Activity: 54
Merit: 0
give a try to a simple pool like xmrpool.eu, which is cn-v7, it works for me on 0.32, same for hashvault.pro for example (tested on graft and xmr).
The difference is not about the algo, but about the pool network config, which may conflict with my security.
I had the issue while mining XCA on three different pools.
I actually have it too while mining XMR on XMRPool.eu. I tried three different ports: 3333, 5555 and 7777.

That's why I concluded the issue was related to the algo but if the 0.32+ works fine on XMRpool.eu on your setup, and as I'm apparently the only one to have it, the issue must be related to my setup, but I have no clue of its cause or location.
I tried to disable the firewall and I don't even have any antivirus running.
I even compared 0.31f and 0.32j on another computer, and the same issue pops up with 0.32j while the 0.31f runs fine.

My log has a weird line "Successfuly logged" because all the others claim the connection fails:

Code:
20:56:12 | Socket connect error: Cannot reach pool on Internet, is your connection up?
20:56:12 | Connected to pool. Now logging in...
20:56:12 | Unloaded OpenCL kernels of GPU Thread 10
20:56:12 | Unloaded OpenCL kernels of GPU Thread 11
20:56:12 | Unloaded OpenCL kernels of GPU Thread 8
20:56:12 | Released OpenCL Thread 8 Scratchpad at 000002b62258d6d0
20:56:12 | Released OpenCL Thread 10 Scratchpad at 000002b62986fcb0
20:56:12 | Released OpenCL Thread 11 Scratchpad at 000002b62ccf56e0
20:56:12 | Unloaded OpenCL kernels of GPU Thread 9
20:56:12 | Released OpenCL Thread 9 Scratchpad at 000002b62986ec30
20:56:12 | Released OpenCL Thread 10 Command-Queue of GPU 1 at 000002b6226a51a0
20:56:12 | Released OpenCL Thread 8 Command-Queue of GPU 0 at 000002b6226a5c20
20:56:12 | Released OpenCL Thread 11 Command-Queue of GPU 1 at 000002b6226a56e0
20:56:12 | Released OpenCL Thread 9 Command-Queue of GPU 0 at 000002b6226a5830
20:56:12 | Successfuly logged as [my_XMR_wallet].100000+PC40
20:56:12 | Released OpenCL Context 000002b62239b2d0 of GPU 0
20:56:12 | Pool connection socket closed.

If I block the connection with the firewall, I get another log:

Code:
21:04:07 | Connection failed: Socket connect error: Une tentative dӡcc鳠ࡵn socket de mani鳥 interdite par ses autorisations dӡcc鳠a 굩 tentꥮ
21:04:07 | Connection interrupted, waiting 5s then retry, attempt #1
21:04:23 | Connecting to mining pool xmrpool.eu:5555 ...
21:04:23 | Connection failed: Socket connect error: Une tentative dӡcc鳠ࡵn socket de mani鳥 interdite par ses autorisations dӡcc鳠a 굩 tentꥮ
21:04:23 | Connection interrupted, waiting 5s then retry, attempt #2
21:04:28 | Connecting to mining pool xmrpool.eu:5555 ...
21:04:28 | Connection failed: Socket connect error: Une tentative dӡcc鳠ࡵn socket de mani鳥 interdite par ses autorisations dӡcc鳠a 굩 tentꥮ
21:04:28 | Connection interrupted, waiting 5s then retry, attempt #3
21:04:33 | Connecting to mining pool xmrpool.eu:5555 ...
21:04:33 | Connection failed: Socket connect error: Une tentative dӡcc鳠ࡵn socket de mani鳥 interdite par ses autorisations dӡcc鳠a 굩 tentꥮ
21:04:33 | Connection interrupted, waiting 5s then retry, attempt #4
21:04:38 | Connecting to mining pool xmrpool.eu:5555 ...
21:04:41 | Connection failed: Socket connect error: Une tentative dӡcc鳠ࡵn socket de mani鳥 interdite par ses autorisations dӡcc鳠a 굩 tentꥮ
21:04:41 | Connection interrupted, waiting 5s then retry, attempt #5
member
Activity: 350
Merit: 22
There were some netcode changes on the 0.32+, i'll revert some of them in next 0.32 (probably k) betting it could fix the regression. But there's no code specific to an algo, except Nicehash. What may happen is that some pools use a proxy internally when the datarate is huge (like xmrig-proxy) that is detected and blocked by my netcode. I forbid use of proxy for security reason, to avoid being turned into stealth botnet (even if it applied more to the cpu version, i don't think there are GPU botnets). So i'll relax a bit the detect.

give a try to a simple pool like xmrpool.eu, which is cn-v7, it works for me on 0.32, same for hashvault.pro for example (tested on graft and xmr).
The difference is not about the algo, but about the pool network config, which may conflict with my security.

Quote
Claymore cryptonote
sure Grin

Quote
driver 18.3.4 with JCE 032h or 032j (heavy algorithm) everything fine with 8 GPU or 10 GPU.
i experienced that regression on my simple 3 cards rig when upgrading from 18.6 to 18.8

Try to lower a lot the multi_hash, even if it causes perf regression. Like use 75% of previous allocation, for test. I expect it then runs stable. Then increase back by steps of 16. The later are the AMD drivers, the less memory I can allocate staying stable. Cry
full member
Activity: 1120
Merit: 131


Am I the only one to have to use the 0.31f to mine CN V7?


0.32G for me. I sometimes mine graft.
jr. member
Activity: 31
Merit: 5
Am I the only one to have to use the 0.31f to mine CN V7?
I also use version 31f, but for another reason. All versions after do not restore the maximum speed in case of disconnect on my rig from 12 550. Versions after 31f do not always have time to give the cards to the maximum speed in the allotted time. On version 31f some cards go to the best mode only for 30 minutes, but they do it! I'm writing this about the fast algorithm. http://prntscr.com/knwz2e

newbie
Activity: 54
Merit: 0
you can try telnet to your pool and port you are using from command prompt, if you are able to connect then should be good.
you also can try other pool just to check.

telnet xmr-asia1.nanopool.org 14444 that is the example if your pool is nanopool and you are using port 14444.

Telnet runs fine and such does jce_cn_gpu_miner64.exe 0.31f or older.

The issue only occurs on 0.32 versions (from 0.32a to 0.32j) and I can't understand why, especially why it only affects the Cryptonight V7 (--variation 3).
I've also tried to replace the .exe in the same directory, but the result is the same.
Pages:
Jump to: