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

[gsrcrxsi314]

can you please add the -tt command functionality? maybe it works? but its not listed in the readme or command list so i assume its not there currently.

this is my favorite feature on Claymore. auto fan speed control without having other software is extremely useful. without it, the cards to to target 85C and i dont want them running that hot. -tt 70 on claymore keeps eveything nice and kosher.

[1714104210]

1714104210

[deadsix]

Tested on Rx 460, 470 and 570. Works as advertised, Hashrate and power consumption the same as claymore.
Has the advantage of being 0.35% cheaper, but thats about it. It looks and feels eerily similar to claymore.

[phuocduong]

how about nvidia, anyone test?

[RIGED]

read the whole thread
congrats on the Dev for providing an alternative to the greedy2% Claymore which I am currently using for Ethash

i use ONLY VEGA64 and FE and are getting 44.1MH/s per GPUvery stable, but have not seen any one in this thread reporting on this miner in conjuction with my choice of gpu

QUESTIONS TO DEV: do i have to take any additional steps for the buggy Vega64s and the super buggy Frontiers? can i expect at least the same hashing speeds maybe a little faster?
im using moded Reg tables and unlocked SoC with Ntool to regulate GPU values

migration can cause serious issues for my rigs (i have previous experience) as the 64s and FEs are like Supercars, faster than anything around but super sensitive to changing telemetry (and before you start yelling efficiency rating i pay $0.04kW/h so i litteraly dont care about Wattage my concern is max stable hashing speed, in any case they are running at av 180W)

btw DEV, you really want to make a difference? write the miner which will utilise 4 simultaneous  threads for the FE on Cryptonight addressing the 16Gb mem into 4Gb per thread, much like the 2x4Gb on the 64-56 getting 2000H/s from cryptonight.

thnx for the effort

[human75]

i have 5 rigs and this miner works just perfect,without any of the problem that you guys mention on top.it performs much better and stable than claymore.so far so good.thanks to dev.

[syraka76]

New Version??

[PhoenixMiner]

New Version??

  Unfortunately we have found a bug in the new version which caused crashes on few of our test rigs. The good news is that we managed to reproduce it after a few hours and it was fixed but as a result we have run the latest build of 2.5 only for an hour so far, so we are not feeling confident to release it tonight even for a beta test. It will be released first thing tomorrow, unless something else comes up during the overnight testing.

 

QUESTIONS TO DEV: do i have to take any additional steps for the buggy Vega64s and the super buggy Frontiers? can i expect at least the same hashing speeds maybe a little faster?
im using moded Reg tables and unlocked SoC with Ntool to regulate GPU values

migration can cause serious issues for my rigs (i have previous experience) as the 64s and FEs are like Supercars, faster than anything around but super sensitive to changing telemetry (and before you start yelling efficiency rating i pay $0.04kW/h so i litteraly dont care about Wattage my concern is max stable hashing speed, in any case they are running at av 180W)

btw DEV, you really want to make a difference? write the miner which will utilise 4 simultaneous  threads for the FE on Cryptonight addressing the 16Gb mem into 4Gb per thread, much like the 2x4Gb on the 64-56 getting 2000H/s from cryptonight.

   We only have a pair of Vega56s to test here and it seems that right now to get anything Vega-based is mission impossible. On Vega56 we are getting slightly better speed than Claymore but please only test on one rig first, and only after PhoenixMiner 2.5 is released (the official release will be most likely in Wednesday), as we have found that 2.4 and earlier versions can be occasionally unstable on highly overclocked rigs so we've made a lot of stability changes in 2.5.

   While we see a CryptoNight version in our future, for now we are firmly focused on ethash, as we have a lot of features to add to PhoenixMiner.

can you please add the -tt command functionality? maybe it works? but its not listed in the readme or command list so i assume its not there currently.

this is my favorite feature on Claymore. auto fan speed control without having other software is extremely useful. without it, the cards to to target 85C and i dont want them running that hot. -tt 70 on claymore keeps eveything nice and kosher.

  No, it isn't supported in the current version (and won't be included in 2.5) but we have planned for it and we are definitely going to implement -tt and the clocks/voltate options in the near future (at least for AMD cards).

The problem is something else. Let me explain my situation. I have 7 rigs at home out of which 1 was running your miner and other were on claymore. I have another 20 rigs at my warehouse, all running claymore. All 27 rigs are on us1 servers of ethermine. At night all my home rig had connection issue but my warehouse rigs were fine. My internet connection was good as I was able to mine on other pools. us1 servers of ethermine was good as all my warehouse rigs were doing fine. It seems that us1 and eu servers of ethermine were blocking my IP after using your miner.

I dont know what happen but us1 servers of ethermine was good yesterday.

   We have used three different ISPs to analyze the problem and we think we found what is causing it. Basically their servers are extremely busy and sometimes they refuse new connections (the devfee requires a different connection to the pool). This affects all miners but what seems to make matters a bit worse for us is the short default reconnect period of 7 seconds. So in version 2.5 we've increased the reconnect period to 20 seconds and added some failover devfee pools. However the network hashrate is increasing so fast that the pools are going to be strained for some time. It is best to have a least a few failover pools to avoid downtime as much as possible.

[rockk]

how can we set more then 1 failover pool?

[jendabenda]

The problem is something else. Let me explain my situation. I have 7 rigs at home out of which 1 was running your miner and other were on claymore. I have another 20 rigs at my warehouse, all running claymore. All 27 rigs are on us1 servers of ethermine. At night all my home rig had connection issue but my warehouse rigs were fine. My internet connection was good as I was able to mine on other pools. us1 servers of ethermine was good as all my warehouse rigs were doing fine. It seems that us1 and eu servers of ethermine were blocking my IP after using your miner.

I dont know what happen but us1 servers of ethermine was good yesterday.

   We have used three different ISPs to analyze the problem and we think we found what is causing it. Basically their servers are extremely busy and sometimes they refuse new connections (the devfee requires a different connection to the pool). This affects all miners but what seems to make matters a bit worse for us is the short default reconnect period of 7 seconds. So in version 2.5 we've increased the reconnect period to 20 seconds and added some failover devfee pools. However the network hashrate is increasing so fast that the pools are going to be strained for some time. It is best to have a least a few failover pools to avoid downtime as much as possible.


[/quote]

This realy makes phoenix miner hardly usable now, it makes your IP blocked for ethermine (specific pool location). Even my nvidia claymores stops mining..... 

Quite strange is that it wasnt issue before.

[gsrcrxsi314]

8hr update. i know it's early but i have a few observations. i'll keep updating as i go.

6x RX 570
2x RX 580

Baseline:
Claymore v10.0
222 MH/s
long term pool averages very close to this
1080-1090W from the wall
cards hold 70C with the -tt 70 argument

Phoenix:
v2.4
228 MH/s
power consumption is up to 1090-1100W from the wall
cards are running hotter (79C on some cards) due to no fan control yet, i'm stuck with BIOS control (dont want any other software on the machine, Wattman is a nightmare, and MSI afterburner doesnt seem to work at all)
pool average so far has been trending low ~220 MH/s
this average reported in the terminal window as well as on nanopool.
stale share % is low. 2.18% as reported by Phoenix.

maybe just a bit of bad luck, i'll let it ride and see how it does. seems like a solid product. as long as the dev fee doesnt increase, and the mentioned features get added soon, this will be my new miner software.

[rockk]

eu and us ethermine servers are totally unusable these days

[rockk]

is our ip beeing temp banned from ethminer pools cuz of devfee hopping? plz fix. add more time for devfee but more hours till it pops up to avoid it or use other pool for it if possible ty

https://www.reddit.com/r/EtherMining/comments/7to4cs/ethermine_servers_having_issues/


and now not even asia1 server works for me.. wtf\

so i was connected fine to asia1 server, then devfee poped up and said cant connect to asia1. server on wich i was in same console. i think indeed devfee gets us banned on pools or smt.

not 1 pool is working for me wich is impossible, so yeah us phoenix miners are beeing banned at ethermine pools.

switched pools now ok, why we get banned from ethermine?

[polymer_city2]

I have been banned from all ethermine servers.

Please fix this!

 

[benosimo06]

Same experience as many people here. The miner appears to hash as well as a finely tuned Claymore right out of the box, but (and this is a huge BUT) being blocked on multiple pool servers and losing many hours of uptime for this negates any potential benefit.

I also don't appear to be able to run Phoenix at all anymore after these server issues for some reason. Same config/bat files as I've been using for the last few days, but it starts up and fails right after detecting GPUs. The last line of the log is "main ADL library initialized".

I well and truly wish this was working better because competition is nice and it has definite potential.

[nitrobg]

Please use the same GPU indexing across the app. miner.exe -list reports GPU indexes 1,2,3,4 whereas miner.exe -di requires 0123.
It would be less confusing if all indexes start from 0, just like in all other miners.

[yyyam2]

i have changed from ethermine to nanopool. It seems ok now. When devfee start mining, it connect to ethermine pool and disconnect immediately.

[PhoenixMiner]

UPDATE on Jan 1, 2018: The problem is fully resolved, thanks to ehtermine.org. You can mine Ethereum (including on ethermine and ethpool pools) with all versions of PhoenixMiner. Here is the old message for reference:

Please avoid using PhoenixMiner on ehtermine or ethpool. It appears that they have something against our miner and this is quite unfortunate because we were using them for devfee.   If you want to use ethermine or ehtpool, please use another miner for now to avoid connection issues. All other pools seem to work fine but the devfee is messing the things up when mining Ethereum. The new version of PhoenixMiner without any usage of ehtermine/ethpool for devfee will be posted here in less than an hour.

Please take our deep apologies about these problems but we had no way to foresee that as we have tested PhoenixMiner privately for many weeks before releasing the first version and we haven't had any issues with them at that time.  

If you mine any coin other than Ethereum you are not affected by this. With the new version, the problem will go away for all other pools except ethermine/ethpool.

[PhoenixMiner]

PhoenixMiner 2.5d is released (see the first post of the theme for details). If you are using older version of PhoenixMiner and you want to mine Ethereum, you must upgrade to 2.5d to avoid connection issues. Here is the download link:

(MEGA links are no longer active)

New in version 2.5d:

• Removed the usage of ethermine/ethpool for devfee to avoid connection issues
• Added -eres command-line option to allocate DAG buffers big enough for 2 or more DAG epochs after the current one
• New OpenCL initialization code for better stability on DAG generation in multi-GPU rigs
• Stop mining if the connection can't be restored after some time to avoid wasting electricity
• Recognize failed connection attempt even if the pool doesn't close the socket
• Longer reconnect delay
• Several other small changes and impovments, mainly for stability

[dohfish]

Yes, new account user posting about PhoenixMiner, hot damn! (Old one got hacked).

I have been using 2.4 for some time, a good 8-10 hours yesterday and got hit with the IP block aswell, I reached out to ethermine.org and just got this reply back:

"The dev fee mining of the Phoenix miner on ethermine triggered our botnet detection and caused a temporary IP block. We have now adjusted our botnet detection system which resolved the problem. We are very sorry for the inconvenience. In general we encourage mining software devs to reach out to us prior to making their software generally available in order to avoid such issues. From the point of view of a mining pool dev-fee miners look exactly the same as botnets."

It appears that the issue even with 2.4 should be resolved in that case, but as a DEV please reach out to them and work with them to solve issues like this.

You most likely did not see this problem as there were too few actually using your miners.

[yyyam2]

which server are you using? I cant connect to nanopool somehow?

eth-asia1.nanopool.org:9999