Anyone have any issue with phoenix not setting clocks properly? One of my 8 GPU 580 rigs has literally just 1 GPU that it keeps setting mclock to 2250 and it's the only value that won't change. Just recently started happening after windows did a stupid update that I couldn't prevent.
Currently running adrenaline drivers 18.3.1 on all rigs. No issues with any other rigs/GPUs. Tested in claymore and clocks set as they should with that. Just curious why one solitary GPU has mclock locked at 2250. I've changed the cclock values and it works with this GPU, just not mclock. It's a sapphire nitro+ 8g 580. I would post my batch/config files but I know that shouldn't be an issue. I've tried adjusting it to plenty of other settings. Even when I set it to 0 for that GPU it still locks it at 2250.
This shouldn't happen with these drivers (we have run exactly the same card with the same drivers and it doesn't behave like that). However we have experienced an MSI 570, which had similar problems even with the stock BIOS. Eventually the MSI stopped working completely unless it is the only card in the rig. It's probably some kind of BIOS problem but we can't be certain.
Thank you for the program... it seems compared to Claymore... I get less stale shares.... and more hashes.....
one of the most stable Rig Rx580 8GB tune to no memory errors.. 8 Cards mining only Eth
Same Clock Settings
Claymore Reported Hash 240.92mhz Actual Hash 24 hours 231.56 mhz..
Phoenix Reported Hash 242.13mhz Actual Hash 24 hours 235.04 mhz..
The only thing your program is no good is that the setting of the mclock and cclock.... cannot overly undervolt... some cards are "bad" hence need to reduce mclock more to get 0 memory errors.....
Took the plunge and learn to set the clocks with Overdriventool! and together with your program works perfect!
I have 12 rigs... 9 Nvidia.. 3 Rx 580s all 8 cards... 3160mhz total... on ETH
all Currently mining with Phoenix... The nvidia cards.. works even better Reported 303.13mhz Actual hash.. 301.58mhz @ Avg actual.. and even Actual hash hit 303.23 @ some point...
Enjoy your dev fee... well given... Claymore performance is not as good Can't believe my rigs.. been using 10 months with claymore...... if your program came out earlier.. I would have earn few percent more in earnings... est $2000 more in the past 10 months.... $2000 is still money in these kind of market...
Thanks a lot, we are glad it works fine for you
We are working hard on improving the hardware support. A lot of the devfee goes towards purchasing and testing all kinds of GPUs to be certain that they are working fine with PhoenixMiner but some of the problems rear their ugly heads only after extended usage, or with certain driver/Windows version combinations.
PhoenixMiner, What there will be new in the next version?
Support for Linux (finally), and some interesting optimizations in the kernels.
So i got windows update some how... and my drivers got fked up..
installed AMD 17.5.2 and PhoenixMiner say
"Amd compute mode is not supported by your driver 17.5.2".
Can someone help me? I think I had this driver before update
Sapphire rx 580 here.
This message means that your drivers doesn't support AMD large memory pages (a.k.a. Compute mode) and you will probably get low hashrate on the current DAG epochs. You have to either use drivers 18.x.x (recommended), or the blockchain beta drivers (only recommended if you are on Windows 7, as the official Windows 7 drivers doesn's support Compute mode). If you are mining Pirl, or any other low-DAG coin this doesn't matter but for ETH and ETC the hashrate drop without Compute mode is devastating.
Hello guys, hello PhoenixMiner.
I try the phoenix miner v2.9e upgrade to 3.0C, I liked it,but He will not Get the value for Hardware control options -cclock -cvddc -mclock -mvddc , which command I set up to do this.
I have amd xfx rx580 8gb gts xxx 8xcard in Rig
Thanks for your reply
Did the
-cclock -cvddc -mclock -mvddc options work for you with 2.9e? Also, make sure that you are using a 18.x.x driver.
I have a suggestion:
When closing the miner and if you are using it to set clocks and vddc it will reset the clocks and vddc to the standards. What happened to me was that doing it with a 6 GPU and 1000W PSU computer simply crashed due to overload. What I do when I need to close the miner is pause the gpus so they go to idle clocks and vddc and only when most of them are idling I close the miner. Would be interesting to add an option so it will pause the gpus then set the clock back or something that would not make the rig overload due to reseting its configuration all at the same time.
Sorry for the inconvenience. We will fix this in the next version, where there will be an option to avoid resetting the OC settings at shutdown. This is one of these things that never happens on our rigs because the PSU(s) are well above 150% of the needed power to avoid any hardware instabilities (it would be hard to determine if a crash is caused by the hardware, or a software bug otherwise).
Running 7 AMD gpus. Reported Hashrate is 200.9. At first the hashrate was doing around 190 something but as time pass by it current hashrate get lower and lower. After a day it reported hashrate is still 200 but the current hashrate is 159.2 and average hashrate is 161.
Make sure that you are running this for at least 24 hours. After at least 24 hours there shouldn't be such a big difference. If the problem continues, switch to another pool because this is not normal in the long run.
janding and Phoenixminer Team
I want to say that the Phoenixminer will not receive the given commands in .bat file, when I look at Hwinfo i Gpu-z, I still have a higher value than the specified in the .bat file on -mvddc and -cvddc
And just to say when i put those same comand in Clay v11.8 everything is Ok.
Thanks for replay
What driver version you are using (18.x.x is required for the hardware control options to work reliably)? Small difference is not a problem (e.g. -fanmax 55 but you are seeing fan speed at 57%).
well I got it to mine in 1709 with 18.3.4 but now the cards are only mining at 17 each vs 30+ with crimson. (compute) is on
2018.06.26:02:07:05.063: main Phoenix Miner 3.0c Windows/msvc - Release
2018.06.26:02:07:05.063: main Cmd line: -pool eu2.ethermine.org:4444 -pool2 us2.ethermine.org:4444 -wal 0xE2d5DeBE9D221b44913f9E0A318f114b22B174e6.Rig1 -proto 3 -amd -tt 65 -tstop 85 -fanmin 40 -fanmax 100 -cvddc 925 -mvddc 925 -gser 1 -cclock 1200 -mclock 2100,2100,2100,2015,2060,2070,2020,2260
2018.06.26:02:07:10.930: main Available GPUs for mining:
2018.06.26:02:07:10.930: main GPU1: Radeon RX 580 Series (pcie 1), OpenCL 2.0, 8 GB VRAM, 36 CUs
2018.06.26:02:07:10.930: main GPU2: Radeon RX 580 Series (pcie 3), OpenCL 2.0, 8 GB VRAM, 36 CUs
2018.06.26:02:07:10.930: main GPU3: Radeon RX 580 Series (pcie 4), OpenCL 2.0, 8 GB VRAM, 36 CUs
2018.06.26:02:07:10.930: main GPU4: Radeon RX 580 Series (pcie 8), OpenCL 2.0, 8 GB VRAM, 36 CUs
2018.06.26:02:07:10.930: main GPU5: Radeon RX 580 Series (pcie 9), OpenCL 2.0, 8 GB VRAM, 36 CUs
2018.06.26:02:07:10.930: main GPU6: Radeon RX 580 Series (pcie 12), OpenCL 2.0, 8 GB VRAM, 36 CUs
2018.06.26:02:07:10.930: main GPU7: Radeon RX 580 Series (pcie 13), OpenCL 2.0, 8 GB VRAM, 36 CUs
2018.06.26:02:07:10.930: main GPU8: Radeon RX 580 Series (pcie 14), OpenCL 2.0, 8 GB VRAM, 36 CUs
2018.06.26:02:07:11.093: main ADL library initialized
2018.06.26:02:07:11.376: main Listening for CDM remote manager at port 3333 in read-only mode
2018.06.26:02:07:11.376: main Eth: the pool list contains 4 pools
2018.06.26:02:07:11.376: main Eth: primary pool: eu2.ethermine.org:4444
2018.06.26:02:07:11.376: main Starting GPU mining
2018.06.26:02:07:11.376: main Matched GPU1 to ADL adapter index 32 (method 1)
2018.06.26:02:07:12.115: main GPU1: Created ADL monitor for adapter 32; overdrive version: 7
2018.06.26:02:07:12.115: main GPU1: using AMD driver ver 18.3.4
2018.06.26:02:07:12.116: main Matched GPU2 to ADL adapter index 0 (method 1)
2018.06.26:02:07:12.605: main GPU2: Created ADL monitor for adapter 0; overdrive version: 7
2018.06.26:02:07:12.607: main GPU2: using AMD driver ver 18.3.4
2018.06.26:02:07:12.607: main Matched GPU3 to ADL adapter index 16 (method 1)
2018.06.26:02:07:13.511: main GPU3: Created ADL monitor for adapter 16; overdrive version: 7
2018.06.26:02:07:13.511: main GPU3: using AMD driver ver 18.3.4
2018.06.26:02:07:13.511: main Matched GPU4 to ADL adapter index 48 (method 1)
2018.06.26:02:07:14.009: main GPU4: Created ADL monitor for adapter 48; overdrive version: 7
2018.06.26:02:07:14.010: main GPU4: using AMD driver ver 18.3.4
2018.06.26:02:07:14.010: main Matched GPU5 to ADL adapter index 112 (method 1)
2018.06.26:02:07:14.492: main GPU5: Created ADL monitor for adapter 112; overdrive version: 7
2018.06.26:02:07:14.492: main GPU5: using AMD driver ver 18.3.4
2018.06.26:02:07:14.492: main Matched GPU6 to ADL adapter index 80 (method 1)
2018.06.26:02:07:14.973: main GPU6: Created ADL monitor for adapter 80; overdrive version: 7
2018.06.26:02:07:14.973: main GPU6: using AMD driver ver 18.3.4
2018.06.26:02:07:14.974: main Matched GPU7 to ADL adapter index 96 (method 1)
2018.06.26:02:07:15.451: main GPU7: Created ADL monitor for adapter 96; overdrive version: 7
2018.06.26:02:07:15.452: main GPU7: using AMD driver ver 18.3.4
2018.06.26:02:07:15.452: main Matched GPU8 to ADL adapter index 64 (method 1)
2018.06.26:02:07:15.929: main GPU8: Created ADL monitor for adapter 64; overdrive version: 7
2018.06.26:02:07:15.929: main GPU8: using AMD driver ver 18.3.4
2018.06.26:02:07:15.930: wdog Starting watchdog thread
2018.06.26:02:07:15.931: main Eth: Connecting to ethash pool eu2.ethermine.org:4444 (proto: QtMiner)
2018.06.26:02:07:15.954: hwmc GPU1: set GPU clocks to 1200 MHz (Vddc 925 mV)
2018.06.26:02:07:15.958: hwmc GPU1: set VMEM clocks to 2100 MHz (Vddc 925 mV)
2018.06.26:02:07:15.963: hwmc GPU2: set GPU clocks to 1200 MHz (Vddc 925 mV)
2018.06.26:02:07:15.967: hwmc GPU2: set VMEM clocks to 2100 MHz (Vddc 925 mV)
2018.06.26:02:07:15.973: hwmc GPU3: set GPU clocks to 1200 MHz (Vddc 925 mV)
2018.06.26:02:07:15.977: hwmc GPU3: set VMEM clocks to 2100 MHz (Vddc 925 mV)
2018.06.26:02:07:15.981: hwmc GPU4: set GPU clocks to 1200 MHz (Vddc 925 mV)
2018.06.26:02:07:15.985: hwmc GPU4: set VMEM clocks to 2050 MHz (Vddc 925 mV)
2018.06.26:02:07:15.988: hwmc GPU5: set GPU clocks to 1200 MHz (Vddc 925 mV)
2018.06.26:02:07:15.991: hwmc GPU5: set VMEM clocks to 2060 MHz (Vddc 925 mV)
2018.06.26:02:07:15.995: hwmc GPU6: set GPU clocks to 1200 MHz (Vddc 925 mV)
2018.06.26:02:07:15.998: hwmc GPU6: set VMEM clocks to 2070 MHz (Vddc 925 mV)
2018.06.26:02:07:16.002: hwmc GPU7: set GPU clocks to 1200 MHz (Vddc 925 mV)
2018.06.26:02:07:16.005: hwmc GPU7: set VMEM clocks to 2050 MHz (Vddc 925 mV)
2018.06.26:02:07:16.012: hwmc GPU8: set GPU clocks to 1200 MHz (Vddc 925 mV)
2018.06.26:02:07:16.018: hwmc GPU8: set VMEM clocks to 2250 MHz (Vddc 925 mV)
2018.06.26:02:07:16.148: eths Eth: Connected to ethash pool eu2.ethermine.org:4444 (91.121.167.111)
2018.06.26:02:07:16.149: eths Eth: Send: {"id":1,"jsonrpc":"2.0","method":"eth_login","params":["0xE2d5DeBE9D221b44913f9E0A318f114b22B174e6.Rig1"]}
2018.06.26:02:07:16.192: main GPU1: 45C 0%, GPU2: 51C 41%, GPU3: 47C 0%, GPU4: 48C 0%, GPU5: 45C 0%, GPU6: 49C 41%, GPU7: 51C 41%, GPU8: 48C 0%
2018.06.26:02:07:16.321: eths Eth: Received: {"id":1,"jsonrpc":"2.0","result":true}
2018.06.26:02:07:16.321: eths Eth: Send: {"id":5,"jsonrpc":"2.0","method":"eth_getWork","params":[]}
You just have to wait about five minutes for the auto-tune to finish and you will get the final hashrate. Also, you can try the -clkernel 2 and see if it gives higher hashrate (after it finished the auto-tune process). Once you figure out the best -gt values you can press 's' in the console window and copy them to your command-line to avoid performing auto-tune each time when you restart your rig.
I don't understand why this miner does not support DubaiCoin. I want to mine DBIX but my rigs often crash when switching DAG.
We will add support in the next version. In the meantime, you can set
-coin clo (or some other new coin with low DAG epoch) to avoid long DAG generation.
just want to know, is it possible if added a function to monitor the specific amount of rejected and or incorrect share then do restart miner?
This is on our TODO list but no guarantees that it will happen in the next version. Currently there is a limit of three consecutive rejected shares before switching to the next pool but there is no limit for restarting.
What the plans for the next version, would be intresting to see what more can be done??
There is always something to improve. Right now we are focused on the Linux version, and on finding ways to further increase the mining profitability.
How do you find a certain gpu? according to the readme.....
Additionally, while the miner is running, you can use the following interactive commands
in the console window by pressing one of these keys:
s Print detailed statistics
1-9 Pause/resume GPU1 ... GPU9 (if you have more than 9 GPUs, type 010 for card 10, 011 for card 11, etc.)
p Pause/resume the whole miner
I just press a number and it will stop the gpu from mining? The P command works but I can't get individual gpus to pause so I can find gpu 7
Any help would be appreciated
Yes, you just press 7 and it will pause GPU7. Another press on 7, and it would resume mining on GPU7. Pressing p pauses/resumes the whole miner and is independent from the pausing/resuming of the individual GPUs. For example, if you pause GPU7, then pause the whole miner, then resume the whole miner, the GPU7 will still remain paused until you resume it by pressing 7 (or by restarting the miner).
You will see the corresponding message(s) in the console too:
Mining on GPU7 is disabled
Mining on GPU7 is enabled
Dear PhoenixMiner Team
So what about core/memory clock/voltage control for Nvidia cards? That is the one thing you should do to become the best solo miner. I guess so. Any idea?
And what about dual mining? Second ASIC-resist coin may be the best choice. Is this real to mine ETH + CryptoNightv7?
We are definitely working on these but the focus for the next version is elsewhere. As for the dual mining, it is also coming but ETH + CryptoNight is not on the cards for now.
I'm still at 2.9.
3.0 is slightly slower, and I want an option for it not to reset clock speeds when exiting.
The option will be added in 3.1 for sure.
is there anybody with startup problems using the version 3.0c? the 3.0c crashes 80% of tries if there was a system restart. 2.9 was crash free, dev asked for the log but there is nothing in the log.
Could this be some form of Debugger detected error (since there isn't anything in the log)? We have made some improvements in the anti-debug code, which should lower the time when it "freaks out" without any good reason.
hi, any have probleme resolved with same GPU like me ?
GPU zotac gtx 970 amp! omega edition.
thank you in advence
We have a few GTX970s - you have to use Windows 7, and older drivers, and you can only mine low DAG coins like Pirl, Akr, etc. Mining ETH and ETC is out of the question as the performance drops like a stone with the larger DAGs with GTX970. Also it is quite a fight to get any decent hashrate from GTX970 under Windows 10.
Quick question:
Is there a need to add "-proto 3" for ETC configuration on Ethermine? The server is: etc.ethermine.org
I noticed in the example for ETH, "-proto 3" is added to the command line.
Thanks for the help
No, ethermine works fine with both -proto 3 and the default (which is -proto 2). There is no upside in running one over the other (there was in the past but no more).
Any news on the update or beta version?
I assume Nvidia finding of best overclock value in next release.
I always wonder why one of my GPUS has lowerst clock compared to others.
GPU0 us always 28 sumfin, where others 31 on RX580s.
There no monitors attached as some people think. \Just dont understand it?
Finding of the best overclock value automatically is nice in theory but hard in practice as in many cases the failures are not graceful (i.e. not just incorrect shares but outright Windows crashes, etc.). Perhaps it could be implemented in the future but with hard upper clock limit, and with a lot of caveats and warnings.
As for the lower hashrate of one of your GPUs - usually it has different memory timings than the others. Also, even if you don't have a display attached, if you don't have an integrated Intel video with HDMI plug (and even in such case, make sure that you have made the iGPU the primary GPU in the BIOS), one of your GPUs would still be used more by Windows and designated as the "primary" GPU.
Driver 398.18 miner 3, what's the problem?
2018.06.30:18:12:14.958: eths Eth: Received: {"id":6,"jsonrpc":"2.0","result":true}
2018.06.30:18:12:15.747: main GPU1: 56C 46%, GPU2: 58C 48%, GPU3: 55C 45%, GPU4: 55C 45%, GPU5: 55C 44%, GPU6: 49C 39%
2018.06.30:18:12:19.606: main Eth speed: 149.125 MH/s, shares: 6/0/0, time: 0:04
2018.06.30:18:12:19.606: main GPUs: 1: 24.668 MH/s (0) 2: 25.003 MH/s (2) 3: 25.003 MH/s (0) 4: 24.999 MH/s (0) 5: 24.999 MH/s (3) 6: 24.453 MH/s (1)
2018.06.30:18:12:20.422: GPU6 CUDA error in CudaProgram.cu:329 : unspecified launch failure (719)
2018.06.30:18:12:20.422: GPU6 GPU6 search error: unspecified launch failure
2018.06.30:18:12:20.450: GPU4 CUDA error in CudaProgram.cu:329 : unspecified launch failure (719)
2018.06.30:18:12:20.450: GPU4 GPU4 search error: unspecified launch failure
2018.06.30:18:12:20.481: GPU5 CUDA error in CudaProgram.cu:329 : unspecified launch failure (719)
2018.06.30:18:12:20.481: GPU5 GPU5 search error: unspecified launch failure
2018.06.30:18:12:20.497: GPU2 CUDA error in CudaProgram.cu:329 : unspecified launch failure (719)
2018.06.30:18:12:20.497: GPU2 GPU2 search error: unspecified launch failure
2018.06.30:18:12:20.499: GPU3 CUDA error in CudaProgram.cu:329 : unspecified launch failure (719)
2018.06.30:18:12:20.499: GPU3 GPU3 search error: unspecified launch failure
2018.06.30:18:12:20.513: GPU1 CUDA error in CudaProgram.cu:329 : unspecified launch failure (719)
2018.06.30:18:12:20.513: GPU1 GPU1 search error: unspecified launch failure
2018.06.30:18:12:20.544: wdog Thread(s) not responding. Restarting.
2018.06.30:18:12:24.685: main Eth speed: 99.168 MH/s, shares: 6/0/0, time: 0:04
If this happen again, check if the same GPU (GPU6), shows the first error. If so, lower the memory overclock of GPU6.
PhoenixMiner_3.0c all rigs AMD r390+win10 or win7
FATAL ERROR: Debugger detected 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 stratum+tcp://daggerhashimoto.eu.nicehash.com:3353 -wal my_btc_wallet -pass x -proto 4 -stales 0 -amd
ps
working only on NVIDIA cards
Sorry about that. We will have a fix for this in the next version, where this error shouldn't happen so often.
I suggest the next version should have an option to choose which config file is used. If not specified, it automatically loads the default config.txt
You can do this with the current version by specifying the file name as the only parameter:
PhoenixMiner MyAlternativeConfig.txt
And if you run without any parameters, it will load config.txt.
Just started using this miner now. Seems good so far.
1. When starting mining the line "unable to open log file etc.." shows up for a few seconds before it starts mining.
What is that about?
2. Also using the autotune. How come claymore autituning takes a few seconds and yours a few minutes?
Solved nr. 1:
-logfile Log.txt (but I had to create Log.txt first). Doesnt the miner have the privileges to create txt files??
1. Probably some mishap with the access rights in this particular folder.
2. The hashrate is often unstable, and we are using finer-grained tuning parameter, so we want to be sure that we have found the best -gt value. You will only need to run auto-tine when the miner restarts. If you are restarting your miner frequently, just copy the best -gt values found by the auto-tune (you can press the 's' key in the console to see them) and paste them in your command line. When the -gt values are specified, there will be no auto-tune unless manually requested by pressing the 'z' key in the console.
3.5 days ago I have reverted from 3.0c to 2.9e. I use nanopool for eth. Basing on statistics from pool I have result some better now.
What is the difference between the reported average hashrate in 2.9e and 3.0? Perhaps this is an issue of unstable hashrate. You can try -clkernel 2 (if you aren't already using the alternative kernels) and see if they will give you more stable average hashrate. On some cards we have observed random-ish drops in hashrate in the normal kernels, which are missing with alternative kernels.
