Hi, I salute you all!
This is my first post here, I have used until now Claymore 11.9 to mine ETH, with all OC and power limit comands wrotten on
.bat file by example:
mclock +780,+750,+780,+750,+780,+750,+780,+750 -powlim -24,-38,-24,-39,-24,-39,-24,-27 and in last period of time, I got alot of
Open Cl errors.
With those settings for memory OC and powerlimit used, as described above, it worked well for weeks, there was used 3x1080Ti and 5xGTX1070 in the rig but in the last period when I replaced one GTX1070 with another GTX1080Ti, to be 4x1080Ti and 4x1070 on that rig, it freeze entire rig after OpenCl error, and the only one solution was to reset rig.
First time I was suspected that forth 1080Ti is bad, but the card is brand new.
I have tested that card on a friend's rig, it works perfect.
I tried to lower mem clocks, also I have managed to run rig at standard settings for all videocards, no power limit, no mem OC,
all stock, the same OpenCl errors at random times period, maximum 10 hours and rig was freezed with OpenCl error.
So OC settings was not the blame for freezing rig.
If I get out one videocard from rig, no matters if is 1080Ti or 1070, (I have tried to get out random 1080Ti and random 1070 card)
just to be only 7 cards on that rig, everything was perfect for days, no any error.
I was out of solutions, the only one was to use just 7 cards on that rig or just 3 1080Ti mixed with 5x1070, the rig freezes with 4x1080Ti and 4x1070...
No power problems as power supplies sums 2500 watts, 2x Seasonic, 1200 and 1300 watts, 4 cards (2x1080Ti and 2x1070) on each power supply, so enough headroom for each power supply.
I have tried PhoenixMiner 4.2c,and all my problems has disappeared!
It works entire days without get any error with all 8 cards, 4x1080Ti and 4x1070!
https://i.postimg.cc/hGL5jFtq/8-cards.jpgGreat mining software!!!!!!!
I tried to use all OC and powerlimit commands on .bat file but doesn't work...
Finally I got to use MSI Afterburner, to manage OC memory and powerlimit too for each card individually, it works great!
Now, my question is,
it will implement in newer versions, options for mem OC and powerlimit for Nvidia cards too?
I have read, those settings wrotten on .bat file, works now just for AMD cards.
Thank you!
Yes, currently these settings are only supported on AMD cards but we are working on supporting them for Nvidia cards too. We hope that this feature will be ready for the next release of PhoenixMIner.
Available GPUs for mining:
GPU1: Radeon RX 580 Series (pcie 1), OpenCL 1.2, 8 GB VRAM, 36 CUs
GPU2: Radeon RX 580 Series (pcie 3), OpenCL 1.2, 8 GB VRAM, 36 CUs
GPU3: Radeon RX 580 Series (pcie 4), OpenCL 1.2, 8 GB VRAM, 36 CUs
GPU4: Radeon RX 580 Series (pcie 5), OpenCL 1.2, 8 GB VRAM, 36 CUs
GPU5: Radeon RX 580 Series (pcie 6), OpenCL 1.2, 8 GB VRAM, 36 CUs
GPU6: Radeon RX 580 Series (pcie 7), OpenCL 1.2, 8 GB VRAM, 36 CUs
GPU1: 43C 65%, GPU2: 47C 65%, GPU3: 47C 65%, GPU4: 45C 65%, GPU5: 47C 65%, GPU6: 50C 65%
Current -gt 71,71,71,71,71,71
Eth: Accepted shares 9095 (3 stales), rejected shares 282 (0 stales)
Eth: Incorrect shares 0 (0.00%), est. stales percentage 0.03%
Eth: Maximum difficulty of found share: 11.4 TH (!!!)
Eth: Average speed (5 min): 0.000 MH/s
Eth: Effective speed: 53.04 MH/s; at pool: 51.45 MH/s
Eth speed: 0.000 MH/s, shares: 9095/282/0, time: 49:06
GPUs: 1: 0.000 MH/s (1541) 2: 0.000 MH/s (1541) 3: 0.000 MH/s (1600) 4: 0.000 MH/s (1512) 5: 0.000 MH/s (1580) 6: 0.000 MH/s (1603)
I don't know why but at some point phoenix miner starts to show 0 hash rate, but it mines correctly on the pool, the share number increases with 0 hash.
I'm using ubuntu 18.04.
kernel: 4.20.6-042006-generic #201901310331 SMP Thu Jan 31 08:33:33 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
amd driver: amdgpu18.40-676022
Phoenix Miner 4.1c
At the fastest this issue happens after 15 hours of mining, but It popped up even after 4 days.
I also notice this in dmesg, but not every time, sometimes this error is there sometimes is not
kern :info : [Sun Apr 21 10:41:04 2019] traps: phoenix[9096] trap divide error ip:550ac1 sp:7ffdb110f230 error:0 in PhoenixMiner[400000+740000]
kern :info : [Mon Apr 22 09:23:49 2019] traps: phoenix[20905] trap divide error ip:550ac1 sp:7ffe62664970 error:0 in PhoenixMiner[400000+740000]
Thank you for reporting this. Please try to use the latest version (PhoenixMiner 4.2c) and see if it solves the issue. If the problem still remains, please send us an excerpt of the log around the moment the hashrate starts to be reported as 0. A possible reason for this are large changes in the system clock (e.g. hours), especially if the clock is adjusted backwards.
Hi everybody
, it is ETH mining with 6 x 1050 Ti gaming MSI ... I have a question that when I start PhoenixMiner 4.2 it shows me extreme hashrates at the start of the run, for example 26 MH / s (1050Ti) -
https://i.postimg.cc/7ZfBrcsP/1050ti-bevadult-XD.jpg... Don't you know what it can be?
or whether it could be achieved, not to drop it to a normal value of about 15 MH / s? :-) Thanks for help
Sorry to disappoint you but these aren't real. It is just an artifact of the way Nvidia drivers report the kernel dispatches as "finished" while they actually aren't finished yet. After the driver kernel dispatch queue fills up, the driver starts to report times that are more in line with the actual kernel dispatch execution times. There is a way to get the exact numbers sooner but it impacts the hashrate negatively, so we decided to leave it as it is. After a few minutes the hashrates get accurate anyway. If you want to test different settings quickly, you can try the
-bench 260 command-line option, which will report accurate hashrates faster because it doesn't change the job as often as the pools do.
Does Phoenix 4.2c support 19.4.3 AMD drivers like 19.4.1? On 19.4.1 miner shows 19.3/2 and works on full speed.
Anyone tried 19.4.3 allready?
We haven't tested with 19.4.3 yet - it is possible that the OpenCL drivers aren't changed and are still supported by PhoenixMiner 4.2c with the driver-specific optimizations as many of the driver releases are more for game-related issues.
Anyone else running into problem with multiple Radeon vii's? When I have 1 card running it seems to be working fine but as soon as I go to 2+ GPU1 hash rate is super low or non existent.
2019.04.26:01:55:29.437: main Phoenix Miner 4.2c Windows/msvc - Release build
2019.04.26:01:55:29.437: main Cmd line:
2019.04.26:01:55:29.437: main config.txt: -pool eu1.ethermine.org:4444 -pool2 us1.ethermine.org:4444 -wal XXXXXX -proto 3 -gser 1 -gt 59
2019.04.26:01:55:29.437: main No CUDA driver found
2019.04.26:01:55:30.028: main OpenCL driver version: 19.2/3
2019.04.26:01:55:30.028: main Available GPUs for mining:
2019.04.26:01:55:30.028: main GPU1: AMD Radeon VII (pcie 11), OpenCL 2.0, 16 GB VRAM, 60 CUs
2019.04.26:01:55:30.028: main GPU2: AMD Radeon VII (pcie 67), OpenCL 2.0, 16 GB VRAM, 60 CUs
2019.04.26:01:55:30.038: main ADL library initialized
2019.04.26:01:55:30.550: main Eth: Loading pools from epools.txt
2019.04.26:01:55:30.550: main Eth: the pool list contains 4 pools (2 from command-line)
2019.04.26:01:55:30.550: main Eth: primary pool: eu1.ethermine.org:4444
2019.04.26:01:55:30.550: main Starting GPU mining
2019.04.26:01:55:30.550: main Matched GPU1 to ADL adapter index 8 (method 1)
2019.04.26:01:55:30.560: main GPU1: Created ADL monitor for adapter 8; overdrive version: 8
2019.04.26:01:55:30.560: main GPU1: using AMD driver ver 19.4.1
2019.04.26:01:55:30.560: main Matched GPU2 to ADL adapter index 0 (method 1)
2019.04.26:01:55:30.568: main GPU2: Created ADL monitor for adapter 0; overdrive version: 8
2019.04.26:01:55:30.568: main GPU2: using AMD driver ver 19.4.1
2019.04.26:01:55:30.569: wdog Starting watchdog thread
2019.04.26:01:55:30.569: main Eth: Connecting to ethash pool eu1.ethermine.org:4444 (proto: QtMiner)
2019.04.26:01:55:30.586: eths Eth: Connected to ethash pool eu1.ethermine.org:4444 (172.65.207.106)
2019.04.26:01:55:30.586: eths Eth: Send: {"id":1,"jsonrpc":"2.0","method":"eth_login","params":["0x16d0beb9a27d6f063f0ab24874843fe454f2ddab"]}
2019.04.26:01:55:30.626: eths Eth: Received: {"id":1,"jsonrpc":"2.0","result":true}
2019.04.26:01:55:30.626: eths Eth: Send: {"id":5,"jsonrpc":"2.0","method":"eth_getWork","params":[]}
2019.04.26:01:55:30.654: eths Eth: Received: {"id":0,"jsonrpc":"2.0","result":["0xbda94e96a118b0ced9d4929daf39df6885295f4c618fff5b4e11196a98da4a7a","0x96ea102ff70653f07bc76a20e40449c1f5f4335aca6408a7403c9d987f6bf44f","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x749893"]}
2019.04.26:01:55:30.654: eths Eth: New job #bda94e96 from eu1.ethermine.org:4444; diff: 4000MH
2019.04.26:01:55:30.655: GPU1 GPU1: Starting up... (0)
2019.04.26:01:55:30.655: GPU1 GPU1: Generating ethash light cache for epoch #254
2019.04.26:01:55:30.771: main Listening for CDM remote manager at port 3333 in read-only mode
2019.04.26:01:55:30.771: main GPU1: 55C, GPU2: 59C
2019.04.26:01:55:31.659: GPU2 GPU2: Starting up... (0)
2019.04.26:01:55:32.623: GPU1 Light cache generated in 2.0 s (24.3 MB/s)
2019.04.26:01:55:32.896: GPU1 GPU1: Allocating DAG (3.00) GB; good for epoch up to #256
2019.04.26:01:55:32.904: GPU1 GPU1: Allocating light cache buffer (48.0) MB; good for epoch up to #256
2019.04.26:01:55:32.918: GPU1 GPU1: Generating DAG for epoch #254
2019.04.26:01:55:33.177: GPU2 GPU2: Allocating DAG (3.00) GB; good for epoch up to #256
2019.04.26:01:55:33.187: GPU2 GPU2: Allocating light cache buffer (48.0) MB; good for epoch up to #256
2019.04.26:01:55:33.205: GPU2 GPU2: Generating DAG for epoch #254
2019.04.26:01:55:33.484: eths Eth: Received: {"id":0,"jsonrpc":"2.0","result":["0xa4ade5956fddc8e3079543cdedb0b779c2c3c2571813a2718669e700a4c77062","0x96ea102ff70653f07bc76a20e40449c1f5f4335aca6408a7403c9d987f6bf44f","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x749893"]}
2019.04.26:01:55:33.484: eths Eth: New job #a4ade595 from eu1.ethermine.org:4444; diff: 4000MH
2019.04.26:01:55:34.731: GPU2 GPU2: DAG 94%
2019.04.26:01:55:34.802: GPU2 GPU2: DAG generated in 1.6 s (1913.6 MB/s)
2019.04.26:01:55:34.803: GPU2 GPU2: Using Ethash OCL kernels (gfx906; -clkernel 1)
2019.04.26:01:55:34.847: GPU1 GPU1: DAG 12%
2019.04.26:01:55:35.594: main Eth speed: 89.339 MH/s, shares: 0/0/0, time: 0:00
2019.04.26:01:55:35.594: main GPUs: 1: 0.000 MH/s (0) 2: 89.339 MH/s (0)
2019.04.26:01:55:36.481: GPU1 GPU1: DAG 24%
2019.04.26:01:55:37.414: eths Eth: Received: {"id":0,"jsonrpc":"2.0","result":["0x1cf62721c05bc89c9b623286678ff4e1378baac8811609af8f09a4ab640ded02","0x96ea102ff70653f07bc76a20e40449c1f5f4335aca6408a7403c9d987f6bf44f","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x749893"]}
2019.04.26:01:55:37.414: eths Eth: New job #1cf62721 from eu1.ethermine.org:4444; diff: 4000MH
2019.04.26:01:55:38.030: eths Eth: Received: {"id":0,"jsonrpc":"2.0","result":["0x454f8452dff1fd06d6150a31a54d431d7e57fd8b99f5c2c1f3a7b99a1e55cdec","0x96ea102ff70653f07bc76a20e40449c1f5f4335aca6408a7403c9d987f6bf44f","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x749894"]}
2019.04.26:01:55:38.030: eths Eth: New job #454f8452 from eu1.ethermine.org:4444; diff: 4000MH
2019.04.26:01:55:38.115: GPU1 GPU1: DAG 35%
2019.04.26:01:55:38.330: eths Eth: Received: {"id":0,"jsonrpc":"2.0","result":["0xe3c1ebfce2ab8e34b9b2a0ab0f37fb211623fa7e92c05cf4725d811d7bd9ba41","0x96ea102ff70653f07bc76a20e40449c1f5f4335aca6408a7403c9d987f6bf44f","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x749894"]}
2019.04.26:01:55:38.331: eths Eth: New job #e3c1ebfc from eu1.ethermine.org:4444; diff: 4000MH
2019.04.26:01:55:39.749: GPU1 GPU1: DAG 47%
2019.04.26:01:55:40.587: eths Eth: Send: {"id":5,"jsonrpc":"2.0","method":"eth_getWork","params":[]}
2019.04.26:01:55:40.614: eths Eth: Received: {"id":0,"jsonrpc":"2.0","result":["0xe3c1ebfce2ab8e34b9b2a0ab0f37fb211623fa7e92c05cf4725d811d7bd9ba41","0x96ea102ff70653f07bc76a20e40449c1f5f4335aca6408a7403c9d987f6bf44f","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x749894"]}
2019.04.26:01:55:40.616: main Eth speed: 89.944 MH/s, shares: 0/0/0, time: 0:00
2019.04.26:01:55:40.616: main GPUs: 1: 0.000 MH/s (0) 2: 89.944 MH/s (0)
2019.04.26:01:55:41.382: GPU1 GPU1: DAG 59%
2019.04.26:01:55:42.310: eths Eth: Received: {"id":0,"jsonrpc":"2.0","result":["0x0bf5c6fc1492a59dbdeb1b7881eb1869928d9d12883c820e09d23c1b20387fed","0x96ea102ff70653f07bc76a20e40449c1f5f4335aca6408a7403c9d987f6bf44f","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x749894"]}
2019.04.26:01:55:42.310: eths Eth: New job #0bf5c6fc from eu1.ethermine.org:4444; diff: 4000MH
2019.04.26:01:55:42.436: eths Eth: Received: {"id":0,"jsonrpc":"2.0","result":["0x8bc1fb170998d8439ed89417849ae86a58d1d359dd3f045fd8281f27c5d104a8","0x96ea102ff70653f07bc76a20e40449c1f5f4335aca6408a7403c9d987f6bf44f","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x749895"]}
2019.04.26:01:55:42.436: eths Eth: New job #8bc1fb17 from eu1.ethermine.org:4444; diff: 4000MH
2019.04.26:01:55:42.508: eths Eth: Received: {"id":0,"jsonrpc":"2.0","result":["0x5c90ef44024d19033b8d6cfa95532f502b97416b979d1bf4ba20ad21dfe84cb7","0x96ea102ff70653f07bc76a20e40449c1f5f4335aca6408a7403c9d987f6bf44f","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x749895"]}
2019.04.26:01:55:42.508: eths Eth: New job #5c90ef44 from eu1.ethermine.org:4444; diff: 4000MH
2019.04.26:01:55:43.016: GPU1 GPU1: DAG 71%
2019.04.26:01:55:44.649: GPU1 GPU1: DAG 82%
2019.04.26:01:55:45.640: main Eth speed: 89.955 MH/s, shares: 0/0/0, time: 0:00
2019.04.26:01:55:45.640: main GPUs: 1: 0.000 MH/s (0) 2: 89.955 MH/s (0)
2019.04.26:01:55:46.283: GPU1 GPU1: DAG 94%
2019.04.26:01:55:46.566: eths Eth: Received: {"id":0,"jsonrpc":"2.0","result":["0x70aa0cd905faa88665163574baa2b7232259833b7c7ceb5fcfa4a4f53ff09ed9","0x96ea102ff70653f07bc76a20e40449c1f5f4335aca6408a7403c9d987f6bf44f","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x749895"]}
2019.04.26:01:55:46.566: eths Eth: New job #70aa0cd9 from eu1.ethermine.org:4444; diff: 4000MH
2019.04.26:01:55:47.081: GPU1 GPU1: DAG generated in 14.2 s (215.8 MB/s)
2019.04.26:01:55:47.082: GPU1 GPU1: Using Ethash OCL kernels (gfx906; -clkernel 1)
2019.04.26:01:55:50.584: eths Eth: Received: {"id":0,"jsonrpc":"2.0","result":["0x46919abf5e71598a5ba35b7c00634fa8744fa09de3b85d69d077c824779aad81","0x96ea102ff70653f07bc76a20e40449c1f5f4335aca6408a7403c9d987f6bf44f","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x749895"]}
2019.04.26:01:55:50.584: eths Eth: New job #46919abf from eu1.ethermine.org:4444; diff: 4000MH
2019.04.26:01:55:50.588: eths Eth: Send: {"id":5,"jsonrpc":"2.0","method":"eth_getWork","params":[]}
2019.04.26:01:55:50.588: eths Eth: Send: {"id":6,"jsonrpc":"2.0","method":"eth_submitHashrate","params":["0x55c99c7","0x4ef3f00611d26dec2b29eb65e4dcd802d5e0d46180a9807794c7fa74efd29aa3"]}
2019.04.26:01:55:50.629: eths Eth: Received: {"id":0,"jsonrpc":"2.0","result":["0x46919abf5e71598a5ba35b7c00634fa8744fa09de3b85d69d077c824779aad81","0x96ea102ff70653f07bc76a20e40449c1f5f4335aca6408a7403c9d987f6bf44f","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x749895"]}
2019.04.26:01:55:50.629: eths Eth: Received: {"id":6,"jsonrpc":"2.0","result":true}
2019.04.26:01:55:50.664: main Eth speed: 96.772 MH/s, shares: 0/0/0, time: 0:00
2019.04.26:01:55:50.664: main GPUs: 1: 6.853 MH/s (0) 2: 89.919 MH/s (0)
I noticed when GPU1 wanted to start up the DAG was taking a considerable amount of time to load. 5+ times as long as GPU2.
Anyone have any thoughts on this or similar issues?
It seems that GPU1 is running on idle clocks for some reason (you can confirm this by using AMD Control center to check the clocks of the cards in real time). In the past we have seen this with RX4xx/RX5xx cards but not with the recent drivers (and you are using fairly recent drivers). One possible workaround is to try and force the clocks with AMD Control Center. If there is no display attached to GPU1 you may also try using HDMI plug.
We will rename the sample epools.txt file to something else to avoid future problems like this.
don't do that.
now very comfortable.
We will just rename the SAMPLE epools.txt file that is included in the .zip file to avoid this issue in the future. When someone wants to use it as a template for their own epools.txt files, they can just rename it back to epools.txt (or copy its contents).
