 Show Posts
|
|
Pages: [1] 2 3 »
|
PM 4.1c with 13xAMD RX580-8GB Fails using turbo mode kernel (-clkernel 3)
Error - immediately following DAG load; always exactly the same error. Switch back to 4.0b works great.
019.01.16:09:06:46.114: GPU7 GPU7: Using Ethash OCL kernels (Ellesmere; -clkernel 3)
2019.01.16:09:06:46.355: GPU10 GPU10: DAG 100%
2019.01.16:09:06:46.480: GPU8 GPU8: DAG 100%
2019.01.16:09:06:47.111: GPU11 GPU11: DAG 100%
2019.01.16:09:06:47.154: GPU12 GPU12: DAG 100%
2019.01.16:09:06:47.160: GPU9 GPU9: DAG 100%
2019.01.16:09:06:47.410: main
2019.01.16:09:06:47.410: main *** 0:00 *** 1/16 09:06 **************************************
2019.01.16:09:06:47.410: main Eth: Mining ETH on eu1.ethermine.org:4444 for 0:00
2019.01.16:09:06:47.410: main Eth: Accepted shares 0 (0 stales), rejected shares 0 (0 stales)
2019.01.16:09:06:47.410: main Eth: Incorrect shares 0 (0.00%), est. stales percentage 0.00%
2019.01.16:09:06:47.410: main Eth: Average speed (5 min): 86.233 MH/s
2019.01.16:09:06:47.410: main
2019.01.16:09:06:47.867: GPU12 GPU12: clEnqueueCopyBuffer (-4)
2019.01.16:09:06:47.984: GPU11 GPU11: clEnqueueCopyBuffer (-4)
2019.01.16:09:06:47.988: GPU8 GPU8: clEnqueueCopyBuffer (-4)
2019.01.16:09:06:48.140: GPU10 GPU10: DAG generated in 39.1 s (74.3 MB/s)
2019.01.16:09:06:48.141: GPU10 GPU10: Using Ethash OCL kernels (Ellesmere; -clkernel 3)
2019.01.16:09:06:48.178: GPU9 GPU9: DAG generated in 39.6 s (73.4 MB/s)
2019.01.16:09:06:48.179: GPU9 GPU9: Using Ethash OCL kernels (Ellesmere; -clkernel 3)
2019.01.16:09:06:48.206: GPU13 GPU13: DAG 100%
2019.01.16:09:06:48.229: main Eth speed: 107.135 MH/s, shares: 0/0/0, time: 0:00
2019.01.16:09:06:48.229: main GPUs: 1: 28.986 MH/s (0) 2: 25.954 MH/s (0) 3: 0.000 MH/s (0) 4: 28.715 MH/s (0) 5: 23.481 MH/s (0) 6: 0.000 MH/s (0) 7: 0.000 MH/s (0) 8: 0.000 MH/s (0) 9: 0.000 MH/s (0) 10: 0.000 MH/s (0) 11: 0.000 MH/s (0) 12: 0.000 MH/s (0) 13: 0.000 MH/s (0)
2019.01.16:09:06:48.277: wdog Thread(s) not responding. Restarting.
2019.01.16:09:06:48.409: GPU13 GPU13: clEnqueueCopyBuffer (-4)
2019.01.16:09:06:49.658: eths Eth: New job #b21615c5 from eu1.ethermine.org:4444; diff: 4000MH
2019.01.16:09:06:49.673: GPU8 GPU8: Starting up... (0)
2019.01.16:09:06:49.686: GPU11 GPU11: Starting up... (0)
2019.01.16:09:06:49.706: GPU12 GPU12: Starting up... (0)
2019.01.16:09:06:49.711: GPU13 GPU13: Starting up... (0)
2019.01.16:09:06:49.752: GPU8 GPU8: Allocating DAG (2x 2.85) GB; good for epoch up to #237
2019.01.16:09:06:49.752: GPU8 GPU8: Allocating light cache buffer (45.6) MB; good for epoch up to #237
2019.01.16:09:06:49.832: GPU11 GPU11: Allocating DAG (2x 2.85) GB; good for epoch up to #237
2019.01.16:09:06:49.832: GPU11 GPU11: Allocating light cache buffer (45.6) MB; good for epoch up to #237
2019.01.16:09:06:49.909: GPU12 GPU12: Allocating DAG (2x 2.85) GB; good for epoch up to #237
2019.01.16:09:06:49.909: GPU12 GPU12: Allocating light cache buffer (45.6) MB; good for epoch up to #237
2019.01.16:09:06:49.974: GPU8 GPU8: Generating DAG for epoch #235
2019.01.16:09:06:49.982: GPU8 GPU8: clEnqueueNDRangeKernel (-4)
2019.01.16:09:06:49.995: GPU13 GPU13: Allocating DAG (2x 2.85) GB; good for epoch up to #237
2019.01.16:09:06:49.995: GPU13 GPU13: Allocating light cache buffer (45.6) MB; good for epoch up to #237
2019.01.16:09:06:50.053: GPU11 GPU11: Generating DAG for epoch #235
2019.01.16:09:06:50.068: GPU11 GPU11: clEnqueueNDRangeKernel (-4)
2019.01.16:09:06:50.130: GPU12 GPU12: Generating DAG for epoch #235
2019.01.16:09:06:50.145: GPU12 GPU12: clEnqueueNDRangeKernel (-4)
2019.01.16:09:06:50.215: GPU13 GPU13: Generating DAG for epoch #235
2019.01.16:09:06:50.230: GPU13 GPU13: clEnqueueNDRangeKernel (-4)
2019.01.16:09:06:50.927: eths Eth: New job #ba79b5f7 from eu1.ethermine.org:4444; diff: 4000MH
2019.01.16:09:06:50.941: GPU8 GPU8: Starting up... (0)
2019.01.16:09:06:50.945: GPU11 GPU11: Starting up... (0)
2019.01.16:09:06:50.964: GPU12 GPU12: Starting up... (0)
2019.01.16:09:06:50.967: GPU13 GPU13: Starting up... (0)
2019.01.16:09:06:51.015: GPU8 GPU8: Allocating DAG (2x 2.85) GB; good for epoch up to #237
2019.01.16:09:06:51.015: GPU8 GPU8: Allocating light cache buffer (45.6) MB; good for epoch up to #237
2019.01.16:09:06:51.093: GPU11 GPU11: Allocating DAG (2x 2.85) GB; good for epoch up to #237
2019.01.16:09:06:51.093: GPU11 GPU11: Allocating light cache buffer (45.6) MB; good for epoch up to #237
2019.01.16:09:06:51.175: GPU12 GPU12: Allocating DAG (2x 2.85) GB; good for epoch up to #237
2019.01.16:09:06:51.175: GPU12 GPU12: Allocating light cache buffer (45.6) MB; good for epoch up to #237
On a second mixed rig 7+6 (nvidia/amd) seeing 0-0.3 MH/s hash rate increase. Tried -lidag 3, same results.
Increase the virtual memory of your system to at least 82 GB (13 X 2 X 3GB for the dags + 4GB for OS and apps) in order 4.1 to work. The VM increase does the trick. Thanks @bategojko74! |
|
|
|
|
PM 4.1c with 13xAMD RX580-8GB Fails using turbo mode kernel (-clkernel 3)
Error - immediately following DAG load; always exactly the same error. Switch back to 4.0b works great.
019.01.16:09:06:46.114: GPU7 GPU7: Using Ethash OCL kernels (Ellesmere; -clkernel 3)
2019.01.16:09:06:46.355: GPU10 GPU10: DAG 100%
2019.01.16:09:06:46.480: GPU8 GPU8: DAG 100%
2019.01.16:09:06:47.111: GPU11 GPU11: DAG 100%
2019.01.16:09:06:47.154: GPU12 GPU12: DAG 100%
2019.01.16:09:06:47.160: GPU9 GPU9: DAG 100%
2019.01.16:09:06:47.410: main
2019.01.16:09:06:47.410: main *** 0:00 *** 1/16 09:06 **************************************
2019.01.16:09:06:47.410: main Eth: Mining ETH on eu1.ethermine.org:4444 for 0:00
2019.01.16:09:06:47.410: main Eth: Accepted shares 0 (0 stales), rejected shares 0 (0 stales)
2019.01.16:09:06:47.410: main Eth: Incorrect shares 0 (0.00%), est. stales percentage 0.00%
2019.01.16:09:06:47.410: main Eth: Average speed (5 min): 86.233 MH/s
2019.01.16:09:06:47.410: main
2019.01.16:09:06:47.867: GPU12 GPU12: clEnqueueCopyBuffer (-4)
2019.01.16:09:06:47.984: GPU11 GPU11: clEnqueueCopyBuffer (-4)
2019.01.16:09:06:47.988: GPU8 GPU8: clEnqueueCopyBuffer (-4)
2019.01.16:09:06:48.140: GPU10 GPU10: DAG generated in 39.1 s (74.3 MB/s)
2019.01.16:09:06:48.141: GPU10 GPU10: Using Ethash OCL kernels (Ellesmere; -clkernel 3)
2019.01.16:09:06:48.178: GPU9 GPU9: DAG generated in 39.6 s (73.4 MB/s)
2019.01.16:09:06:48.179: GPU9 GPU9: Using Ethash OCL kernels (Ellesmere; -clkernel 3)
2019.01.16:09:06:48.206: GPU13 GPU13: DAG 100%
2019.01.16:09:06:48.229: main Eth speed: 107.135 MH/s, shares: 0/0/0, time: 0:00
2019.01.16:09:06:48.229: main GPUs: 1: 28.986 MH/s (0) 2: 25.954 MH/s (0) 3: 0.000 MH/s (0) 4: 28.715 MH/s (0) 5: 23.481 MH/s (0) 6: 0.000 MH/s (0) 7: 0.000 MH/s (0) 8: 0.000 MH/s (0) 9: 0.000 MH/s (0) 10: 0.000 MH/s (0) 11: 0.000 MH/s (0) 12: 0.000 MH/s (0) 13: 0.000 MH/s (0)
2019.01.16:09:06:48.277: wdog Thread(s) not responding. Restarting.
2019.01.16:09:06:48.409: GPU13 GPU13: clEnqueueCopyBuffer (-4)
2019.01.16:09:06:49.658: eths Eth: New job #b21615c5 from eu1.ethermine.org:4444; diff: 4000MH
2019.01.16:09:06:49.673: GPU8 GPU8: Starting up... (0)
2019.01.16:09:06:49.686: GPU11 GPU11: Starting up... (0)
2019.01.16:09:06:49.706: GPU12 GPU12: Starting up... (0)
2019.01.16:09:06:49.711: GPU13 GPU13: Starting up... (0)
2019.01.16:09:06:49.752: GPU8 GPU8: Allocating DAG (2x 2.85) GB; good for epoch up to #237
2019.01.16:09:06:49.752: GPU8 GPU8: Allocating light cache buffer (45.6) MB; good for epoch up to #237
2019.01.16:09:06:49.832: GPU11 GPU11: Allocating DAG (2x 2.85) GB; good for epoch up to #237
2019.01.16:09:06:49.832: GPU11 GPU11: Allocating light cache buffer (45.6) MB; good for epoch up to #237
2019.01.16:09:06:49.909: GPU12 GPU12: Allocating DAG (2x 2.85) GB; good for epoch up to #237
2019.01.16:09:06:49.909: GPU12 GPU12: Allocating light cache buffer (45.6) MB; good for epoch up to #237
2019.01.16:09:06:49.974: GPU8 GPU8: Generating DAG for epoch #235
2019.01.16:09:06:49.982: GPU8 GPU8: clEnqueueNDRangeKernel (-4)
2019.01.16:09:06:49.995: GPU13 GPU13: Allocating DAG (2x 2.85) GB; good for epoch up to #237
2019.01.16:09:06:49.995: GPU13 GPU13: Allocating light cache buffer (45.6) MB; good for epoch up to #237
2019.01.16:09:06:50.053: GPU11 GPU11: Generating DAG for epoch #235
2019.01.16:09:06:50.068: GPU11 GPU11: clEnqueueNDRangeKernel (-4)
2019.01.16:09:06:50.130: GPU12 GPU12: Generating DAG for epoch #235
2019.01.16:09:06:50.145: GPU12 GPU12: clEnqueueNDRangeKernel (-4)
2019.01.16:09:06:50.215: GPU13 GPU13: Generating DAG for epoch #235
2019.01.16:09:06:50.230: GPU13 GPU13: clEnqueueNDRangeKernel (-4)
2019.01.16:09:06:50.927: eths Eth: New job #ba79b5f7 from eu1.ethermine.org:4444; diff: 4000MH
2019.01.16:09:06:50.941: GPU8 GPU8: Starting up... (0)
2019.01.16:09:06:50.945: GPU11 GPU11: Starting up... (0)
2019.01.16:09:06:50.964: GPU12 GPU12: Starting up... (0)
2019.01.16:09:06:50.967: GPU13 GPU13: Starting up... (0)
2019.01.16:09:06:51.015: GPU8 GPU8: Allocating DAG (2x 2.85) GB; good for epoch up to #237
2019.01.16:09:06:51.015: GPU8 GPU8: Allocating light cache buffer (45.6) MB; good for epoch up to #237
2019.01.16:09:06:51.093: GPU11 GPU11: Allocating DAG (2x 2.85) GB; good for epoch up to #237
2019.01.16:09:06:51.093: GPU11 GPU11: Allocating light cache buffer (45.6) MB; good for epoch up to #237
2019.01.16:09:06:51.175: GPU12 GPU12: Allocating DAG (2x 2.85) GB; good for epoch up to #237
2019.01.16:09:06:51.175: GPU12 GPU12: Allocating light cache buffer (45.6) MB; good for epoch up to #237
On a second mixed rig 7+6 (nvidia/amd) seeing 0-0.3 MH/s hash rate increase. Tried -lidag 3, same results.
|
|
|
|
I using PM 3.0c and every 5 sometimes 6 days PM stop working. What happend and how to fix this? Have maybe someone .bat file for auto restar/reboot PM if PB stop working? 2018.07.26:00:42:06.959: eths Eth: Received: {"jsonrpc":"2.0","id":0,"result":["0xda40f35db43beeb3a7e6b66304068bbc0ca9ef3c25c4a8d68dad6a7de14835f0","0x0565d880e378b22250f35f260bac49983734114a9d338b7d7bacea1985c67dd4","0x000000006df37f675ef6eadf5ab9a2072d44268d97df837e6748956e5c6c2116"]}
2018.07.26:00:42:06.959: eths Eth: New job #da40f35d from eth-eu1.nanopool.org:9999; diff: 10000MH
2018.07.26:00:42:07.210: GPU3 GPU3: Starting up... (0)
2018.07.26:00:42:07.210: GPU3 Eth: Generating light cache for epoch #201
2018.07.26:00:42:07.370: GPU2 GPU2: Starting up... (0)
2018.07.26:00:42:07.396: GPU4 GPU4: Starting up... (0)
2018.07.26:00:42:07.396: GPU5 GPU5: Starting up... (0)
2018.07.26:00:42:07.422: GPU1 GPU1: Starting up... (0)
2018.07.26:00:42:07.429: GPU6 GPU6: Starting up... (0)
2018.07.26:00:42:10.009: GPU6 GPU6: Generating DAG for epoch #201
2018.07.26:00:42:10.009: GPU5 GPU5: Generating DAG for epoch #201
2018.07.26:00:42:10.010: GPU3 GPU3: Generating DAG for epoch #201
2018.07.26:00:42:10.011: GPU4 GPU4: Generating DAG for epoch #201
2018.07.26:00:42:10.011: GPU2 GPU2: Generating DAG for epoch #201
2018.07.26:00:42:10.011: GPU1 GPU1: Generating DAG for epoch #201
2018.07.26:00:42:11.238: main Eth speed: 0.000 MH/s, shares: 3574/0/22, time: 52:09
2018.07.26:00:42:11.238: main GPUs: 1: 0.000 MH/s (582) 2: 0.000 MH/s (595) 3: 0.000 MH/s (591) 4: 0.000 MH/s (596) 5: 0.000 MH/s (592) 6: 0.000 MH/s (618/22)
2018.07.26:00:42:11.511: GPU5 GPU5: DAG 19%
2018.07.26:00:42:11.515: GPU2 GPU2: DAG 19%
2018.07.26:00:42:11.515: GPU3 GPU3: DAG 19%
2018.07.26:00:42:11.518: GPU4 GPU4: DAG 19%
2018.07.26:00:42:11.528: GPU6 GPU6: DAG 19%
2018.07.26:00:42:12.519: eths Eth: Send: {"id":5,"jsonrpc":"2.0","method":"eth_getWork","params":[]}
2018.07.26:00:42:12.546: eths Eth: Received: {"jsonrpc":"2.0","id":0,"result":["0xda40f35db43beeb3a7e6b66304068bbc0ca9ef3c25c4a8d68dad6a7de14835f0","0x0565d880e378b22250f35f260bac49983734114a9d338b7d7bacea1985c67dd4","0x000000006df37f675ef6eadf5ab9a2072d44268d97df837e6748956e5c6c2116"]}
2018.07.26:00:42:13.011: GPU5 GPU5: DAG 41%
2018.07.26:00:42:13.036: GPU6 GPU6: DAG 41%
2018.07.26:00:42:13.223: GPU3 GPU3: DAG 44%
2018.07.26:00:42:13.225: GPU2 GPU2: DAG 44%
2018.07.26:00:42:13.230: GPU4 GPU4: DAG 44%
2018.07.26:00:42:13.698: GPU1 CUDART error in CudaProgram.cu:188 : unspecified launch failure (4)
2018.07.26:00:42:13.700: GPU1 GPU1 initMiner error: unspecified launch failure
2018.07.26:00:42:13.711: GPU3 CUDART error in CudaProgram.cu:188 : unspecified launch failure (4)
2018.07.26:00:42:13.711: GPU3 GPU3 initMiner error: unspecified launch failure
2018.07.26:00:42:13.711: GPU4 CUDART error in CudaProgram.cu:188 : unspecified launch failure (4)
2018.07.26:00:42:13.711: GPU4 GPU4 initMiner error: unspecified launch failure
2018.07.26:00:42:13.785: GPU6 CUDART error in CudaProgram.cu:188 : unspecified launch failure (4)
2018.07.26:00:42:13.785: GPU6 GPU6 initMiner error: unspecified launch failure
2018.07.26:00:42:13.801: GPU2 CUDART error in CudaProgram.cu:188 : unspecified launch failure (4)
2018.07.26:00:42:13.801: GPU5 CUDART error in CudaProgram.cu:188 : unspecified launch failure (4)
2018.07.26:00:42:13.801: GPU2 GPU2 initMiner error: unspecified launch failure
2018.07.26:00:42:13.801: GPU5 GPU5 initMiner error: unspecified launch failure
I would mitigate this problem using the option -lidag: -lidag <n> Slow down DAG generation to avoid crashes when switching DAG epochs (0-3, default: 0 - fastest, 3 - slowest). You may specify this option per-GPU. Currently the option works only on AMD cards So try with "-lidag 2". From your above logs the problem with the gpus happened during the DAG generation. DAG generation is more intensive compared to normal hashing and when your OC is on the limit, it will crash the GPUs. |
|
|
|
GPU3: unable to get fan speed - Unknown Error (999),what is the problem, the driver 390.65,PhoenixMiner_3.0b?  ? Hi! and Welcome to the club. I've search a little bit on the internet and there are a lot of people with this error and you will have also the nvlddmkm error event id 14 if you look in logs on windows. Just a short history and why I think it's not the OC the principal issue because there are some with this issue without OC.... 1. before Phoenix I've run with Claymore (my brother still use Claymore 11.6 and we have the same GPU's - 1070 G1 Gaming - Micron memory) Short description on 1070 G1 Gaming OC Claymore 11.6 - TDP 60%, 0 CC, +800 Memory with Afterburner and it's working flawlessly for weeks without a crash - 226 Mh/s for 7 GPUs Phoenix Miner - TDP 60%, -150CC, +780 Memory with Afterburner and it's working like 2-5 days and then restart - 230.1 Mh/s for 7 GPUs I've lost days from my life to search about this issue and how to solve the problem ... If you look on nvidia forum it's full of people with this issue and they are not mining, no OC... 2. I have 2 RGIs, same setup and same hardware (TDP 60%, -150CC, +780 Memory, Phoenix Miner 2.9e) 1st RIG - windows 10 1709 (10.0.16299.400 and something..460/462... :?) / nvidia 391.35 - 230.1 Mh and no problem with error 999, working ok. On the second RIG was funny, windows 1803 and couple of drivers ... no way, restart after 20 min so I've choose to install again 1709, a version with January updates...just what I've found. I've tried to: - increase the virtual memory - different drivers (5 or 6 drivers.... :@) - something with replace of nvlddmkm.sy_ and use this command "EXPAND.EXE nvlddmkm.sy_ nvlddmkm.sys" (search on google) - TdrDelay in registry (also search on google) - bios update fo MB - disable SLI - prefer maximum power (nvidia inspector) - DSR factor x2 in nvidia control panel ... something what I've found on google for mining... I don't know if it's important or not but trust me...you will try everything just to get rid of that error  ))) At the end, after 2 days of pain...find on geforce forum something about driver 387.92 to be the solution to nvlddmkm.sys error. 2nd RIG - windows 10 1709 (10.0.16299.192) / driver 387.92 / same overclock settings (60%/-150/+780) - run for 10-11 hours (I was happy finally!!!!) and after that the error appear again, no restart after another 2-3 hours but I wanted to try another driver. Now, I'm on the same track but with and oldest driver (384.76), the driver from the Gigabyte website and install just the driver without hd audio, gf experinece, psysX, etc...and wait to see how it's working. With other drivers I have the error from the begging, after 5-10 min of running... I'm sure it's something with windows and nvidia drivers. What it's very strange ... it's ok on Claymore with +800 memory and working for weeks but I have this error with Phoenix even on +750... Another problem, on the other rig it's working very well with 391.35, I have a restart after 3-4 days but...it's ok, I can lower the OC but I don't have that error. I'm still searching how to solve this. Regards. I have been tuning my cards by increasing the mem clock. 650, 660... 880. Staying at one freq. for 1 day... At - 200,+880. About four hours into start two cards got the error above.. So decreasing my OC a bit down removed the issue completely. Haven't seen it since. |
|
|
|
Hi. I'm getting below error from time to time. As you can see, miner was running fine for more than 2 days (on 3.0a). My setup: 7 x 1070, power limit 62, core +140, memory +650. Can you please advise? 2018.06.03:02:58:27.401: eths Eth: New job #3732dc6c from eu1.ethermine.org:4444; diff: 4000MH
2018.06.03:02:58:27.585: main Eth speed: 223.248 MH/s, shares: 12366/0/0, time: 62:40
2018.06.03:02:58:27.585: main GPUs: 1: 31.880 MH/s (1722) 2: 31.892 MH/s (1845) 3: 31.899 MH/s (1776) 4: 31.885 MH/s (1756) 5: 31.894 MH/s (1742) 6: 31.911 MH/s (1756) 7: 31.887 MH/s (1769)
2018.06.03:02:58:31.106: GPU2 CUDA error in CudaProgram.cu:328 : an illegal memory access was encountered (700)
2018.06.03:02:58:31.112: GPU2 GPU2 search error: an illegal memory access was encountered
2018.06.03:02:58:31.147: GPU1 CUDA error in CudaProgram.cu:328 : an illegal memory access was encountered (700)
2018.06.03:02:58:31.147: GPU1 GPU1 search error: an illegal memory access was encountered
2018.06.03:02:58:31.147: GPU3 CUDA error in CudaProgram.cu:328 : an illegal memory access was encountered (700)
2018.06.03:02:58:31.147: GPU3 GPU3 search error: an illegal memory access was encountered
2018.06.03:02:58:31.147: GPU4 CUDA error in CudaProgram.cu:328 : an illegal memory access was encountered (700)
2018.06.03:02:58:31.147: GPU4 GPU4 search error: an illegal memory access was encountered
2018.06.03:02:58:31.147: GPU5 CUDA error in CudaProgram.cu:328 : an illegal memory access was encountered (700)
2018.06.03:02:58:31.147: GPU5 GPU5 search error: an illegal memory access was encountered
2018.06.03:02:58:31.148: GPU6 CUDA error in CudaProgram.cu:328 : an illegal memory access was encountered (700)
2018.06.03:02:58:31.148: GPU6 GPU6 search error: an illegal memory access was encountered
2018.06.03:02:58:31.148: GPU7 CUDA error in CudaProgram.cu:328 : an illegal memory access was encountered (700)
2018.06.03:02:58:31.148: GPU7 GPU7 search error: an illegal memory access was encountered
2018.06.03:02:58:32.055: wdog Thread(s) not responding. Restarting. Reduce core to -150 (minus 150) or even - 200 Increase mem gradually in 20 increments... I have it at +820. Hashing at 33.2 MH/s |
|
|
|
Noticed that one of my Nvidia GTX 1070 GPU hash rate is incorrectly reported:
Eth speed: 418.690 MH/s, shares: 16624/0/0, time: 45:38
GPUs: 1: 33.180 MH/s (1339) 2: 33.185 MH/s (1310) 3: 33.176 MH/s (1320)
4: 35.353 MH/s (1248) <<<---- This should be 316XX or something as it was in PH2.9e
5: 30.962 MH/s (1173) 6: 33.208 MH/s (1335) 7: 33.208 MH/s (1350) 8: 31.052 MH/s (1305) 9: 30.620 MH/s (1176) 10: 30.925 MH/s (1226) 11: 30.846 MH/s (1248) 12: 33.192 MH/s (1376) 13: 29.783 MH/s (1218)
The 2.9e reporting on this same card:
2018.06.01:00:43:43.799: main GPUs: 1: 33.198 MH/s (1365) 2: 33.172 MH/s (1328) 3: 33.186 MH/s (1341) 4: 31.680 MH/s (1262) 5: 30.925 MH/s (1254) 6: 33.216 MH/s (1269) 7: 33.214 MH/s (1312) 8: 30.800 MH/s (1269) 9: 30.471 MH/s (1254) 10: 30.884 MH/s (1252) 11: 30.835 MH/s (1222) 12: 33.198 MH/s (1295) 13: 29.603 MH/s (1135)
I have the same problem with my RX 580, It's 31.5mh/s in reality but it reports 39.7mh/s. As listed on the fixed list of 3.0c I confirm the high hash report is gone with PH 3.0c: GPUs: 1: 33.189 MH/s (4) 2: 33.187 MH/s (3) 3: 33.185 MH/s (2) 4: 31.678 MH/s (1) 5: 30.768 MH/s (1) 6: 33.217 MH/s (1) 7: 33.216 MH/s (3) 8: 30.825 MH/s (0) 9: 30.382 MH/s (0) 10: 30.745 MH/s (3) 11: 30.851 MH/s (1) 12: 33.182 MH/s (1) 13: 29.779 MH/s (2) May i please know how did u get 33 .2mh/s on RX 580? You may. The RX580 under my control are hashing at max 32.x MH/s. Do not have any in the 33 range. The rig mentioned above is a mix gpu rig as per next list: GPU1: GeForce GTX 1070 (pcie 1), CUDA cap. 6.1, 8 GB VRAM, 15 CUs GPU2: GeForce GTX 1070 (pcie 2), CUDA cap. 6.1, 8 GB VRAM, 15 CUs GPU3: GeForce GTX 1070 (pcie 6), CUDA cap. 6.1, 8 GB VRAM, 15 CUs GPU4: GeForce GTX 1070 (pcie  , CUDA cap. 6.1, 8 GB VRAM, 15 CUs GPU5: Radeon RX 580 Series (pcie 9), OpenCL 2.0, 8 GB VRAM, 36 CUs GPU6: GeForce GTX 1070 (pcie 10), CUDA cap. 6.1, 8 GB VRAM, 15 CUs GPU7: GeForce GTX 1070 (pcie 11), CUDA cap. 6.1, 8 GB VRAM, 15 CUs GPU8: Radeon RX 580 Series (pcie 13), OpenCL 2.0, 8 GB VRAM, 36 CUs GPU9: Radeon RX 580 Series (pcie 14), OpenCL 2.0, 8 GB VRAM, 36 CUs GPU10: Radeon RX 580 Series (pcie 15), OpenCL 2.0, 8 GB VRAM, 36 CUs GPU11: Radeon RX 580 Series (pcie 16), OpenCL 2.0, 8 GB VRAM, 36 CUs GPU12: GeForce GTX 1070 (pcie 17), CUDA cap. 6.1, 8 GB VRAM, 15 CUs GPU13: Radeon RX 580 Series (pcie 18), OpenCL 2.0, 8 GB VRAM, 36 CUs You are welcome to send me PM for further details on details of my configurations/monitoring tools and approaches. If you read through the forum, I did post my configurations above. Did some changes recently primarily focusing on temperature control. Two of five rigs are in my control by having fixed fan speeds which levels I change based on time of day (daily temperature fluctuations). I do keep my GPUs at 50-55oC. |
|
|
|
Noticed that one of my Nvidia GTX 1070 GPU hash rate is incorrectly reported:
Eth speed: 418.690 MH/s, shares: 16624/0/0, time: 45:38
GPUs: 1: 33.180 MH/s (1339) 2: 33.185 MH/s (1310) 3: 33.176 MH/s (1320)
4: 35.353 MH/s (1248) <<<---- This should be 316XX or something as it was in PH2.9e
5: 30.962 MH/s (1173) 6: 33.208 MH/s (1335) 7: 33.208 MH/s (1350) 8: 31.052 MH/s (1305) 9: 30.620 MH/s (1176) 10: 30.925 MH/s (1226) 11: 30.846 MH/s (1248) 12: 33.192 MH/s (1376) 13: 29.783 MH/s (1218)
The 2.9e reporting on this same card:
2018.06.01:00:43:43.799: main GPUs: 1: 33.198 MH/s (1365) 2: 33.172 MH/s (1328) 3: 33.186 MH/s (1341) 4: 31.680 MH/s (1262) 5: 30.925 MH/s (1254) 6: 33.216 MH/s (1269) 7: 33.214 MH/s (1312) 8: 30.800 MH/s (1269) 9: 30.471 MH/s (1254) 10: 30.884 MH/s (1252) 11: 30.835 MH/s (1222) 12: 33.198 MH/s (1295) 13: 29.603 MH/s (1135)
I have the same problem with my RX 580, It's 31.5mh/s in reality but it reports 39.7mh/s. As listed on the fixed list of 3.0c I confirm the high hash report is gone with PH 3.0c: GPUs: 1: 33.189 MH/s (4) 2: 33.187 MH/s (3) 3: 33.185 MH/s (2) 4: 31.678 MH/s (1) 5: 30.768 MH/s (1) 6: 33.217 MH/s (1) 7: 33.216 MH/s (3) 8: 30.825 MH/s (0) 9: 30.382 MH/s (0) 10: 30.745 MH/s (3) 11: 30.851 MH/s (1) 12: 33.182 MH/s (1) 13: 29.779 MH/s (2) |
|
|
|
|
Wanted to share the stats with the forum. These are the current stats of one of my rigs running on the PhoenixMiner 2.9e:
*** 1142:28 ***************************************************
Eth: Mining ETH on eu1.ethermine.org:4444 for 80:00
Available GPUs for mining:
GPU1: Radeon RX 580 Series (pcie 1), OpenCL 2.0, 8 GB VRAM, 36 CUs
GPU2: Radeon RX 580 Series (pcie 2), OpenCL 2.0, 8 GB VRAM, 36 CUs
GPU3: Radeon RX 580 Series (pcie 3), OpenCL 2.0, 8 GB VRAM, 36 CUs
GPU4: Radeon RX 580 Series (pcie 7), OpenCL 2.0, 8 GB VRAM, 36 CUs
GPU5: Radeon RX 580 Series (pcie 9), OpenCL 2.0, 8 GB VRAM, 36 CUs
GPU6: Radeon RX 580 Series (pcie 10), OpenCL 2.0, 8 GB VRAM, 36 CUs
GPU7: Radeon RX 580 Series (pcie 12), OpenCL 2.0, 8 GB VRAM, 36 CUs
GPU8: Radeon RX 580 Series (pcie 13), OpenCL 2.0, 8 GB VRAM, 36 CUs
GPU9: Radeon RX 580 Series (pcie 15), OpenCL 2.0, 8 GB VRAM, 36 CUs
GPU10: Radeon RX 580 Series (pcie 16), OpenCL 2.0, 8 GB VRAM, 36 CUs
GPU11: Radeon RX 580 Series (pcie 17), OpenCL 2.0, 8 GB VRAM, 36 CUs
GPU12: Radeon RX 580 Series (pcie 18), OpenCL 2.0, 8 GB VRAM, 36 CUs
GPU13: Radeon RX 580 Series (pcie 19), OpenCL 2.0, 8 GB VRAM, 36 CUs
GPU1: 54C 92%, GPU2: 57C 86%, GPU3: 57C 85%, GPU4: 56C 85%, GPU5: 54C 79%, GPU6: 52C 44%, GPU7: 52C 41%, GPU8: 58C 86%, GPU9: 54C 84%, GPU10: 54C 99%, GPU11: 52C 43%, GPU12: 62C 81%, GPU13: 49C 0%
Eth: Accepted shares 407093 (40 stales), rejected shares 3 (0 stales)
Eth: Incorrect shares 169 (0.04%), est. stales percentage 0.01%
Eth: Maximum difficulty of found share: 12954.2 TH (!!!)
Eth: Average speed (5 min): 407.232 MH/s
Eth: Effective speed: 395.92 MH/s; at pool: 395.92 MH/s
PhoenixMiner: If you ever have a moment of doubt about your work... get back to this post. THANKS!
|
|
|
|
|
Noticed that one of my Nvidia GTX 1070 GPU hash rate is incorrectly reported:
Eth speed: 418.690 MH/s, shares: 16624/0/0, time: 45:38
GPUs: 1: 33.180 MH/s (1339) 2: 33.185 MH/s (1310) 3: 33.176 MH/s (1320)
4: 35.353 MH/s (1248) <<<---- This should be 316XX or something as it was in PH2.9e
5: 30.962 MH/s (1173) 6: 33.208 MH/s (1335) 7: 33.208 MH/s (1350) 8: 31.052 MH/s (1305) 9: 30.620 MH/s (1176) 10: 30.925 MH/s (1226) 11: 30.846 MH/s (1248) 12: 33.192 MH/s (1376) 13: 29.783 MH/s (1218)
The 2.9e reporting on this same card:
2018.06.01:00:43:43.799: main GPUs: 1: 33.198 MH/s (1365) 2: 33.172 MH/s (1328) 3: 33.186 MH/s (1341) 4: 31.680 MH/s (1262) 5: 30.925 MH/s (1254) 6: 33.216 MH/s (1269) 7: 33.214 MH/s (1312) 8: 30.800 MH/s (1269) 9: 30.471 MH/s (1254) 10: 30.884 MH/s (1252) 11: 30.835 MH/s (1222) 12: 33.198 MH/s (1295) 13: 29.603 MH/s (1135)
|
|
|
|
|
A hint for nvidia GTX 1070 overclocking.
Currently running with the following OC settings:
On most GPUs with: core: -200, mem:+900, fixed fan speed, fixed power target as per next cmd OC tool:
start nvidiaInspector.exe -setBaseClockOffset:0,0,-200 -setMemoryClockOffset:0,0,880 -setPowerTarget:0,60 -setTempTarget:0,1,65 -setFanSpeed:0,45
start nvidiaInspector.exe -setBaseClockOffset:1,0,-200 -setMemoryClockOffset:1,0,880 -setPowerTarget:1,60 -setTempTarget:1,1,65 -setFanSpeed:1,60
start nvidiaInspector.exe -setBaseClockOffset:2,0,-200 -setMemoryClockOffset:2,0,900 -setPowerTarget:2,60 -setTempTarget:2,1,65 -setFanSpeed:2,45
start nvidiaInspector.exe -setBaseClockOffset:3,0,-200 -setMemoryClockOffset:3,0,625 -setPowerTarget:3,55 -setTempTarget:3,1,65 -setFanSpeed:3,40
start nvidiaInspector.exe -setBaseClockOffset:4,0,-200 -setMemoryClockOffset:4,0,900 -setPowerTarget:4,60 -setTempTarget:4,1,65 -setFanSpeed:4,45
start nvidiaInspector.exe -setBaseClockOffset:5,0,-200 -setMemoryClockOffset:5,0,900 -setPowerTarget:5,60 -setTempTarget:5,1,65 -setFanSpeed:5,60
start nvidiaInspector.exe -setBaseClockOffset:6,0,-200 -setMemoryClockOffset:6,0,900 -setPowerTarget:6,60 -setTempTarget:6,1,65 -setFanSpeed:6,45
When atempting to start the miner, it will fail during the DAG when using the above settings.
So this is what I do:
Step 1: Setup the OC with core: -200, mem +800 as per above.
Step 2: Start the PhoenixMiner and wait for hashing to start (after loading the DAGs).
Step 3: After few minutes apply the OC settings with -200, mem +900.
These are current results:
Eth speed: 417.699 MH/s, shares: 335/0/0, time: 0:58
GPUs: 1: 33.641 MH/s (25) 2: 33.642 MH/s (21) 3: 33.804 MH/s (30) 4: 31.308 MH/s (28) 5: 30.930 MH/s (24) 6: 33.826 MH/s (27) 7: 33.844 MH/s (30) 8: 30.963 MH/s (22) 9: 30.462 MH/s (26) 10: 30.885 MH/s (20) 11: 30.837 MH/s (24) 12: 33.808 MH/s (28) 13: 29.749 MH/s (30)
The GPUs 5,8,9,10,11 and 13 are AMD RX580.
Still in process of increasing the mem clocks but leaving a system for 24h observation between each change to confirm stability.
Happy mining!
|
|
|
|
so how can we make the fans here to work the same as claymore? any ideas? if i set -tt 60 and -fanmax 90 in claymore, as long the temperature is higher than -tt 60, the -fanmax 90 will always be at 90%, if temperature is 50c then the fan in claymore is around 0% and jumps to 50% and then 0% again, so how this miner can work the same?
Actually it does work like that. Both Phoenix and Claymore have a temperature management matrix (or a function) that translates current temperature/target temperature, min/max speeds into a targeted fan speed. Addition of the formula/matrix would enrich the documentation, but on the other hand this is "proprietary" part of the code that is not likely to be revealed. PH correct me if I am wrong. If you wish you could take over the control of the temperature and fans speed on your own with the OC tools. I am taking control at 2 of my rigs as both GPU self management and PhoenixMiner Tempeature management fail to keep the control over temperature in optimal way (in this particular setups in my opinion). On the nvidia, I am doing this as part of the OC (setting fans on fixed spin rate) using nvidiainspector. start C:\dev\Tools\Guru3D.com\nvidiaInspector.exe -setBaseClockOffset:0,0,-200 -setMemoryClockOffset:0,0,795 -setPowerTarget:0,59 -setTempTarget:0,1,65 -setFanSpeed:0,45 On AMD GPUs I am using overdrive5_64.exe overdrive5_64.exe -a 1 -F 45 One more thing. If you have multiple GPUs, then -tt 60 might not be right. Try -tt 60,60,60 ... listing a target temperature for each GPU rather than just one. |
|
|
|
Hi
how to solve this
I`m using PhoenixMiner 2.9e and have this error every 10 min
2018.05.17:19:27:32.267: eths Eth: Unable to read pool response: The semaphore timeout period has expired
2018.05.17:19:27:32.267: eths Eth: Reconnecting in 20 seconds...
This would be a result of unstable internet connection. Make sure your router/access point is not rebooting periodically and your PC has a stable internet connection. The miner connects to the pool and keeps a connection alive at all times. When your network drops the connection is lost and miner will not really reconnect but establish a new connection. In some rare cases it could also be an ISP problem with the upstream network. Check the event viewer, these should be a clear message from Windows indicating a connection drop. |
|
|
|
how it works
-gpus <123 ..n> Use only the specified GPUs
write
-gpus <1235>
and "file not found"
Use as: -gpus 1235 It will use only cards 1, 2, 3 and 5 and will ignore all other cards. e..g. card 4, 6, ... The "<>" stands as a standard placeholder indicating a mandatory parameter/option. For example "[]" would indicate an optional parameter. |
|
|
|
I've been using claymore for my RX X80s for over a year now. Decided to give phoenix a go...and I'm damn happy I did: slight improvement in hashrate at the same clocks and power and significant reduction in stale shares! I've been suffering from 5-15% stales (ethermine.org) since Byzantium fork in 2017. With phoenix I have <1% stales.
Great job, man.
Retraction of my previous statement: number of stale shares is marginally lower than claymore's. During the first few hours of running phoenix I indeed had <1% of stales; number increased with time though and as of now I'm back to 5-10% stales. Bad job, man! Your 5-10% stale share is arguably bad. With the PH 2.9e, migrated from Claymore 11.5 my stale share rate is slightly higher than on Claymore yet still in the range of 1-3% - varies from day to day. Stale share is sensitive not only to the miner code but also on the quality of your network speed and latency. Shares are accepted in 40-42ms in my could you please explain to a noob (me) the difference between network speed and network latency? You will get the best answer if you Google: network latency definition. |
|
|
|
I've been using claymore for my RX X80s for over a year now. Decided to give phoenix a go...and I'm damn happy I did: slight improvement in hashrate at the same clocks and power and significant reduction in stale shares! I've been suffering from 5-15% stales (ethermine.org) since Byzantium fork in 2017. With phoenix I have <1% stales.
Great job, man.
Retraction of my previous statement: number of stale shares is marginally lower than claymore's. During the first few hours of running phoenix I indeed had <1% of stales; number increased with time though and as of now I'm back to 5-10% stales. Bad job, man! Your 5-10% stale share is arguably bad. With the PH 2.9e, migrated from Claymore 11.5 my stale share rate is slightly higher than on Claymore yet still in the range of 1-3% - varies from day to day. Stale share is sensitive not only to the miner code but also on the quality of your network speed and latency. Shares are accepted in 40-42ms in my case. What is yours? What is your ping to your pool? Here is what I have: C:\Program Files\NVIDIA Corporation\NVSMI>ping eu1.ethermine.org Pinging eu1.ethermine.org [46.105.121.53] with 32 bytes of data: Reply from 46.105.121.53: bytes=32 time=59ms TTL=54 Reply from 46.105.121.53: bytes=32 time=42ms TTL=54 Reply from 46.105.121.53: bytes=32 time=41ms TTL=54 Reply from 46.105.121.53: bytes=32 time=41ms TTL=54 Ping statistics for 46.105.121.53: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 41ms, Maximum = 59ms, Average = 45ms Connect a rig to network using wired connection (avoid wireless at any cost). Make sure you are not using switches/APs that introduce unexpected latency. |
|
|
|
For now i have never problem with PhoenixMiner. Now i have a problem with this: I using PM 2.9e2018.05.13:10:26:26.668: GPU2 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.05.13:10:26:26.668: GPU2 GPU2 search error: unspecified launch failure
2018.05.13:10:26:26.678: GPU5 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.05.13:10:26:26.678: GPU5 GPU5 search error: unspecified launch failure
2018.05.13:10:26:26.694: GPU3 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.05.13:10:26:26.694: GPU3 GPU3 search error: unspecified launch failure
2018.05.13:10:26:26.709: wdog Thread(s) not responding. Restarting.
2018.05.13:10:26:26.725: GPU6 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.05.13:10:26:26.725: GPU6 GPU6 search error: unspecified launch failure
2018.05.13:10:26:26.725: GPU1 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.05.13:10:26:26.725: GPU1 GPU1 search error: unspecified launch failure
2018.05.13:10:26:26.756: GPU4 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
My settings are same all time. I have gtx 1070 (8gb) gpus. How to solve this problem any idea? try lowering the GPU2 overclock settings a bit, looks like that is the card that is causing the issue Ok, tnx for advice. I’ll try this I have also had the same problem for a couple of days, have you solved it and what did you like to report? I got these same errors when OC-ing my 1070 to the limits. Follow next steps to resolve this problem - worked 100% in my case: - Reduce the OC settings for the nvidia cards
- Reinstall nvidia drivers
- Run Phoenix ... it will for sure work again
I got this problem twice; In both cases when searching for maximum stable mem freq I can push the 1070 gpus. Currently running stable at: Core: -200 (minus 200) Mem: 765 Power Limit: 59 Hashing: 32.770 MH/s To tune, I am using nvidia Inspector as it allows me to easily tune individual gpus. I have this line "call nvidia-tune.bat" in start.bat before the PhoenixMiner.exe line: ::nvidia-tune.bat file content: 7 nvidia cards 0..7 -
:: Note1: card 3 - it is stable at max 625 mem clock - any atampt to go higher will produce errors in minutes after the mining starts
:: Note2: The fans are set to run at constant speed - I have found these values (different for each fan) that keep my cards at around 50-55oC, depending on the ambient temperature
start C:\dev\Tools\Guru3D.com\nvidiaInspector.exe -setBaseClockOffset:0,0,-200 -setMemoryClockOffset:0,0,765 -setPowerTarget:0,59 -setTempTarget:0,1,65 -setFanSpeed:0,45
start C:\dev\Tools\Guru3D.com\nvidiaInspector.exe -setBaseClockOffset:1,0,-200 -setMemoryClockOffset:1,0,765 -setPowerTarget:1,59 -setTempTarget:1,1,65 -setFanSpeed:1,60
start C:\dev\Tools\Guru3D.com\nvidiaInspector.exe -setBaseClockOffset:2,0,-200 -setMemoryClockOffset:2,0,765 -setPowerTarget:2,59 -setTempTarget:2,1,65 -setFanSpeed:2,45
start C:\dev\Tools\Guru3D.com\nvidiaInspector.exe -setBaseClockOffset:3,0,-200 -setMemoryClockOffset:3,0,625 -setPowerTarget:3,55 -setTempTarget:3,1,65 -setFanSpeed:3,40
start C:\dev\Tools\Guru3D.com\nvidiaInspector.exe -setBaseClockOffset:4,0,-200 -setMemoryClockOffset:4,0,765 -setPowerTarget:4,59 -setTempTarget:4,1,65 -setFanSpeed:4,45
start C:\dev\Tools\Guru3D.com\nvidiaInspector.exe -setBaseClockOffset:5,0,-200 -setMemoryClockOffset:5,0,765 -setPowerTarget:5,59 -setTempTarget:5,1,65 -setFanSpeed:5,60
start C:\dev\Tools\Guru3D.com\nvidiaInspector.exe -setBaseClockOffset:6,0,-200 -setMemoryClockOffset:6,0,765 -setPowerTarget:6,59 -setTempTarget:6,1,65 -setFanSpeed:6,45
In my experience the nvidia is not gracefully handling errors when it comes to errors from OC. In best scenario (when slightly overclocked), PhoenixMiner will restart as expected. In worst case, when OC is too high, nvidia driver/configuration gets corrupted and the error as above ends any attempt to mine with the card. The reboot, restart nor cold restart will not make it go away. Only the driver reinstall fixes the problem. |
|
|
|
Here we go again: Miner: 7*1070 + 5*580 So on Claymore v. 11.6 i use This bat file: setx GPU_FORCE_64BIT_PTR 0
setx GPU_MAX_HEAP_SIZE 100
setx GPU_USE_SYNC_OBJECTS 1
setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_SINGLE_ALLOC_PERCENT 100
Miners\Claymore_Dual_Ethereum_v10.2\EthDcrMiner64.exe -epool eu1.ethermine.org:4444 -ewal walletaddress.rigcozinha -epsw x -allpools 1 -mport 4444 -cclock 1150 -mclock 2225 -cvddc 850 -mvddc 850 MSI Afterburnner 4.5.0: Core: 0 Mem: +715 PL: 65% Power Consumption: 1750w PhoniexMiner config bat file: REM
REM Example bat file for starting PhoenixMiner.exe to mine ETH
REM
setx GPU_FORCE_64BIT_PTR 0
setx GPU_MAX_HEAP_SIZE 100
setx GPU_USE_SYNC_OBJECTS 1
setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_SINGLE_ALLOC_PERCENT 100
PhoenixMiner.exe -pool eu1.ethermine.org:4444 -pool2 us1.ethermine.org:4444 -wal walletaddress.RIGcozinha -proto 3 -cclock 1150 -mclock 2225 -cvddc 850 -mvddc 850 -log 0 Afterburnner config are the same Power Consumption: 2150w Whats the problem? I like verter PM, but With This difference i cannot keep using. After some tests i realized that the extra consumption is on AMD cards. So for now... the solution i'm using is Claymore for AMD cards, and PM for Nvidia cards. I dont know why but PM is not executing the "in BOLD" command line: PhoenixMiner.exe -pool eu1.ethermine.org:4444 -pool2 us1.ethermine.org:4444 -wal walletaddress.RIGcozinha -proto 3 -cclock 1150 -mclock 2225 -cvddc 850 -mvddc 850 -log 0 Use hwinfo64 to check actual values the gpus are running at. For PhoenixMiner specify the voltage for each card so - cvddc 850,850,850,... -mvdcc 850,850,850... Same for frequencies. I have multiple rigs configured this way on -18.x.x drivers perform as expected. |
|
|
|
I need a good working start.bat command file, which switches from one wallet to another wallet with a time limit
i used this bat this works not so good.
Define the 'not so good'. Specify your requirements. switching from wallet 1 to wallet 2, a lot of loss of time and of course the loss of time for startup phoenixminer, must be an easier way for this, without the waiting times and the start-up time of the Miner itself. As advised in the previous replies there are so much simpler solutions utilizing wallet transfer of the mined eth... However if you insist on a complex solution then I can program solution utilizing the remote management API and epools.txt. Send a PM message to get my full proposal for the not free solution. |
|
|
|
I got massage "GPU4 CUDA error in CudaProgram.cu:264 : the launch timed out and was terminated (702)", and then the miner was hanged. What is this mean?
It means two things: your gpu is overclocked - reduce memory frequency and secondly the miner code insufficiently handles that part of the code interfacing with the cuda API or the CUDA driver itself is buggy. In my opinion and experience the driver is to blame. |
|
|
|
I need a good working start.bat command file, which switches from one wallet to another wallet with a time limit i used this bat this works not so good. setx GPU_FORCE_64BIT_PTR 0
setx GPU_MAX_HEAP_SIZE 100
setx GPU_USE_SYNC_OBJECTS 1
setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_SINGLE_ALLOC_PERCENT 100
:wallet1
echo Starting Mining Process for first wallet
:: Update the "C:\Mining\PhoenixMiner" with the actual full path of your miner location
start "Phoenix Miner for Wallet #1" /D "C:\Mining\PhoenixMiner" PhoenixMiner.exe -pool us2.ethermine.org:4444 -pool2 us1.ethermine.org:14444 -wal <wallet.rigname> -gpus 1234567 -pass x -logfile *
timeout /t 60
taskkill /im PhoenixMiner.exe /f /t
goto wallet2
:wallet2
echo Starting Mining Process for second wallet
:: Update the "C:\Mining\PhoenixMiner" with the actual full path of your miner location
start "Phoenix Miner for Wallet #2" /D "C:\Mining\PhoenixMiner" PhoenixMiner.exe -pool us2.ethermine.org:4444 -pool2 us1.ethermine.org:14444 -wal <wallet.rigname> -gpus 1234567 -pass x -logfile *
timeout /t 60
taskkill /im PhoenixMiner.exe /f /t
goto wallet1 Define the 'not so good'. Specify your requirements. |
|
|
|
|
