monote
Newbie
Offline
Activity: 26
Merit: 1
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 26, 2018, 10:26:08 AM |
|
Jumps to 400k ? It's similar to a previous bug I already fixed about the share counter (which was a cosmetical but misleading bug). And again, only for CN-Heavy. I'll take a look back once i'm done with the Watchdog.
Yeah, actually taking a closer look, it did arrive to 1.5m diff... ![Shocked](https://bitcointalk.org/Smileys/default/shocked.gif) Btw, I'm using 32f version of the miner cause I don't know why, last version wasn't stable for me. After some time one of the cards randomly stops and resets its clocks to 300mhz...mega weird... Anyways, this doesn't happen (like NEVER) using 32f miner version ![Cheesy](https://bitcointalk.org/Smileys/default/cheesy.gif) Cheers mate!
|
|
|
|
wyzdic
Newbie
Offline
Activity: 46
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 27, 2018, 06:21:38 AM |
|
--bus-order It's very nice feature:P, JCE gpu list same with hwinfo now.
|
|
|
|
JCE-Miner (OP)
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 350
Merit: 22
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 27, 2018, 06:31:21 PM |
|
![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) It should have been the default order, but I wanted to be somehow compatible with claymore 9 and Stak (which also used OpenCL order). And now changing the default could cause chaos with existing configurations.
|
|
|
|
lebuawu2
Jr. Member
Offline
Activity: 176
Merit: 2
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 28, 2018, 10:32:19 AM |
|
Hi JCE,
thanks for additional report how many re-connection occurs (with that I can check if the hash rate drop mostly because of connection drop).
recently I tried driver 18.6.1 and 18.8.1 with JCE 032h or 032j (heavy algorithm) but it instantly crash if all 8 or 10 GPU I used, but if I only configure 6 GPU it's fine. can you please help to take a look of this problem?
driver 18.3.4 with JCE 032h or 032j (heavy algorithm) everything fine with 8 GPU or 10 GPU.
Thanks.
|
|
|
|
lebuawu2
Jr. Member
Offline
Activity: 176
Merit: 2
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 28, 2018, 10:59:18 AM |
|
![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) It should have been the default order, but I wanted to be somehow compatible with claymore 9 and Stak (which also used OpenCL order). And now changing the default could cause chaos with existing configurations. I believe you are referring to Claymore cryptonote, because Claymore ethash since version 9.6 already sorted by bus id. yes we need to change the config if in one rig contains different GPU type, but I still prefer with order by bus id because of GPU-Z, HWInfo, OverdriveNTool they order by bus id.
|
|
|
|
lebuawu2
Jr. Member
Offline
Activity: 176
Merit: 2
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 28, 2018, 11:03:18 AM |
|
Jumps to 400k ? It's similar to a previous bug I already fixed about the share counter (which was a cosmetical but misleading bug). And again, only for CN-Heavy. I'll take a look back once i'm done with the Watchdog.
Yeah, actually taking a closer look, it did arrive to 1.5m diff... ![Shocked](https://bitcointalk.org/Smileys/default/shocked.gif) Btw, I'm using 32f version of the miner cause I don't know why, last version wasn't stable for me. After some time one of the cards randomly stops and resets its clocks to 300mhz...mega weird... Anyways, this doesn't happen (like NEVER) using 32f miner version ![Cheesy](https://bitcointalk.org/Smileys/default/cheesy.gif) Cheers mate! it's a bit strange because for me static diff work perfectly with miner.rocks.
|
|
|
|
Lermite
Newbie
Offline
Activity: 54
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 28, 2018, 11:15:56 AM |
|
I have an issue that I've already explained to JCE on a french forum, but I'd like to know if I'm the only one.
It happens with every 0.32 versions and only on Cryptonight V7 (--variation 3): each connection attempt to the pool fails. All the other algos (CN Light, Heavy, Saber,...) work fine with the 0.32 versions. The issue only concerns CN V7.
The culprit is not my firewall because disabling it has no effect on the issue.
Am I the only one to have to use the 0.31f to mine CN V7?
|
|
|
|
lebuawu2
Jr. Member
Offline
Activity: 176
Merit: 2
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 28, 2018, 12:03:19 PM |
|
I have an issue that I've already explained to JCE on a french forum, but I'd like to know if I'm the only one.
It happens with every 0.32 versions and only on Cryptonight V7 (--variation 3): each connection attempt to the pool fails. All the other algos (CN Light, Heavy, Saber,...) work fine with the 0.32 versions. The issue only concerns CN V7.
The culprit is not my firewall because disabling it has no effect on the issue.
Am I the only one to have to use the 0.31f to mine CN V7?
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.
|
|
|
|
Lermite
Newbie
Offline
Activity: 54
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 28, 2018, 12:59:46 PM |
|
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.
|
|
|
|
Sx5000
Jr. Member
Offline
Activity: 31
Merit: 5
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 28, 2018, 05:08:57 PM |
|
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
|
|
|
|
Iamtutut
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 28, 2018, 06:03:14 PM |
|
Am I the only one to have to use the 0.31f to mine CN V7?
0.32G for me. I sometimes mine graft.
|
|
|
|
JCE-Miner (OP)
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 350
Merit: 22
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 28, 2018, 06:22:53 PM |
|
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. Claymore cryptonote sure ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) 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](https://bitcointalk.org/Smileys/default/cry.gif)
|
|
|
|
Lermite
Newbie
Offline
Activity: 54
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 28, 2018, 07:06:39 PM |
|
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: 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: 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
|
|
|
|
JCE-Miner (OP)
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 350
Merit: 22
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 28, 2018, 07:21:23 PM |
|
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](https://bitcointalk.org/Smileys/default/wink.gif) ) 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.
|
|
|
|
korm
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 280
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 29, 2018, 06:26:51 PM |
|
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](https://bitcointalk.org/Smileys/default/cool.gif) But with RX460, it works worse than the srb. I do not know why
|
|
|
|
JCE-Miner (OP)
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 350
Merit: 22
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 29, 2018, 08:22:53 PM |
|
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](https://bitcointalk.org/Smileys/default/cry.gif) 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.
|
|
|
|
|
heavyarms1912
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 30, 2018, 03:03:46 AM |
|
![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2F4NMcmsu.jpg&t=665&c=n16FOD21jTow-A) 1272 H/s on Bittube. Peaked 1312 H/s on an RX 570 8GB.
|
|
|
|
darklus123
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 30, 2018, 07:56:06 AM Last edit: August 30, 2018, 08:09:51 AM by darklus123 |
|
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
|
|
|
|
wyzdic
Newbie
Offline
Activity: 46
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 30, 2018, 09:29:27 AM |
|
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.
|
|
|
|
|