 Show Posts
|
|
Pages: « 1 [2] 3 »
|
Ok, very annoying thing now...only on one rig I have this message "Application has been blocked from accessing Graphics hardware". Anyone had the same problem? Manage to solve it?
Thanks !
This is my wild guess. Uninstall any 3rd party Antivirus. Keep windows defender. Exclude the PhoenixMiner folder from windows defender. Run PhoenixMiner as administrator. Report back. |
|
|
|
I've noticed This:
With Claymore the consumption is 1600w. With This 2000w.
I've got a Rig With 8*1070 and 5*580.
The settings are the same.
Im using afterburnner.
Help needed.
For nvidia set power limit at MSI Afterburner to a value betwet 50-60 % - find a minimum value that does not lower the hash. For Amd - assuming you use the modded Rom with memory timing patch only and no other changes use miner setting for freq and voltages. Set voltages for both men and core to 850. Again you need to find optimal and stable values... Send a PM if you need additional help. I have similar rig with 7x 1070 and 6x rx580 hashing at 409 MH/s at 1680W. Hello my friend Thanks for the tip. The best i can do is 1900w. Can tou Share your command line and Afterburnner config for NVIDIA(our systems are the same). I pay 0.20€/kW... So every watt counts. Thanks. Sure I can; Complete setup: Power Usage: 1660W @Wall This rig has an i7 core 7700K which runs at 50% (about 50 watts) for XMR mining. Nvidia Driver: 397.31 (GPU: GIGABYTE GTX 1070 8GB GDDR5 - GV-N1070WF2OC-8GD) AMD Driver: Win10-64Bit-Radeon-Software-Adrenalin-Edition-18.2.1-Feb7 (GPU: ASUS STRIX RadeonRX 580 8GB O8G - ASUVG-RX580-O8G) AMD Modded ROM: Only Memory Timings STRAP Patched using PolarisBiosEditor (One click patch). MSI Afterburtner Settings: Core Voltage: +0 Power Limit %: 58 Temp. limit (oC): 60 Core Clock (MHz): -200 (minus 200) Memory Clock (Mhz): +705 Fan Speed (%): 45 (Manual) start script: setlocal
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
set DEFAULT_POOL=eu1.ethermine.org:4444
set WORKER=<Workername>
set WALLET=<MyETHWallet>
:: Archive old logs
move log*.txt old
echo Last start at: %TIME% %DATE% >>reboot.log
PhoenixMiner.exe config.txt
endlocal Command Line - I use config file for PH: :config.txt -epool %DEFAULT_POOL%
-ewal %WALLET%.%WORKER%
-epsw x
-clKernel 1
-cclock 0,0,0,0,1170,0,0,1160,1140,1160,1180,0,1120
-mclock 0,0,0,0,2160,0,0,2165,2150,2160,2155,0,2085
-cvddc 0,0,0,0,835,0,0,835,835,900,835,0,835
-mvddc 0,0,0,0,835,0,0,835,835,900,835,0,835
-rmode 2 Command line: PhoenixMiner.exe config.txt :reboot.bat-- :: Some trickery to mitigate the PH bug: config file not found from reboot.bat.
echo Last reboot at: %TIME% %DATE% >>reboot.log
copy config.txt config-reboot.txt
PhoenixMiner.exe config-reboot.txt Stats from PH: *** 42:18 ***************************************************
Eth: Mining ETH on eu1.ethermine.org:4444 for 42:18
Available GPUs for mining:
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 8), 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
GPU1: 56C 45%, GPU2: 59C 45%, GPU3: 54C 45%, GPU4: 52C 45%, GPU5: 50C 41%, GPU6: 56C 45%, GPU7: 59C 45%, GPU8: 50C 0%, GPU9: 52C 41%, GPU10: 51C 41%, GPU11: 51C 41%, GPU12: 53C 45%, GPU13: 52C 0%
Eth: Accepted shares 15142 (0 stales), rejected shares 0 (0 stales)
Eth: Incorrect shares 0 (0.00%), est. stales percentage 0.00%
Eth: Maximum difficulty of found share: 11.6 TH (!!!)
Eth: Average speed (5 min): 410.120 MH/s
Eth: Effective speed: 397.60 MH/s; at pool: 397.60 MH/s
GPUs: 1: 32.357 MH/s (1183) 2: 32.334 MH/s (1203) 3: 32.340 MH/s (1258) 4: 32.340 MH/s (1222) 5: 30.843 MH/s (1145) 6: 32.378 MH/s (1197) 7: 32.376 MH/s (1190) 8: 30.932 MH/s (1104) 9: 30.618 MH/s (1144) 10: 30.803 MH/s (1113) 11: 30.868 MH/s (1133) 12: 32.356 MH/s (1210) 13: 29.492 MH/s (1088) |
|
|
|
I've noticed This:
With Claymore the consumption is 1600w. With This 2000w.
I've got a Rig With 8*1070 and 5*580.
The settings are the same.
Im using afterburnner.
Help needed.
For nvidia set power limit at MSI Afterburner to a value betwet 50-60 % - find a minimum value that does not lower the hash. For Amd - assuming you use the modded Rom with memory timing patch only and no other changes use miner setting for freq and voltages. Set voltages for both men and core to 850. Again you need to find optimal and stable values... Send a PM if you need additional help. I have similar rig with 7x 1070 and 6x rx580 hashing at 409 MH/s at 1680W. |
|
|
|
 Thank u  336.6 at ~1050 watts! Stable A F. What gear? |
|
|
|
Not looking for the failover purpose, instead I'm looking to split up the total mining durations into two chunks, 1) mining using first wallet address & when 60 mins is reached flip over to the wallet 2 and mine for x time and back. Sort of like a dev fee idea. Or there maybe a better way to achieve the same thing? anyone expert in terms of batch file configuration? I'm attempting to use the following windows cmd commands to switch between different wallet address using one single batch file. However it seems to me that once the first phoenix process has started, the timeout command following is no longer working. Any suggestions as to why?
:wallet1
echo Starting Mining Process
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 us2.ethermine.org:4444 -pool2 us1.ethermine.org:14444 -wal <wallet.rigname> -gpus 1234567 -pass x -logfile *
timeout /t 60 <---stopped here>
taskkill /im PhoenixMiner.exe /f /t
goto wallet2
:wallet2
echo Starting Mining Process
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 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
you just need one bat file for a failover.... PhoenixMiner.exe -pool us2.ethermine.org:4444 -pool2 us1.ethermine.org:14444 -wal <wallet.rigname> -wal2 <wallet.rigname> -gpus 1234567 -pass x -pass2 x -logfile * -pool2 <host:port> Failover ethash pool address. Same as -pool but for the failover pool -wal2 <wallet> Failover ethash wallet (if missing -wal will be used for the failover pool too) -pass2 <password> Failover ethash password (if missing -pass will be used for the failover pool too) -worker2 <name> Failover ethash worker name (if missing -worker will be used for the failover pool too) -proto2 <n> Failover ethash stratum protocol (if missing -proto will be used for the failover pool too) -coin2 <coin> Failover devfee Ethash coin (if missing -coin will be used for the failover pool too) -stales2 <n> Submit stales to the failover pool: 1 - yes (default), 0 - no If you have more gpus the optimal way mining into two wallets is to run two instances of PhoenixMiner splitting half gpus to first instance and the second half to second instance. By hourly restarting the miner you are loosing mining time and damaging the hw due to temperature drop during the switch. In order to do what you intended to do with the batch approach you need to create a new proces using start comand. Example: start "Launch PH" /D "c:\phoenixminer" phoenixminer.exe config.txt Example: start "Launch PH" /D "c:\phoenixminer" phoenixminer.exe config.txt Hi, you can explain this a little more detailed what you mean by it or something we can try. The more elegant solution would be to simply mine to first wallet and then transfer half of the mined coins to the second wallet. The batch solution if you insist: 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 |
|
|
|
Hi, I just upgraded to 1803 using 2.9e miner version. The miner now gets stuck at:  It stays there for at least 1,5 hours till now. Looking forward to your help! Few posts back I have reported the same problem and issued a warning. In my instance compute mode was off after upgrade, and miner took some 5 or so minutes to find all gpus before starting mining. Two options: roll back the upgrade. Or clean install the Radeon drivers (Uninstall with ddu, install driver, enable compute mode) then try PH. Report your findings. |
|
|
|
Not looking for the failover purpose, instead I'm looking to split up the total mining durations into two chunks, 1) mining using first wallet address & when 60 mins is reached flip over to the wallet 2 and mine for x time and back. Sort of like a dev fee idea. Or there maybe a better way to achieve the same thing? anyone expert in terms of batch file configuration? I'm attempting to use the following windows cmd commands to switch between different wallet address using one single batch file. However it seems to me that once the first phoenix process has started, the timeout command following is no longer working. Any suggestions as to why?
:wallet1
echo Starting Mining Process
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 us2.ethermine.org:4444 -pool2 us1.ethermine.org:14444 -wal <wallet.rigname> -gpus 1234567 -pass x -logfile *
timeout /t 60 <---stopped here>
taskkill /im PhoenixMiner.exe /f /t
goto wallet2
:wallet2
echo Starting Mining Process
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 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
you just need one bat file for a failover.... PhoenixMiner.exe -pool us2.ethermine.org:4444 -pool2 us1.ethermine.org:14444 -wal <wallet.rigname> -wal2 <wallet.rigname> -gpus 1234567 -pass x -pass2 x -logfile * -pool2 <host:port> Failover ethash pool address. Same as -pool but for the failover pool -wal2 <wallet> Failover ethash wallet (if missing -wal will be used for the failover pool too) -pass2 <password> Failover ethash password (if missing -pass will be used for the failover pool too) -worker2 <name> Failover ethash worker name (if missing -worker will be used for the failover pool too) -proto2 <n> Failover ethash stratum protocol (if missing -proto will be used for the failover pool too) -coin2 <coin> Failover devfee Ethash coin (if missing -coin will be used for the failover pool too) -stales2 <n> Submit stales to the failover pool: 1 - yes (default), 0 - no If you have more gpus the optimal way mining into two wallets is to run two instances of PhoenixMiner splitting half gpus to first instance and the second half to second instance. By hourly restarting the miner you are loosing mining time and damaging the hw due to temperature drop during the switch. In order to do what you intended to do with the batch approach you need to create a new proces using start comand. Example: start "Launch PH" /D "c:\phoenixminer" phoenixminer.exe config.txt |
|
|
|
Who can say - why sometimes speed 1 of cards drops from 31M to 25M untill restarting miner?
Overclock reset. It happens sometimes don't know why though. I have these hash drops also but it comes back in couple of minutes. Sometime OverdriveNtool loses OC setting for one card usually, just down OC I use PhoenixMiner for OC (AMD) and MSI Afterburner for Nvidia. Have the drops and they always recover to max hash in couple of minutes. Never required to restart or anything. One of the "why" PhoenixMiner. |
|
|
|
One of my rigs stopped mining earlier today. Turned out it was Windows Defender that moved the PhoenixMiner.exe into the quarantine categorised as "Trojan:Win32/Tilken.B!cl"
Did restore the .exe and disabled Windows Defender. The threat in my opinion is Windows Defender, not the miner.
Windows Defender Details:
Trojan:Win32/Tilken.B!cl
Alert level: Severe
Status: Active
Date: 02/05/2018
Recommended action: Remove threat now.
Category: Trojan
Details: This program is dangerous and executes commands from an attacker.
Affected items:
file: C:\dev\Ethereum\PhoenixMiner_2.9e\PhoenixMiner.exe
process: pid:10100,ProcessStart:131683638871312779
You should not use any AV. included WD. That's really bad advice. Just configure your AV to exclude certain directories that your miners are located. To be precise: "Disabled Windows Defender" by adding an exclusion folder for PhoenixMiner. in the Windows Defender Security center: e.g. c:\dev\Ethereum\PhoenixMiner_2.9e |
|
|
|
Core clock should be use to lower the load on memmory but should never get over +150, and this also lower the power to get the card running between 80 and 100 watts with reduced power limit between 50 and 60% Here you have a good guide how to overclock nvidia cards https://mining.help/nvidia-ethereum-mining/In my opinion the guide above (and other guides on the web) are 80% great but inaccurate at 20%. A great start for newcomers - it helped me to get the whole picture when I started to build first rig, but inaccurate at many aspects and details. Advice: Proceed with caution. Again: My personal opinion. |
|
|
|
|
One of my rigs stopped mining earlier today. Turned out it was Windows Defender that moved the PhoenixMiner.exe into the quarantine categorised as "Trojan:Win32/Tilken.B!cl"
Did restore the .exe and disabled Windows Defender. The threat in my opinion is Windows Defender, not the miner.
Windows Defender Details:
Trojan:Win32/Tilken.B!cl
Alert level: Severe
Status: Active
Date: 02/05/2018
Recommended action: Remove threat now.
Category: Trojan
Details: This program is dangerous and executes commands from an attacker.
Affected items:
file: C:\dev\Ethereum\PhoenixMiner_2.9e\PhoenixMiner.exe
process: pid:10100,ProcessStart:131683638871312779
|
|
|
|
hashrate with gtx 1070 ?
These are my stable settings: Driver: 391.01 Using MSI Afterburner set as: Core Voltage (%): 0 Power Limit (%): 55 Temp Limit (%): 83 (linked with Power Limit) Core Clock (MHz): -200 Memory Clock (MHz): 635 Is your core clock set to negative 200 mhz? I'm getting similar hash rates with my MSI GTX 1070s, (just two for the time being.) Here are my afterburner settings: Core Voltage: 0% Power: 65% Temp: 67 degrees Centigrade (linked with power) Core Clock: +99 Mem Clock: +650 Yes, I run my core clock as low as possible to preserve power, lower the overall GPU temperature. Ethash PoW is memory hard. High core clock has very little impact on hash rate. So no real gain increasing the core clock. My new settings (stable for the last 24h) are: Core Voltage (%): +0 Power Limit (%): 58 Temp Limit (%): 83 (linked with Power Limit) Core Clock (MHz): -200 (minus two hundred) Memory Clock (MHz): +685 With PhoenixMiner stats are: Hash: 1: 32.114 MH/s (4419) 2: 32.113 MH/s (4435) 3: 32.098 MH/s (4351) 4: 32.116 MH/s (4478/3) 6: 32.128 MH/s (4469) 7: 32.119 MH/s (4390) 12: 32.120 MH/s (4489) Temperature: GPU1: 58C 38%, GPU2: 60C 41%, GPU3: 57C 36%, GPU4: 56C 35%, GPU6: 58C 39%, GPU7: 60C 41%, GPU12: 57C 36%, GPU13: 53C 0% While running on the default configuration I would be getting around 26 MH/s while the GPU temperature would stabilise at 72oC. By reducing the core/power limit both the GPU temperature and power usage is reduced. In the above stats I have removed the RX580 figures as this reply is focusing on nvidia GTX 1070. The above GPUs are all Gigabyte - GV-N1070WF2OC-8GD (GIGABYTE GTX 1070 8GB GDDR5) |
|
|
|
hashrate with gtx 1070 ?
These are my stable settings: Driver: 391.01 Using MSI Afterburner set as: Core Voltage (%): 0 Power Limit (%): 55 Temp Limit (%): 83 (linked with Power Limit) Core Clock (MHz): -200 Memory Clock (MHz): 635 Note: The power limit is set in cmd (as admin) using next commands: cd C:\Program Files\NVIDIA Corporation\NVSMI
nvidia-smi --id=0 --power-limit=100
nvidia-smi --id=1 --power-limit=105
nvidia-smi --id=2 --power-limit=100
...
A draw can be checked by: C:\Program Files\NVIDIA Corporation\NVSMI>nvidia-smi --query | find "Power Draw" | find /v "1911" | find /v "N/A"
Power Draw : 100.11 W
Power Draw : 104.22 W
Power Draw : 99.06 W
Power Draw : 99.08 W I figured when reducing the power limit further down it would had an effect on hash rate (reduced). Found a min limit point at witch the hash was maximised at given settings manually by trial. Note that the settings above only work stable for me when the power limit was reduced. With the power limit at 100% the settings were note stable at all. Stats from PhoenixMiner: 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 GPU1: 54C 27%, GPU2: 57C 34%, GPU3: 52C 25%, GPU4: 53C 26% GPUs: 1: 31.755 MH/s (3367) 2: 31.774 MH/s (3365) 3: 31.733 MH/s (3267) 4: 31.754 MH/s (3395/3) Did push memory freq. further but it did not run stable for long. |
|
|
|
Decided to try this out on 1 GTX 1070ti today. ETH-only mining with Claymore was giving me a consistent 34.2 Mh/s, Phoenix is reporting 34.6 Mh/s so I'm going to let it run for a day or 2 and compare shares, but this looks like a winner to me. Thank you!!
When making a final judgement make sure that you account for all the contributing factors such as luck, long enough testing period... Stats from some of my rigs (all 13 GPU rigs 8GB, both RX580 and nvidia 1070 8GB): Rig 2: Eth speed: 404.844 MH/s, shares: 41520/1/3, time: 115:23, shares per min: 5,895215107 Rig 4: Eth speed: 407.562 MH/s, shares: 120660/1/49, time: 337:48, shares per min: 5,953226761 Rig 1: Eth speed: 409.197 MH/s, shares: 98235/0/31, time: 274:26, shares per min: 5,965929795 Rig 3: Eth speed: 411.097 MH/s, shares: 122320/2/17, time: 337:44, shares per min: 6,036320568 ... The running time is several days for each of the above rigs. The higher the hash rate the higher the number of shares per minute. As it should be. But this only become right after several days of running time. For the first few days it was almost random... |
|
|
|
Hello, I'm using 2 RX 580 GPUs When I use -clKernel 0 The hash rate moves up & down, most of time it is showing 64 MH/s, sometimes go down to 58 MH/s The average 5 min. is just above 58 MH/s When I use -clKernel 1 The hash rate is more stable, most of the time is 60 MH/s sometimes go down to 59.7 or so The average 5 min. is about 59.8 With kernel 0, looking at it, the average appears to be over 62 MH/s What I must believe the 5min. average or what I see on the screen? Could the average 5 min. with kernel 0 be wrong? & why just after starting miner it tell me the 5 min. average when I have been only mining for 1 min. or even less? Thank you.  Over time the higher the average the more shares you find. You can also use "-dcri" to optimise your hashing rate. In PH 3.0 this will be automatically tuned for best param like in the Claymore - a promised feature of the PH developer. For now do it manually. It might increase your hash even further and bring more stable hash rate on default kernel. High hash rate fluctuation (several MH/s) is an indication of overclocked setup. The card is attempting to compute at the maximum speed but at times it throttles down due to the increased temperature or other factors internally managed by the GPU bios. There are quite few things you can do to address this. Rig cooling - add external fans, reduce core/mem clocks, manage ambient and rig (gpu) temperature ... When you start the miner the average is calculated with the available data. In the first few minutes that is less than 5 minutes of data regardless of the listed "(5 min)". |
|
|
|
hello,
i have to say, i like this miner very much, but have 1 problem.
i have rig with 12 x rx580 cards,
i set parameter -minfan 90 , but it doesnt work, fans still work as default
any advice ?
thanks
According to the documentation: "Hardware control options (AMD cards only; use comma to specify different values for each GPU):" We might therefore assume that single value stands for all cards. I have observed that "-tt 60" option does not work and got it working with setting an individual value for each card like: "-tt 60,60,60,60,60,60,60,60" on the 8 AMD rig. Not sure if this is a "bug" or intended behavior; the supplied readme.txt (the documentation) is not clear on the details. My understanding of the temperature management in PhoenixMiner is that you need to setup a target temperature (-tt) before you can utilise other temperature parameters such as -fanmin, -fanmax, -tmax... So give next options a try (taking into the account you have 12 amd GPUs): -tt 60,60,60,60,60,60,60,60,60,60,60,60, -fanmin 90,90,90,90,90,90,90,90,90,90,90,90 BTW: Using -fanmin 90 is in my opinion not the best approach in keeping the temperature as steady as possible. It will introduce higher than optimal temperature fluctuation which is bad for the hardware. The "default" is in my opinion optimal -fanmin 0 and -fanmax 100 leaving the miner a full flexibility on managing the target temperature of the GPUs using the build in temperature/fan curve. PH does not document how it does the temperature management so we do not know what exactly will the "-fanmin 90" do in terms of temperature management. |
|
|
|
I see some use the pause at the end of their startup .bat file, what does that command do? And also is the setx commands needed?
It allows to view the command output of the startup/restart script. It is particularly handy when the script fails or PhoenixMiner startup fails for debugging purposes. |
|
|
|
|
Defect Description: reboot.bat fails to load config file
Command Output:
GPU7 not responding
Thread(s) not responding. Restarting.
Eth speed: 215.464 MH/s, shares: 216/0/0, time: 1:00
GPUs: 1: 31.246 MH/s (24) 2: 30.626 MH/s (34) 3: 30.510 MH/s (34) 4: 31.255 MH/s (33) 5: 30.694 MH/s (27) 6: 31.212 MH/s (21) 7: 0.000 MH/s (24) 8: 29.920 MH/s (19)
C:\dev\Ethereum\PhoenixMiner_2.9e>PhoenixMiner.exe config-ms05.bat
Phoenix Miner 2.9e Windows/msvc - Release
-----------------------------------------
Unable to open configuration file config-ms05.bat
C:\dev\Ethereum\PhoenixMiner_2.9e>pause
Press any key to continue . . .
reboot.bat:
----
PhoenixMiner.exe config-ms05.bat
pause
----
The initial startup of the miner is started using the same command: PhoenixMiner.exe config-ms05.bat
Workaround: Updated reboot.bat to:
----
echo Last miner reboot at: %DATE% %TIME% >>reboot.log
copy config-ms05.txt config-ms05-reboot.txt
PhoenixMiner.exe config-ms05-reboot.txt
pause
----
|
|
|
|
The connection issue still persist.
if you reboot router with dynamid ip
the miner cant connect to ethermine.org pool
you need to manual close and relaunch the program to connect
70-80% of rigs have this problem occur
while some can connect after router reboot
i'm agree... The connection issue still persist. I did observe this problem when my dynamic IP changed by the ISP. However in my case Phoenix 2.8c auto-recovered from the situation on its own. It attempted to connect to the main pool several times waiting 20 sec in between and then after 3 or so failed attempts successfully connected to the next pool from my epools.txt. Possible workaround: Add second (or more) pool(s) to the epools.txt list. You can add the same pool there twice. Example of epools.txt: # Ethermine.org # Main pool listed in the config.txt file: POOL: eu1.ethermine.org:4444, WALLET: %WALLET%.%WORKER%, PSW: x, WORKER: , ESM: 0, ALLPOOLS: 0 POOL: us1.ethermine.org:4444, WALLET: %WALLET%.%WORKER%, PSW: x, WORKER: , ESM: 0, ALLPOOLS: 0 POOL: us2.ethermine.org:4444, WALLET: %WALLET%.%WORKER%, PSW: x, WORKER: , ESM: 0, ALLPOOLS: 0 POOL: asia1.ethermine.org:4444, WALLET: %WALLET%.%WORKER%, PSW: x, WORKER: , ESM: 0, ALLPOOLS: 0 POOL: asia2.ethermine.org:4444, WALLET: %WALLET%.%WORKER%, PSW: x, WORKER: , ESM: 0, ALLPOOLS: 0 |
|
|
|
Report of first 24hrs on PhoenixMiner 2.9d (migrated from 2.8c). Environment: 52 GPU (45x RX580/8GB, 7x 1070/8GB) in four rigs of 13 cards each. Results: - Hashing rate: Increased a bit: Before: 1.630 GH/s, now 1.633 GH/s ~ 0.12% increase. The increase is most notable on Nvidia cards. - Power Consumption: Decreased for few watts: e.g. on one rig from 1630 to 1620W on average, measured on the wall. A slight temperature drop in line with power consumption. - Stale share: Increased a bit as reported by the ethermine.org pool, before 3-4%, now 4-5% with drops to 2% occasionally. Was < 3% on Claymore 11.5 - Stability: Stable, occasional hashing drops on some cards e.g. form 31MH/s to 24 for a 10-20 sec, then recovering back to normal 31 MH/s. Did not observe that before. Comments: - In my opinion the "-logsmaxsize <n> Maximum size of the logfiles in MB. The default is 200 MM"; The default value of 200Mb is to high and cannot be normally edited by most editors. The default should be no more than e.g. 10MB or if you must, 50Mb. - Missing a feature: Auto tune of the GPU tuning parameter /-gt/; Similar to Claymore -dcri auto tune). - The 2.9d is officially released as an unofficial version with full support. Really Why not just stick to the usual sw naming convention like calling it "alpha"; a limited test version that might get new functionalities until released as final. Verdict: Works like a charm out of the box. Thumbs up! |
|
|
|
|
