PhoenixMiner 6.2c: fastest Ethereum/Ethash miner with lowest devfee (Win/Linux)

[aurus33]

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.

[1713966630]

1713966630

[1713966630]

1713966630

[1713966630]

1713966630

[gsrcrxsi314]

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.

upgrade to the new drivers. the blockchain drivers are buggy as hell.

new drivers (driver only package) + compute mode switcher = profit.

[Digital_Seytan]

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

 

[gsrcrxsi314]

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

 

too much overclock

[human75]

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.

upgrade to the new drivers. the blockchain drivers are buggy as hell.

new drivers (driver only package) + compute mode switcher = profit.

Afterburner won't recognise new driver at all.
if you have mixed rig like me then new drivers are useless. because i give different oc value each card.

[skinnyfalcon]

Updated from 2.7 to 2.8c:
Everything is running quite stable (there is a very peculiar hash drop on individual cards, occurs very rarely and beck up to normal after 2-3 min). The average stale has dropped from 2-3% down to 0.6-0.7%, however the overall hash rate does not seem to have improved.
https://media.discordapp.net/attachments/377248766828347392/430509035675058208/20180402_192720.jpg?width=761&height=897

[PhoenixMiner]

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.

[Jbodz83]

Went back to Claymore 11.6 - it seems that Phoenixminer could not stabilize their stale shares. as having 11Mhs extra w/ 5-6% stale shares is not that good compared to 1-2$ from ClaymoreMiner 11.6. just my thought..

[milos957]

Thanks to Phoenix Miner Developers for great effort and excellent support. I use the latest AMD driver version 18.3.4, all my rigs work perfectly, all the settings are in the bat file only the card temperature is maintained with the MSI Afterburner: download-eu2.guru3d.com/afterburner/[Guru3D.com]-MSIAfterburnerSetup443Beta4.rar

[MaxMidnite]

Any plans for CryptoNote miner or integration, would be great?

[Jbodz83]

This is my hashrate and stale share percentage in Claymore 11.6

https://image.ibb.co/iz6vBc/ETC.png

Phoenix can tap my RIG up to 395Mhs (13GPU) however, it gives me 5-6% stale share..

i like the hashrate spike from PhoenixMiner, but i guess effeciency goes to Claymore 11.6 - hope that PhoenixMiner could catch up soon..

[janding]

This is my hashrate and stale share percentage in Claymore 11.6



Phoenix can tap my RIG up to 395Mhs (13GPU) however, it gives me 5-6% stale share..

i like the hashrate spike from PhoenixMiner, but i guess effeciency goes to Claymore 11.6 - hope that PhoenixMiner could catch up soon..

I'm waiting on the same fix for stale shares.
I have almost identical results with speed gain but stale shares are just too high with Phoenix.
When that gets solved I'll be back on Phoenix in a flash.

[skinnyfalcon]

This is my hashrate and stale share percentage in Claymore 11.6

https://image.ibb.co/iz6vBc/ETC.png

Phoenix can tap my RIG up to 395Mhs (13GPU) however, it gives me 5-6% stale share..

i like the hashrate spike from PhoenixMiner, but i guess effeciency goes to Claymore 11.6 - hope that PhoenixMiner could catch up soon..

Your screen shot doesn't show the stale shares (%). what you are seeing is Valid Share/Rejected Share/Bad Share. Even with v2.7c I only had 2.6% stale, after updating to 2.8c its down to 0.58%. And your Rejected shares are quite high 3 rejected in 404 valid, I have 0 rejected and only 0.01% invalid. So something is not right in your configuration.

[janding]

This is my hashrate and stale share percentage in Claymore 11.6



Phoenix can tap my RIG up to 395Mhs (13GPU) however, it gives me 5-6% stale share..

i like the hashrate spike from PhoenixMiner, but i guess effeciency goes to Claymore 11.6 - hope that PhoenixMiner could catch up soon..

Your screen shot doesn't show the stale shares (%). what you are seeing is Valid Share/Rejected Share/Bad Share. Even with v2.7c I only had 2.6% stale, after updating to 2.8c its down to 0.58%. And your Rejected shares are quite high 3 rejected in 404 valid, I have 0 rejected and only 0.01% invalid. So something is not right in your configuration.

I'm guessing you are getting your stale share numbers from the miner display window which is totally inaccurate.
And yes he is showing the accurate stale share rate of 1%
The numbers you see are Valid   Shares / Stale Shares / Invalid Shares

[jimsta]

Glad to be able to try Phoenix Miner, I'm mainly an AMD miner across 3 rigs.  I did notice that Phoenix miner on a 9 card AMD rig mixed of rx 570/580 pulled an extra 20 watts (from the wall) compared to the 1180 (from the wall) of Claymore 11.4, not a biggie because it's so small but I'm just a bit curious.

Hashrate is the same between both.

my other rig which is a smorgasboard of different brands of cards is about 4-5 MH/s lower using phoenix.

Is it possible to customize the GT/DCRI for each individual card?

I like the output and format of Phoenix way better but at this moment only using it on 2 of my rigs (the other Nvidia).

Thanks for the miner!

[Jbodz83]

This is my hashrate and stale share percentage in Claymore 11.6

https://image.ibb.co/iz6vBc/ETC.png

Phoenix can tap my RIG up to 395Mhs (13GPU) however, it gives me 5-6% stale share..

i like the hashrate spike from PhoenixMiner, but i guess effeciency goes to Claymore 11.6 - hope that PhoenixMiner could catch up soon..

Your screen shot doesn't show the stale shares (%). what you are seeing is Valid Share/Rejected Share/Bad Share. Even with v2.7c I only had 2.6% stale, after updating to 2.8c its down to 0.58%. And your Rejected shares are quite high 3 rejected in 404 valid, I have 0 rejected and only 0.01% invalid. So something is not right in your configuration.

Sorry, i didnt get you, this SS if you can see in the right its 404 valid 3 stales (1%) 0 Invalid (0%) - unfortunately, i am not looking in my miners results sir. thats why i shared the screenshot directly from pool. well.. cant have this kind of percentage of stale share in PhoenixMiner. something is wrong with your reference i guess?

Thanks for sharing your experience by the way - check the pool not the miner's result sir

[j2james]

Hi Phoenix, can you change time logging in the next release to be more user friendly?

Now you use format

17625:02:43:37.171

But for me 17625 looks strange. I really do not know what is it. Can you log date instead of 17625?

Another point. I use -minRigSpeed 188 option. It should do restart if avg hashrate is less then 188 during last 5 minutes. But this is not true. Please look at log. Only 1 minute I had hashrate less then 188. Not 5 minutes, but rig was rebooted

Code:

	Line 169001: 17625:12:01:00.948: main Eth speed: 192.206 MH/s, shares: 2537/0/2, time: 36:32
	Line 169008: 17625:12:01:06.018: main Eth speed: 193.469 MH/s, shares: 2537/0/2, time: 36:32
	Line 169013: 17625:12:01:11.088: main Eth speed: 191.407 MH/s, shares: 2537/0/2, time: 36:33
	Line 169026: 17625:12:01:16.158: main Eth speed: 191.587 MH/s, shares: 2537/0/2, time: 36:33
	Line 169029: 17625:12:01:21.228: main Eth speed: 191.606 MH/s, shares: 2537/0/2, time: 36:33
	Line 169034: 17625:12:01:26.231: main Eth speed: 191.135 MH/s, shares: 2537/0/2, time: 36:33
	Line 169036: 17625:12:01:31.246: main Eth speed: 190.546 MH/s, shares: 2537/0/2, time: 36:33
	Line 169047: 17625:12:01:36.251: main Eth speed: 191.941 MH/s, shares: 2537/0/2, time: 36:33
	Line 169049: 17625:12:01:41.256: main Eth speed: 190.582 MH/s, shares: 2537/0/2, time: 36:33
	Line 169055: 17625:12:01:46.256: main Eth speed: 189.725 MH/s, shares: 2537/0/2, time: 36:33
	Line 169057: 17625:12:01:51.302: main Eth speed: 190.850 MH/s, shares: 2537/0/2, time: 36:33
	Line 169067: 17625:12:01:56.310: main Eth speed: 190.770 MH/s, shares: 2537/0/2, time: 36:33
	Line 169075: 17625:12:02:01.310: main Eth speed: 190.820 MH/s, shares: 2537/0/2, time: 36:33
	Line 169082: 17625:12:02:06.312: main Eth speed: 192.562 MH/s, shares: 2537/0/2, time: 36:33
	Line 169084: 17625:12:02:11.514: main Eth speed: 190.879 MH/s, shares: 2537/0/2, time: 36:34
	Line 169092: 17625:12:02:16.515: main Eth speed: 190.799 MH/s, shares: 2537/0/2, time: 36:34
	Line 169094: 17625:12:02:21.518: main Eth speed: 190.793 MH/s, shares: 2537/0/2, time: 36:34
	Line 169099: 17625:12:02:26.518: main Eth speed: 190.781 MH/s, shares: 2537/0/2, time: 36:34
	Line 169101: 17625:12:02:31.518: main Eth speed: 190.915 MH/s, shares: 2537/0/2, time: 36:34
	Line 169116: 17625:12:02:36.519: main Eth speed: 190.963 MH/s, shares: 2538/0/2, time: 36:34
	Line 169121: 17625:12:02:41.522: main Eth speed: 190.766 MH/s, shares: 2538/0/2, time: 36:34
	Line 169133: 17625:12:02:46.579: main Eth speed: 190.568 MH/s, shares: 2538/0/2, time: 36:34
	Line 169143: 17625:12:02:51.590: main Eth speed: 190.527 MH/s, shares: 2539/0/2, time: 36:34
	Line 169150: 17625:12:02:56.591: main Eth speed: 190.601 MH/s, shares: 2539/0/2, time: 36:34
	Line 169154: 17625:12:03:01.604: main Eth speed: 190.593 MH/s, shares: 2539/0/2, time: 36:34
	Line 169159: 17625:12:03:06.604: main Eth speed: 190.677 MH/s, shares: 2539/0/2, time: 36:34
	Line 169164: 17625:12:03:11.606: main Eth speed: 190.855 MH/s, shares: 2539/0/2, time: 36:35
	Line 169173: 17625:12:03:16.608: main Eth speed: 190.845 MH/s, shares: 2539/0/2, time: 36:35
	Line 169175: 17625:12:03:21.611: main Eth speed: 189.304 MH/s, shares: 2539/0/2, time: 36:35
	Line 169183: 17625:12:03:26.611: main Eth speed: 190.948 MH/s, shares: 2539/0/2, time: 36:35
	Line 169191: 17625:12:03:31.613: main Eth speed: 190.941 MH/s, shares: 2539/0/2, time: 36:35
	Line 169198: 17625:12:03:36.630: main Eth speed: 190.786 MH/s, shares: 2539/0/2, time: 36:35
	Line 169203: 17625:12:03:41.634: main Eth speed: 191.880 MH/s, shares: 2539/0/2, time: 36:35
	Line 169208: 17625:12:03:46.683: main Eth speed: 190.897 MH/s, shares: 2539/0/2, time: 36:35
	Line 169210: 17625:12:03:51.687: main Eth speed: 191.073 MH/s, shares: 2539/0/2, time: 36:35
	Line 169217: 17625:12:03:56.689: main Eth speed: 191.021 MH/s, shares: 2539/0/2, time: 36:35
	Line 169219: 17625:12:04:01.693: main Eth speed: 190.925 MH/s, shares: 2539/0/2, time: 36:35
	Line 169225: 17625:12:04:06.696: main Eth speed: 190.788 MH/s, shares: 2539/0/2, time: 36:35
	Line 169230: 17625:12:04:11.698: main Eth speed: 190.634 MH/s, shares: 2539/0/2, time: 36:36
	Line 169243: 17625:12:04:16.698: main Eth speed: 190.537 MH/s, shares: 2539/0/2, time: 36:36
	Line 169245: 17625:12:04:21.700: main Eth speed: 190.440 MH/s, shares: 2539/0/2, time: 36:36
	Line 169252: 17625:12:04:26.703: main Eth speed: 190.492 MH/s, shares: 2539/0/2, time: 36:36
	Line 169254: 17625:12:04:31.704: main Eth speed: 190.597 MH/s, shares: 2539/0/2, time: 36:36
	Line 169262: 17625:12:04:36.716: main Eth speed: 190.594 MH/s, shares: 2539/0/2, time: 36:36
	Line 169266: 17625:12:04:41.723: main Eth speed: 190.437 MH/s, shares: 2539/0/2, time: 36:36
	Line 169271: 17625:12:04:46.737: main Eth speed: 190.413 MH/s, shares: 2539/0/2, time: 36:36
	Line 169273: 17625:12:04:51.777: main Eth speed: 190.313 MH/s, shares: 2539/0/2, time: 36:36
	Line 169293: 17625:12:04:56.778: main Eth speed: 190.389 MH/s, shares: 2540/0/2, time: 36:36
	Line 169301: 17625:12:05:01.812: main Eth speed: 190.256 MH/s, shares: 2540/0/2, time: 36:36
	Line 169307: 17625:12:05:06.966: main Eth speed: 187.663 MH/s, shares: 2540/0/2, time: 36:36
	Line 169309: 17625:12:05:12.163: main Eth speed: 179.329 MH/s, shares: 2540/0/2, time: 36:37
	Line 169322: 17625:12:05:17.163: main Eth speed: 155.063 MH/s, shares: 2541/0/2, time: 36:37
	Line 169324: 17625:12:05:22.288: main Eth speed: 111.250 MH/s, shares: 2541/0/2, time: 36:37
	Line 169329: 17625:12:05:27.525: main Eth speed: 85.712 MH/s, shares: 2541/0/2, time: 36:37
	Line 169332: 17625:12:05:32.705: main Eth speed: 115.706 MH/s, shares: 2541/0/2, time: 36:37
	Line 169339: 17625:12:05:37.775: main Eth speed: 163.700 MH/s, shares: 2541/0/2, time: 36:37
	Line 169346: 17625:12:05:42.811: main Eth speed: 173.852 MH/s, shares: 2541/0/2, time: 36:37

Code:

17625:12:05:42.811: main *** 36:37 ***************************************************
17625:12:05:42.811: main Eth: Mining ETH on eth-eu1.nanopool.org:9999
17625:12:05:42.811: main Eth speed: 173.852 MH/s, shares: 2541/0/2, time: 36:37
17625:12:05:42.811: main GPUs: 1: 29.437 MH/s (390) 2: 28.839 MH/s (437/1) 3: 29.572 MH/s (445/1) 4: 28.203 MH/s (451) 5: 29.520 MH/s (396) 6: 28.282 MH/s (422)
17625:12:05:42.811: main Eth: Accepted shares 2541 (27 stales), rejected shares 0 (0 stales)
17625:12:05:42.811: main Eth: Incorrect shares 2 (0.08%), est. stales percentage 1.06% 
17625:12:05:42.811: main Eth: Maximum difficulty of found share: 46.1 TH (!!!)
17625:12:05:42.811: main Eth: Average speed (5 min): 184.180 MH/s
17625:12:05:42.811: main Eth: Effective speed: 192.72 MH/s; at pool: 192.72 MH/s
17625:12:05:42.811: main  
17625:12:05:42.811: main Average ethash speed for 5 min is below minimum of 188 MH/s. Restarting!

[j2james]

Hi Phoenix,

Can you think about new option in miner to switch to next pool from epools if average (for 5 minutes, for example) share accepting time is more then configured? It will require to define for each pool its own time. Also may be some conditions should be used to back to previous pool. I think if you will like this idea, you will find the best solution for this issue.

[Bigdrago]

Do this have the same autotune function as claymore?

[j2james]

Anybody knows why invalid shares is present? I'm in mining about 3 months, but only yesterday I had two invalid shares (on different cards). I use Phoenix miner now and use it about a week. Before that I used Claymore. And only yesterday I had caught 2 invalid shares. Can it be result of overclocking or no? Is it normal or no?