Topic: PhoenixMiner 6.2c: fastest Ethereum/Ethash miner with lowest devfee (Win/Linux) - page 371. (Read 784958 times)

Long story short Windows was giving me trouble lately, so I switched to Hive OS (Linux). Got Phoenix 3.5d working perfectly. Noticed on my pool that I wasn't mining anymore more but my rig was still drawing the same amount of power. Checked the monitor and saw that Phoenix was stuck in the DevFee. Tried it again a few days ago and it did the same thing. So I am back using Claymore. Any ideas on how to fix this on my end or is it a known bug that is being worked on? Love Phoenix but can't mine solely for the Devs

Hive OS - 0.5.82
Phoenix Miner - 3.5d
5 RX 480's and 1 1070ti
Mining Ethereum and ETC

Thank you guys, for me it is better than claymore, my rig 8 x RX570:

with claymore: 248.3 mh
with phoenix: 249.4 mh

i thinks the new Adrenalin driver it's not woriking well with PhoenixMiner 3.5d

Thats what it was... the AV... Thank you for you input!

Or your AV erased/quarantined PhoenixMiner.exe

Bat file needs to sit next to phoenix exe file, meaning same folder.

Awesome.  Now that you got that out of the way, straighten me out with a answer.

Common Sense

Need some help:  I want to run phoenix miner 3.5d to see if its faster than claymore 11.9.  I downloaded it from mega to a thumb drive, copied it over to my rig... which is a 12 GPU AMD rig consisting of Rx560, 570 and 580s.  my command line in the start.bat is this: "PhoenixMiner.exe -pool ssl://us.1.ethermine.org:5555 -pool2 us1.ethermine.org:4444 -wal YourEthWalletAddress.WorkerName -proto 3" pause, except it has my wallet and rig name.

 After saving it  and double clicking it, I get this return and it freezes: "PhoenixMiner.exe is not reconized as an internal or external command, operable program or batch file"

I haven't changed anything in config.txt or epools...

windows 10

What am I missing to start this miner???

I hope they will add it later.

Yeah, but it need fan control for linux like claymore

Very good miner, stable as rock and gives best hashrate.

Hi.
According to OP, first card has numer 1, not 0.
Edit. and don't use brackets.

Guys, I have a rig with 10 gpus and want to use the first 9 with PhoenixMiner, so I used this comand:
-gpus <012345678>
but the miner didn't work this way, so I changed to
-di 012345678
and it works fine I think...
Is that normal or I'm doing something wrong?
thanks

I hate to be 'that guy' but is their an estimate as to when the next version will release?

   This is partially true. Under Linux, this is not called Compute mode, and -acm won't do anything but you can still have the same problem (big drop in hashrate in DAG epoch 180+ vs DAG epoch 2) because of the TLB thrashing when the DAG size increases. If you are seeing such hashrate drop under Linux (and it is quite noticeable when mining ETH or ETC), you need to enable the large page support as described here: https://support.amd.com/en-us/kb-articles/Pages/AMDGPU-PRO-Driver-for-Linux-Release-Notes.aspx (in the "Large page support") section. Note that in the latest AMD drivers for Linux this is supposed to be turned on by default, and in the drivers before 17.40, it may not have an effect at all.


   The drivers shouldn't be a problem. In 18.9.3 there weren't relevant changes in the OpenCL implementation, so using 18.8.2 probably won't make a difference. Could you please send us a log (preferably whenever the problem is happening) to see what is going wrong?


   This seems like the IP hijack attack aganst your network/ISP. Please try using an SSL-enabled pool like ethermine (e.g. -pool ssl://eu1.ethermine.org:5555 instead of -pool eu1.ethermine.org:4444). If you are already using SSL pool, please send us a (partial) log to see if there are any clues what happens.


   We will probably add support but not in the next release, as we are trying to finish it ASAP. The change seems small but it requires a lot of conditional checks and changes in the code that need to be thoroughly tested, etc, which can easily add a week or two to our schedule.



    Theoretically, there shouldn't be need to recalculate the -gt values whenever the network difficulty change. Probably something else has changed like the driver version, the PM kernels (if you have upgraded PhoenixMiner since the last auto GT), the core and/or memory clocks, etc.). Also, it is not possible to get the network difficulty from the pool (it simply doesn't send us this information, only the share difficulty). However we may add an option to re-run auto-tune periodically in the future.

Mined now for few days and seems that phoenix is little faster than claymore.
After adding -mi settings, started mining better. -gt still auto tune. started mining prezzed Z and -gt was calculated.
Notised that after coin network difficult changes about 10TH (up or down), then was need to auto tune -gt setting again, was mining better.
So there is suggestion to phoenix , can you add setting that monitor coin network difficult and if changes in difficult are big then phoenix calculates new -gt settings.
Exsample: ETC dif 197TH calculated first, dificult rised to 206TH need to calculate again -gt settings. And this up and down goes every day.
This few minutes autotune is worth.

Good day PM please Add --->>  Will be added support of Ubiq (hardfork) New Ubqhash algo?

Will be added support of Ubiq (hardfork) algo?

Please consider adding Yocoin and Atheios