What's this: PhoenixMiner 2.9c: fastest Ethereum/Ethash miner with lowest devfee (Windows)?
Fake release, probably packed with malware. All official or beta (or whatever) releases of PhoenixMiner will be done here, in this thread.
Running 2.8c now, One of my GPU's still drops to 0.0mh. I have two models of this card, same memory, both with stable overclock. Runs fine with 2.7b. Have tried to lower significantly its memory clock from 2200 to 2100, 2075 and 2050, does not fix the problem, left the core at 1150. With version 2.8c I have tried to use the -clnew 0 flag for that particular GPU while designating the other cards in the system -clnew 1 yet it does not fix the problem. I run the card with -mi 12 on 2.7b so I also tried to lower that to -mi 10 on 2.8c with no difference in result. Only way that card remains hashing is by running it separately with 2.7b. I have also tried claymore 11.6 version with the same conclusion, hashes for a minute or two and drops out to 0.0mh.
Has anyone else experienced this particular problem? Its not a major issue for me running two versions but it is the idea that I cannot solve this problem has me twisted atm.
While we were unable to reproduce the problem, we have an idea what may be the cause although it doesn't make much sense. Still, we will fix this in the next release where -clnew 0 should be able to completely replicate the behavior from 2.7.
Just gave a chance to PM2.8c today on Windows 10. Sharing my first expression, observations, problems and results:
Copied the Claymore config file over. It fails out of the box. Requires a migration of configuration.
After a bit of tweaking a successful configuration file migration was in place. Got the PM2.8c running in less than 3 minutes.
The following discrepancies were observed:
PM2.8c vs CL11.5
1. config file with spaces listing multiple single option values, for example: "-cvddc 835, 835, 850, 900, 835, 835" reports an issue with invalid option 835. CL allows spaces. Some use spaces with a line above as comment with list of GPUs; GPU1 GPU2 GPU3 ... - spaces are for alignment.
2. Order of GPUs is different, this leads to incompatibility with CL existing configuration. CL lists AMD cards then adds NVidia cards. On PH2.8c all are mixed as discovered at system level The migration requires redo of the config file and custom settings for all options with individual values per GPU. For example: -cclock 0,0,0,0,1170,0,0,1160,1160,1160,1180,0,1120 - the 0 for NVIDIA cards. Migrated from -cclock 1170,1160,1160,1160,1180,1120.
3. -ethi default is different 8 vs 12.
Results/comparison as reported by miners (13 GPUs rig: 5x AMD RX580, 7x NVidia 1070):
CL11.5: Average speed (as observed in logs): 400.309 - ranging: 400.151 MH/s - 400.706 MH/s @ wall wattage: 1620W
PH2.8c: Average speed (5 min): 402.817 MH/s - ranging: 400.926 MH/s - 404.945 MH/s @ wall wattage: 1630W
Observations:
1. Can confirm increased hash rate of 0.62%. (Same settings as CL).
2. The reporting API works as advertised out of the box. Using Claymore's Monitor on Android it just works, reporting the version as: PM2.8c-ETH compared to 11.5-ETH (Claymore).
3. It appears stale shares value is at a similar level to CL. The PH reported % of stale shares is not in sync with pool report (ethermine.org): 1.26% vs 3%
4. Log file entries are detailed and easy to understand.
6. The on-screen run log/report is on a higher level compared to CL. Way more informative and rich with data. Not sure about the (!) next to Share actual difficulty when diff is in GH.
7. As a software engineer I do start counting my GPUs with 0, 1 ... but on the other hand some other SWs such as HWinfo64 are also listing GPUs from 1, 2, 3... Not sure yet how annoying if at all this is.
Will keep this rig running for a while to gather more data on stability and performance. Will report back.
Would be nice for miners to add a migration section (from other miner apps) to PH.
Definitely would be interested to buy a licensed version with devfee 0.
All in all a great alternative miner with better performance and a lower devfee. A solid ****. Excellent job.
Thank you for reporting your findings. We will fix the errors caused by the additional spaces in config.txt in the next release. The GPUs should be ordered in increasing PCIe bus number, which in turn should be roughly the same as the order of the PCIe slots starting from the CPU socket (and also the same order as most hardware control and monitoring programs). We will consider adding an option for alternative GPU ordering but for now this seems the most sensible approach. We are also preparing another improvement that will lower the number of stale shares even further.
Added PhoenixMiner 2.8c to official EthControl software list, great work.
Thank you!
We are happy that the fixes in PM 2.8c are working.
I noticed that PM constantly uses 1.5-2% of CPU power during mining. Why? Can it be reduced?
Hmm, this is too much. What CPU you have and what version of PhoenixMiner you are using? In PhoenixMiner 2.8c and with very slow CPU like Athlon II x2 we are seeing about 0.2-0.5% CPU load.
what is the best gpu for your miner? (ROI)
It's hard to give a definitive answer because it depends too much on the difficulty, ETH price, etc. It is better to maybe use metrics like hashrate per USD (GPU price) and hashrate per watt (power consumption). In these so far the AMD Polaris cards are still the best but if you already have paid back the GPU initial price, the power efficiency of GTX1070 is the best. So, if you are buying GPUs right now - AMD Polaris (RX570 4 or 8 GB because the hashrate is the same as 580; 8 GB if you want to be as future-proof as possible).
I noticed that PM constantly uses 1.5-2% of CPU power during mining. Why? Can it be reduced?
Oh, increased CPU usage is only with -gpow parameter. Without it or with -li option CPU usage is norm - 0-0,5%.
I think that it -gpow bug...
Ah, this explains it. -gpow and -li both work by adding some "sleep" time after each kernel dispatch. -li uses fixed amount of time, which makes it difficult to be sure how much it will decrease the hash-rate but -gpow dynamically recalculates the length of the sleep period. This is both too CPU intensive and too inaccurate if the mining intensity (-mi) is already low (under 5 or 6). So if you want to use low -mi, it is better to use the -li option which is "dumb" but uses less CPU.
Dev Request:
Can you include a feature that "force" or change the seeting for the card(s) to turn on compute mode?
perhaps a command at run time or a flag "-compute 1"
I use blockchain drivers, but switching to newest driver would definitely make it extremely useful!
Thanks.
Yes, it will be included in the next full release.
i use 2.8.c bu what can i do for this error help
gpu: 2 or 4 on more rigs cannot get fan speed, error 999
Lower the memory overclock of the cards that give this error a little (20-40 MHz) and it should go away.
