PhoenixMiner 3.5d: fastest Ethereum/Ethash miner with lowest devfee (Win/Linux)

[axe0911]

i think im in error ,but i see miner restard because low hash....
i removed -minRigSpeed 129  after , and now ,no anymore probleme .....

  The -minRigSpeed option works with 5 minutes average hashrate. It doesn't care about the effective hashrate, because it can be quite random. So if the 5 min average hashrate speed drops under 129 MH/s in your case, the miner will be restarted. To avoid unnecessary restarting, put this option to your normal hashrate minus about half of one card's hasrate. I.e. if your normal hashrate is 132 MH/s with 5 GPUs, set -minRigSpeed 119

This will be work  (-cclock 1150 -mclock 2170 -cvddc 850 -mvddc 850)  with this minner??? Or how to set the clocks?

  There is no support for these options yet. We are working on it and it will be released in version 2.7b.

2.7 has almost 2x more stales then 2.6

  There is no reason for that - should be the same or slightly lower. We have seen some wild variations on stales because of luck (when the average block time drops and a few blocks are found in quick succession there are a lot more stale shares). We will include pool stats in a later version to show the average round time, latencly, etc.

yup , watchdog work fine ,phoenix 2.7a working fine , ( i desactivated a gpu in windows/hardware )
phoenix found a probleme and restart , good.

but i dont have see security about T°c  limit ,when a card reach 90°C
stop made it minnning for 5 minutes for cold down & restart it ?

im a bit crazy but i will leave rig 3 weeks .....

got usb watchdog key working fine , phoenix have watchdog for GPU ....
sonoff for restart rig when probleme

just "need" GPU T° check for security / dont burn/kill it ....

  You mean like -tstop and -tstart options of Claymore? We will try to include these in 2.7.

I have seen a small 1.5-2% speed improvement poolside over Claymore 11.0 on my Nvidia 1060 rig.  Thank you.

My RX-480 cards are also 2-5% faster but not enough improvement to keep them on Ethash.  Their MH/s output has dropped 33% in the last few months.  Flashed a few BIOs and tweeked with Afterburner.  Is there a magic bullet to regain old speeds to 480s or is this the new norm for ETH algo?

  33% drop in hashrates? It looks like you are not using the blockchain driver (or the newest AMD drivers switched to COMPUTE mode). Please google AMD blockchain driver and install it (after removing the current driver with DDU).

some people seems to test it already 2.7a

  You can find 2.7a in this post: https://bitcointalk.org/index.php?topic=2647654.msg30259176#msg30259176 but please note that it is a beta release - do not try it on a large scale (i.e. multple rigs). We test each beta version for at least 12-24 hours on about a dozen testing rigs with various GPUs but the configurations in the field are much more diverse than our test rigs so some errors can't be found in this testing.

Truly a great miner.

I have been facing a challenge when one of the GPU hangs, the miner does not restart.

It gives an error that reboot.bat couldn't be located.

Also, why is the GPU hanging ?

Code:

17580:04:04:52.516: eths Eth: Received: {"id":0,"jsonrpc":"2.0","result":["0x289abbab48807a4927ff272c8d39ff2d1460bd952c7228c4c98536ca6a554c44","0x4e99a30e99712c8c6e292fe7ba6b27a37c7ced12e2ec7862f31fb676724cb404","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x4df57e"]}
17580:04:04:52.516: eths Eth: New job #289abbab from asia1.ethermine.org:4444; diff: 4000MH
17580:04:04:52.990: main Eth speed: 57.131 MH/s, shares: 284/0/0, time: 5:16
17580:04:04:52.990: main GPUs: 1: 28.367 MH/s (142) 2: 28.763 MH/s (142)
17580:04:04:59.633: main Eth speed: 56.980 MH/s, shares: 284/0/0, time: 5:16
17580:04:04:59.633: main GPUs: 1: 28.374 MH/s (142) 2: 28.606 MH/s (142)
17580:04:04:59.677: eths Eth: Send: {"id":6,"jsonrpc":"2.0","method":"eth_submitHashrate","params":["0x36496db","0xdf1e1ca4401117200633d5a343be0ae9c05e3d9e630c497b76f2409afb2b402e"]}

17580:04:04:59.772: eths Eth: Received: {"id":6,"jsonrpc":"2.0","result":true}
17580:04:05:04.687: main Eth speed: 22.871 MH/s, shares: 284/0/0, time: 5:16
17580:04:05:04.687: main GPUs: 1: 0.000 MH/s (142) 2: 22.871 MH/s (142)
17580:04:05:08.344: main GPU1: 59C 17%, GPU2: 67C 17%
17580:04:05:09.686: eths Eth: Send: {"id":5,"jsonrpc":"2.0","method":"eth_getWork","params":[]}

17580:04:05:09.766: main Eth speed: 28.610 MH/s, shares: 284/0/0, time: 5:16
17580:04:05:09.766: main GPUs: 1: 0.000 MH/s (142) 2: 28.610 MH/s (142)
17580:04:05:09.778: eths Eth: Received: {"id":5,"jsonrpc":"2.0","result":["0x289abbab48807a4927ff272c8d39ff2d1460bd952c7228c4c98536ca6a554c44","0x4e99a30e99712c8c6e292fe7ba6b27a37c7ced12e2ec7862f31fb676724cb404","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x4df57e"]}
17580:04:05:14.845: main Eth speed: 28.609 MH/s, shares: 284/0/0, time: 5:16
17580:04:05:14.845: main GPUs: 1: 0.000 MH/s (142) 2: 28.609 MH/s (142)
17580:04:05:19.687: eths Eth: Send: {"id":5,"jsonrpc":"2.0","method":"eth_getWork","params":[]}

17580:04:05:19.687: eths Eth: Send: {"id":6,"jsonrpc":"2.0","method":"eth_submitHashrate","params":["0x34c999c","0xdf1e1ca4401117200633d5a343be0ae9c05e3d9e630c497b76f2409afb2b402e"]}

17580:04:05:19.781: eths Eth: Received: {"id":5,"jsonrpc":"2.0","result":["0x289abbab48807a4927ff272c8d39ff2d1460bd952c7228c4c98536ca6a554c44","0x4e99a30e99712c8c6e292fe7ba6b27a37c7ced12e2ec7862f31fb676724cb404","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x4df57e"]}
17580:04:05:19.873: eths Eth: Received: {"id":5,"jsonrpc":"2.0","result":["0x289abbab48807a4927ff272c8d39ff2d1460bd952c7228c4c98536ca6a554c44","0x4e99a30e99712c8c6e292fe7ba6b27a37c7ced12e2ec7862f31fb676724cb404","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x4df57e"]}
17580:04:05:19.873: eths Eth: Received: {"id":6,"jsonrpc":"2.0","result":true}
17580:04:05:19.923: main  
17580:04:05:19.923: main Eth: Mining ETH on asia1.ethermine.org:4444
17580:04:05:19.923: main Eth speed: 28.607 MH/s, shares: 284/0/0, time: 5:17
17580:04:05:19.923: main GPUs: 1: 0.000 MH/s (142) 2: 28.607 MH/s (142)
17580:04:05:19.923: main Eth: Accepted shares 284 (8 stales), rejected shares 0 (0 stales)
17580:04:05:19.923: main Eth: Incorrect shares 0 (0.00%), est. stales percentage 2.82%
17580:04:05:19.923: main Eth: Maximum difficulty of found share: 1274.3 GH (!)
17580:04:05:19.923: main Eth: Average speed (5 min): 54.926 MH/s
17580:04:05:19.923: main Eth: Effective speed: 59.71 MH/s; at pool: 59.71 MH/s
17580:04:05:19.923: main  
17580:04:05:25.002: main Eth speed: 28.243 MH/s, shares: 284/0/0, time: 5:17
17580:04:05:25.002: main GPUs: 1: 0.000 MH/s (142) 2: 28.243 MH/s (142)
17580:04:05:29.688: eths Eth: Send: {"id":5,"jsonrpc":"2.0","method":"eth_getWork","params":[]}

17580:04:05:29.782: eths Eth: Received: {"id":5,"jsonrpc":"2.0","result":["0x289abbab48807a4927ff272c8d39ff2d1460bd952c7228c4c98536ca6a554c44","0x4e99a30e99712c8c6e292fe7ba6b27a37c7ced12e2ec7862f31fb676724cb404","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x4df57e"]}
17580:04:05:30.096: main Eth speed: 28.617 MH/s, shares: 284/0/0, time: 5:17
17580:04:05:30.096: main GPUs: 1: 0.000 MH/s (142) 2: 28.617 MH/s (142)
17580:04:05:35.175: main Eth speed: 28.605 MH/s, shares: 284/0/0, time: 5:17
17580:04:05:35.175: main GPUs: 1: 0.000 MH/s (142) 2: 28.605 MH/s (142)
17580:04:05:36.394: main GPU1: 54C 17%, GPU2: 67C 17%
17580:04:05:39.689: eths Eth: Send: {"id":5,"jsonrpc":"2.0","method":"eth_getWork","params":[]}

17580:04:05:39.689: eths Eth: Send: {"id":6,"jsonrpc":"2.0","method":"eth_submitHashrate","params":["0x32eb4a9","0xdf1e1ca4401117200633d5a343be0ae9c05e3d9e630c497b76f2409afb2b402e"]}

17580:04:05:39.783: eths Eth: Received: {"id":5,"jsonrpc":"2.0","result":["0x289abbab48807a4927ff272c8d39ff2d1460bd952c7228c4c98536ca6a554c44","0x4e99a30e99712c8c6e292fe7ba6b27a37c7ced12e2ec7862f31fb676724cb404","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x4df57e"]}
17580:04:05:39.876: eths Eth: Received: {"id":5,"jsonrpc":"2.0","result":["0x289abbab48807a4927ff272c8d39ff2d1460bd952c7228c4c98536ca6a554c44","0x4e99a30e99712c8c6e292fe7ba6b27a37c7ced12e2ec7862f31fb676724cb404","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x4df57e"]}
17580:04:05:39.876: eths Eth: Received: {"id":6,"jsonrpc":"2.0","result":true}
17580:04:05:40.285: main Eth speed: 28.604 MH/s, shares: 284/0/0, time: 5:17
17580:04:05:40.285: main GPUs: 1: 0.000 MH/s (142) 2: 28.604 MH/s (142)
17580:04:05:45.364: main Eth speed: 28.601 MH/s, shares: 284/0/0, time: 5:17
17580:04:05:45.364: main GPUs: 1: 0.000 MH/s (142) 2: 28.601 MH/s (142)
17580:04:05:49.690: eths Eth: Send: {"id":5,"jsonrpc":"2.0","method":"eth_getWork","params":[]}

17580:04:05:49.783: eths Eth: Received: {"id":5,"jsonrpc":"2.0","result":["0x289abbab48807a4927ff272c8d39ff2d1460bd952c7228c4c98536ca6a554c44","0x4e99a30e99712c8c6e292fe7ba6b27a37c7ced12e2ec7862f31fb676724cb404","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x4df57e"]}
17580:04:05:50.442: main Eth speed: 28.606 MH/s, shares: 284/0/0, time: 5:17
17580:04:05:50.442: main GPUs: 1: 0.000 MH/s (142) 2: 28.606 MH/s (142)
17580:04:05:54.128: wdog GPU1 not responding
17580:04:05:54.128: wdog Thread(s) not responding. Restarting.
17580:04:05:55.552: main Eth speed: 28.604 MH/s, shares: 284/0/0, time: 5:17
17580:04:05:55.552: main GPUs: 1: 0.000 MH/s (142) 2: 28.604 MH/s (142)

  Please check your command-line options: if you have -rmode 2 (or -r 1), remove it as it forces the miner to try and run the reboot.bat file in the same folder as the miner instead of just restarting the PhoenixMiner.exe with the same options. As for the reason for freezing of GPU1, it is either too high clocks or too low voltage (or combination of both). Please note the the current version of PhoenixMiner doesn't support the hardware control options (-cvddc, -mvddc, etc.). They will be added in the upcoming 2.7b and for now you have to rely on third-party program for controlling the clocks and voltages of the GPUs.

That worked. However, after auto restarting PhoenixMiner.exe, one of my GPU's OC gets removed. I think I will wait for the version that supports Overclocking.

[flatounet]

yup , watchdog work fine ,phoenix 2.7a working fine , ( i desactivated a gpu in windows/hardware )
phoenix found a probleme and restart , good.

but i dont have see security about T°c  limit ,when a card reach 90°C
stop made it minnning for 5 minutes for cold down & restart it ?

im a bit crazy but i will leave rig 3 weeks .....

got usb watchdog key working fine , phoenix have watchdog for GPU ....
sonoff for restart rig when probleme

just "need" GPU T° check for security / dont burn/kill it ....

  You mean like -tstop and -tstart options of Claymore? We will try to include these in 2.7.

yes i talk about -tstop -tstart . very welcome here

i leave home in 2 weeks
thank's you

[kadok29]

hi, i'm mining with 12 gpu rig.....

all my gpy working ok at 29 mh/s... but when i turn off or disconnect the screen....  mi hashrate on gpu 0  goes to 5 mh/s....

what is the problem?

can anyone help?

[janding]

hi, i'm mining with 12 gpu rig.....

all my gpy working ok at 29 mh/s... but when i turn off or disconnect the screen....  mi hashrate on gpu 0  goes to 5 mh/s....

what is the problem?

can anyone help?

Is your monitor connected to the hdmi port on the GPU that drops speed when you turn it off ?

[dagarair]

For a guy like me with a ton of miners I would really like to see a global update or a push feature to push an update from a main console.  Claymore has this issue as well so it's not just you all.  But for a guy that has 50-100 + miners man it would rock.  That is what makes linux so nice.  I'm half and half right now but might go full linux because of the console push features.

Hats off to you all though.  You are for sure getting better by far since 2.3!  Testing 2.6 on 10 machines again.

[kadok29]

hi, i'm mining with 12 gpu rig.....

all my gpy working ok at 29 mh/s... but when i turn off or disconnect the screen....  mi hashrate on gpu 0  goes to 5 mh/s....

what is the problem?

can anyone help?

Is your monitor connected to the hdmi port on the GPU that drops speed when you turn it off ?

yes, connected on hdmi port on the GPU

[janding]

hi, i'm mining with 12 gpu rig.....

all my gpy working ok at 29 mh/s... but when i turn off or disconnect the screen....  mi hashrate on gpu 0  goes to 5 mh/s....

what is the problem?

can anyone help?

Is your monitor connected to the hdmi port on the GPU that drops speed when you turn it off ?

yes, connected on hdmi port on the GPU

There have been known issues connecting a monitor to a GPU port used for mining.
Here are 2 things you can try.

1.) Plug the monitor into a different GPU and see if that works. The problem may follow where the monitor is connected.
2.) Install a standard video card in that system connect your monitor on that instead of the GPU. ( best suggestion )

It's not recommended to use a monitor on a GPU your mining on.
May work, may not.

[flatounet]

monitor on rig is just for install win ,few driver & go ,

after i use teamviewers ( free ) ....
or pool for see if all was good ,u dont need monitor after....

[LiviuStefann]

I've been using this miner for few days.... v2.6. It seems to me, that phoenix miner is working a lot better than claymore on ethermine pool.    One rig is running for +100h, one half of that. Both rigs - 6strix 1070, mobo strix 270e, cpu g4400, ssd, corsair ram, corsair hx PSU.
In my case... phoenix rules!
https://imgur.com/LzSfTtS
https://imgur.com/ykd6dLI
https://imgur.com/vJWk7Fu

[Rufgenia]

Hello,

need option for controlling fanspeed like claymore " -tt 60 -fanmin 75 " for example.

[Bwaite43]

Any update on the Linux version?

[cryptoreporting]

Linux version please 😩

[dohfish]

Phoenixminer,
My rig config: win 10 pro, 6 x msi 570 gaming x 4G, mining at Nanopool, mclock 2030, vcddc 870, cclock 1100, vcore 950, fan 80%.

Miners 2.6 and 2.7a both crash win, BSOD. Claymore doesn’t, but it resets the voltages and clocks after sometime after the decree sessions I guess. Now I’m running 2.7a with -mi 8. This reduces the local hashrate to around 173 from 175 of claymore.

Please look into this issue.

Thank you.

Try give them more voltage and test the miner first. If you can run for 24hrs stable, try decrease the voltage. For my experience, the claymore hardware control is not so stable. I am now using overdrivetools to control. It 's easy to use.

Then Phoenix draws more power than claymore with reduced hashrate. I’ll wait. Thanks for the tip.

What you are seeing is that your clocks are not stable, software access the systems in different ways which can make it behave differently.

2030 is per my experience quite high for a 570, I have only a single card (570) which are stable at 2030+ - The median is 2000 on memory for my 120 rx570's

[P00P135]

https://www.virustotal.com/#/file/237d6f3f781d9a4a718559c956d2da0bf81e82c374e7ce6dca44e397bcd404ff/detection

Detected 9 times for specifically Troj.Win64.Wdfload   

[janding]

https://www.virustotal.com/#/file/237d6f3f781d9a4a718559c956d2da0bf81e82c374e7ce6dca44e397bcd404ff/detection

Detected 9 times for specifically Troj.Win64.Wdfload   

Just curious.
Would you happen to have a list of all the miners that show 100% clean when ran against
any virus detecting software. I will switch to that one.

[ckai93]

a few hours back pool shows that rig went offline but the miner still submit shares.
i've restarted the miner and still submit shares as usual but pool still doesn't show that.
been in touch with ethermine support but they insist that it wasn't a server side fault.

still not sure if it was a pool or miner issue but till then, i'll continue using claymore.

[miner_in_bkk]

My rig had the same issues as well.

Has yours corrected itself yet ?

[zeii]

I have many Incorrect shares after switching DAG size.
Could you please add commands to restart miner when get more than xx incorrect shares?
I mine to nicehash and found this problem every time when switch DAG size.(if not switch DAG,they not have any incorrect share)
Rig Rx560 4Gb.
Thank you.

[Bungadek]

a few hours back pool shows that rig went offline but the miner still submit shares.
i've restarted the miner and still submit shares as usual but pool still doesn't show that.
been in touch with ethermine support but they insist that it wasn't a server side fault.

still not sure if it was a pool or miner issue but till then, i'll continue using claymore.

Had the same issue connected to the asia1.ethermine.org. Looks like the difficulty had been raised on that pool too?

Switched to the us server for now and it’s reporting as normal.

Be good to know if you hear anything back!

[tenmoi]

Phoenixminer,
My rig config: win 10 pro, 6 x msi 570 gaming x 4G, mining at Nanopool, mclock 2030, vcddc 870, cclock 1100, vcore 950, fan 80%.

Miners 2.6 and 2.7a both crash win, BSOD. Claymore doesn’t, but it resets the voltages and clocks after sometime after the decree sessions I guess. Now I’m running 2.7a with -mi 8. This reduces the local hashrate to around 173 from 175 of claymore.

Please look into this issue.

Thank you.

Try give them more voltage and test the miner first. If you can run for 24hrs stable, try decrease the voltage. For my experience, the claymore hardware control is not so stable. I am now using overdrivetools to control. It 's easy to use.

Then Phoenix draws more power than claymore with reduced hashrate. I’ll wait. Thanks for the tip.

What you are seeing is that your clocks are not stable, software access the systems in different ways which can make it behave differently.

2030 is per my experience quite high for a 570, I have only a single card (570) which are stable at 2030+ - The median is 2000 on memory for my 120 rx570's

Thanks a lot for the info on mem clocks. And as you’re running lots of rx 570, could you help me solve this problem with one of my cards: I set fan speed to 100% in afterburner 4.4.2 but claymore reports 90% and this number never goes higher, so the GPU hits 57C. I’m asking because the other 5 report higher 95-96% fan speed and are running cool at 50C.
Is this a hardware issue? I have reinstalled windows but the problem persists.

Thank you.