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

[lesjokolat]

PhoenixMiner.exe -platform 1 -amd -epool stratum+tcp://daggerhashimoto.usa.nicehash.com:3353 -ewal Wallet.Rig -tmax 70 -esm 3 -epsw x -allpools 1 -dbg -1 -gt 67  -lidag 3

try this:

PhoenixMiner.exe -amd -pool stratum+tcp://daggerhashimoto.usa.nicehash.com:3353 -wal (your address) -pass x -tmax 70 -esm 3 -allpools 1 -dbg -1 -gt 67 -lidag 3


also what coin? add

-coin eth

for example

[1714774440]

1714774440

[1714774440]

1714774440

[fractalyse]

IMPORTANT! The versions of PhoenixMiner before 4.0 only support DAG epoch up to 235. Both ETC and ETH passed DAG epoch 235 some time ago. The unfortunate result is that the old version(s) of PhoenixMiner won't be able to create DAG or mine ETH or ETC any more - you must upgrade to PhoenixMiner 4.x if you are mining ETH or ETC.
Changes in version 4.2c (since 4.1c):

Hi,
Could you change gpu details in api ?
Currently it's not possible to know which gpu is hang and not mininig
Here is the output if all gpu are mining correctly

{ gpusEthHashrate:
   [ { gpuId: 0, hashrate: 29502 },
     { gpuId: 1, hashrate: 29501 },
     { gpuId: 2, hashrate: 29487 },
     { gpuId: 3, hashrate: 29502 },
     { gpuId: 4, hashrate: 29486 },
     { gpuId: 5, hashrate: 29500 } ],
  rejectedEthShares: 0,
  totalEthHashrate: '176981',
  totalRejectedShares: '0',
  totalSubmittedShares: '6',
  uptime: '2',
  validEthShares: 0 }

Here is the output if gpu 0 is hang. Using API it is impossible to know which gpu is hanging

{ gpusEthHashrate:
   [ { gpuId: 0, hashrate: 29502 },
     { gpuId: 1, hashrate: 29501 },
     { gpuId: 2, hashrate: 29487 },
     { gpuId: 3, hashrate: 29502 },
     { gpuId: 4, hashrate: 29486 } ],
  rejectedEthShares: 0,
  totalEthHashrate: '147481',
  totalRejectedShares: '0',
  totalSubmittedShares: '6',
  uptime: '2',
  validEthShares: 0 }

Gpu 0 is always the first USABLE Gpu by the miner, instead of being the first Gpu the user ask to use (even if this one is not usable).
Could you do something like this :
in this example Gpu 0 is hang and couldn't be used anymore by the miner.

{ gpusEthHashrate:
   [ { gpuId: 0, hashrate: 0, used: false },
     { gpuId: 1, hashrate: 29501, used: true },
     { gpuId: 2, hashrate: 29487, used: true },
     { gpuId: 3, hashrate: 29502, used: true },
     { gpuId: 4, hashrate: 29486, used: true },
     { gpuId: 5, hashrate: 29500, used: true } ],
  rejectedEthShares: 0,
  totalEthHashrate: '147481',
  totalRejectedShares: '0',
  totalSubmittedShares: '6',
  uptime: '2',
  validEthShares: 0 }

Currently this is notified only in console mode, nothing API side, I think this could be a good benefit .
Thanks for the job, and thanks in advance

[Pilgrim75]

hi,

tnX for great Miner, however, i got an issue with it sometimes it stuck on devfee mining for hours till i notice and restart the miner,
i don't mind the devfee its developer time and passion but stucking on devfee mining for long time i'm barely above the Electricity bill and maintenance fee...
so if there is anything i can do to make it normal i appreciate any insights

tnX in advance

here is the latest over 15 minutes none stop devfee mining!
and had to restart the miner to  back to normal

*** 7:45 *** 4/7 10:08 **************************************
Eth: Mining ETH on eu1.ethermine.org:4444 for 0:00
Eth: Accepted shares 1004 (0 stales), rejected shares 14 (0 stales)
Eth: Incorrect shares 0 (0.00%), est. stales percentage 0.00%
Eth: Maximum difficulty of found share: 22.2 TH (!!!)
Eth: Average speed (5 min): 160.702 MH/s
Eth: Effective speed: 156.88 MH/s; at pool: 154.72 MH/s

Eth speed: 160.711 MH/s, shares: 1045/14/0, time: 8:00
GPUs: 1: 32.226 MH/s (228) 2: 31.816 MH/s (201) 3: 32.221 MH/s (200) 4: 32.225 MH/s (224) 5: 32.222 MH/s (206)
Eth: New job #7ef2caf3 from eu1.ethermine.org:4444; diff: 4000MH
Eth: New job #11b6e302 from eu1.ethermine.org:4444; diff: 4000MH
Eth speed: 160.711 MH/s, shares: 1045/14/0, time: 8:00
GPUs: 1: 32.225 MH/s (228) 2: 31.817 MH/s (201) 3: 32.221 MH/s (200) 4: 32.225 MH/s (224) 5: 32.222 MH/s (206)
Eth: New job #19eaab09 from eu1.ethermine.org:4444; diff: 4000MH
Eth: New job #3877a609 from eu1.ethermine.org:4444; diff: 4000MH
Eth: New job #84052be9 from eu1.ethermine.org:4444; diff: 4000MH
Eth speed: 160.711 MH/s, shares: 1045/14/0, time: 8:00
GPUs: 1: 32.226 MH/s (228) 2: 31.817 MH/s (201) 3: 32.221 MH/s (200) 4: 32.224 MH/s (224) 5: 32.223 MH/s (206)

*** 8:00 *** 4/7 10:22 **************************************
Eth: Mining ETH on eu1.ethermine.org:4444 for 0:14
Eth: Accepted shares 1045 (0 stales), rejected shares 14 (0 stales)
Eth: Incorrect shares 0 (0.00%), est. stales percentage 0.00%
Eth: Maximum difficulty of found share: 22.2 TH (!!!)
Eth: Average speed (5 min): 160.704 MH/s
Eth: Effective speed: 157.90 MH/s; at pool: 155.81 MH/s

Eth speed: 160.711 MH/s, shares: 1045/14/0, time: 8:00
GPUs: 1: 32.226 MH/s (228) 2: 31.816 MH/s (201) 3: 32.221 MH/s (200) 4: 32.225 MH/s (224) 5: 32.222 MH/s (206)
Eth: New job #7ef2caf3 from eu1.ethermine.org:4444; diff: 4000MH
Eth: New job #11b6e302 from eu1.ethermine.org:4444; diff: 4000MH
Eth speed: 160.711 MH/s, shares: 1045/14/0, time: 8:00
GPUs: 1: 32.225 MH/s (228) 2: 31.817 MH/s (201) 3: 32.221 MH/s (200) 4: 32.225 MH/s (224) 5: 32.222 MH/s (206)
Eth: New job #19eaab09 from eu1.ethermine.org:4444; diff: 4000MH
Eth: New job #3877a609 from eu1.ethermine.org:4444; diff: 4000MH
Eth: New job #84052be9 from eu1.ethermine.org:4444; diff: 4000MH
Eth speed: 160.711 MH/s, shares: 1045/14/0, time: 8:00
GPUs: 1: 32.226 MH/s (228) 2: 31.817 MH/s (201) 3: 32.221 MH/s (200) 4: 32.224 MH/s (224) 5: 32.223 MH/s (206)

I confirm!
Today, 2 farms, 8 RX 580 40 minutes worked for the developer! And I do not need to write what to add! Add to your hands the ability to do everything right. Regardless of the settings, the program should work correctly. Reduce your greed!

[Digital_Seytan]

Hello PM dev is this possible on next new version of Phoenixminer  , the main update is applying memory straps/registers without flashing cards.
Like this:  https://bitcointalk.org/index.php?topic=5123724.0
but for Windows and with more features.



https://latest-miners.wixsite.com/latestminer

[PhoenixMiner]

Phoenix, please add AMD 19.4.1 driver support.

   We will add support for the latest AMD drivers (and all drivers before them) when the next version is released.

Hi all ... anyone using the -pauseat command? It doesn't seem to work with time(24h). Whatever the time is set it always pauses mining from the start.

   -pauseat is meant to be used along with -resumeat. E.g. -pauseat 06:00 -resumeat 22:00 will only mine between 22:00 and 6:00. If you start the miner at 18:00 for example, it will start paused and will start mining at 22:00 as instructed. However if you have only -pauseat at the command line, the miner will always start paused. In the next release we will change that, so if you only have -pauseat without -releaseat, the miner won't start paused but running.

So came across strange thing. i have only one rx480 in rig with few rx580s, everything was working ok up until maybe month ago.
rx480 started giving incorrect shares, a lot of them, before it would give few in a week. Now all of sudden, card would in give in 5 days 7 incorrect shares (normal more or less) and then would just start giving enormous amount of incorrect ones (every 3rd or 4th would be CORRECT one)

I tried to check logs, but nothing unusual in them.
Restarting rig helps, for 4-5 days then everything starts all over again.
Radeon software version 19.1.1
phoenix 4.1c

Did anybody have similar problem or know solution for it?

Thanks

   If you have a lot of incorrect shares that go away after restart, most probably the GPU produced incorrect result during the DAG generation. With corrupted DAG, most shares will be incorrect. If the GPU worked fine before probably there is some degradation of the memory (or its VRM, capacitors, etc). Try using -lidag to decrease the intensity during DAG generation for this GPU, which will decrease the probability of corrupted DAG being generated. If this doesn't help, the only solution is to reduce the memory overclock.

hi,

tnX for great Miner, however, i got an issue with it sometimes it stuck on devfee mining for hours till i notice and restart the miner,
i don't mind the devfee its developer time and passion but stucking on devfee mining for long time i'm barely above the Electricity bill and maintenance fee...
so if there is anything i can do to make it normal i appreciate any insights

tnX in advance

here is the latest over 15 minutes none stop devfee mining!
and had to restart the miner to  back to normal

Code:

[glow=red,2,300]*** 7:45 *** 4/7 10:08[/glow] **************************************
Eth: Mining ETH on eu1.ethermine.org:4444 for 0:00
Eth: Accepted shares 1004 (0 stales), rejected shares 14 (0 stales)
Eth: Incorrect shares 0 (0.00%), est. stales percentage 0.00%
Eth: Maximum difficulty of found share: 22.2 TH (!!!)
Eth: Average speed (5 min): 160.702 MH/s
Eth: Effective speed: 156.88 MH/s; at pool: 154.72 MH/s

Eth speed: 160.711 MH/s, shares: 1045/14/0, time: 8:00
GPUs: 1: 32.226 MH/s (228) 2: 31.816 MH/s (201) 3: 32.221 MH/s (200) 4: 32.225 MH/s (224) 5: 32.222 MH/s (206)
Eth: New job #7ef2caf3 from eu1.ethermine.org:4444; diff: 4000MH
Eth: New job #11b6e302 from eu1.ethermine.org:4444; diff: 4000MH
Eth speed: 160.711 MH/s, shares: 1045/14/0, time: 8:00
GPUs: 1: 32.225 MH/s (228) 2: 31.817 MH/s (201) 3: 32.221 MH/s (200) 4: 32.225 MH/s (224) 5: 32.222 MH/s (206)
Eth: New job #19eaab09 from eu1.ethermine.org:4444; diff: 4000MH
Eth: New job #3877a609 from eu1.ethermine.org:4444; diff: 4000MH
Eth: New job #84052be9 from eu1.ethermine.org:4444; diff: 4000MH
Eth speed: 160.711 MH/s, shares: 1045/14/0, time: 8:00
GPUs: 1: 32.226 MH/s (228) 2: 31.817 MH/s (201) 3: 32.221 MH/s (200) 4: 32.224 MH/s (224) 5: 32.223 MH/s (206)

[glow=red,2,300]*** 8:00 *** 4/7 10:22 [/glow]**************************************
Eth: Mining ETH on eu1.ethermine.org:4444 for 0:14
Eth: Accepted shares 1045 (0 stales), rejected shares 14 (0 stales)
Eth: Incorrect shares 0 (0.00%), est. stales percentage 0.00%
Eth: Maximum difficulty of found share: 22.2 TH (!!!)
Eth: Average speed (5 min): 160.704 MH/s
Eth: Effective speed: 157.90 MH/s; at pool: 155.81 MH/s

Eth speed: 160.711 MH/s, shares: 1045/14/0, time: 8:00
GPUs: 1: 32.226 MH/s (228) 2: 31.816 MH/s (201) 3: 32.221 MH/s (200) 4: 32.225 MH/s (224) 5: 32.222 MH/s (206)
Eth: New job #7ef2caf3 from eu1.ethermine.org:4444; diff: 4000MH
Eth: New job #11b6e302 from eu1.ethermine.org:4444; diff: 4000MH
Eth speed: 160.711 MH/s, shares: 1045/14/0, time: 8:00
GPUs: 1: 32.225 MH/s (228) 2: 31.817 MH/s (201) 3: 32.221 MH/s (200) 4: 32.225 MH/s (224) 5: 32.222 MH/s (206)
Eth: New job #19eaab09 from eu1.ethermine.org:4444; diff: 4000MH
Eth: New job #3877a609 from eu1.ethermine.org:4444; diff: 4000MH
Eth: New job #84052be9 from eu1.ethermine.org:4444; diff: 4000MH
Eth speed: 160.711 MH/s, shares: 1045/14/0, time: 8:00
GPUs: 1: 32.226 MH/s (228) 2: 31.817 MH/s (201) 3: 32.221 MH/s (200) 4: 32.224 MH/s (224) 5: 32.223 MH/s (206)

      Please send us the fill log (or at least a few minutes before the devfee period started). From the snippet above it seems that the shares increase from 1004 to 1045 for these 15 minutes (the devfee shares are not counted in the stats, so these are your own shares), which is quite normal amount for your rig as it corresponds to about 180 MH/s effective hashrate with 4000 MH share difficulty. That's why we need the full log to understand what went wrong, with the communication between the miner and the pool,
      There was one quite rare case where this could have happened in the older versions if the stratum thread froze but we have a watchdog timer for the stratum thread too in the last few releases and this shouldn't be possible (the miner will just restart after a minute or so).

Hi guys,
recentl I use this great miner, but last 3 days I get very annoing problem:

Eth: Unable to read pool response: An existing connection was forcibly closed by the remote host
Eth: Reconnecting in 20 seconds...

I try almost everything but stil comes up may be this is a issue with my ISP, I don't know.
Please reply if someone have same troubles and know what is solution.
Thanks in advance.

    Besides internet connectivity problems, this can be caused by the pool rejecting the connection from you for some reason. You can check the log file for details as some pools usually send a non-standard but human readable error message when they refuse a connection.

• Added parameter to enable or disable driver-specific optimizations on Nvidia GPUs. Use -nvdo 1 (the default is 0) to enable the optimizations. This won't change hashrate (or will change it only slightly) but can make the cards more stable depending on the concrete Nvidia driver.

What driver version or versions was this coded for? What are the driver settings the optimizations affect if you dont mind dropping some knowledge? What ever they are they seem to work for stability.

   Neither GPU manufacturer is particularly forthcoming with information about the driver implementation so we can't give you what we don't have ourselves We perform a lot of experiments and micro-benchmarks to see what works best. The -nvdo option will work with all Nvidia drivers (including the ones that are released after PM 4.2c) as it is a more general mechanism than the one used with the AMD drivers, which will simply crash if the driver behaves differently than expected. As we can't test with all possible GPU/driver combinations,  you have to try it for yourself.

-li, -mi and -ethi does not work on PhoenixMiner, any idea why?

   Can you please let us know the whole command-line (or config.txt) you are using as well as the OS version,  and the GPUs you are using? Also we need to know the mined coin (or at least the algorithm - Ethash, ProgPOW/BCI or dual mining).

Hi,
Could you change gpu details in api ?
Currently it's not possible to know which gpu is hang and not mininig
Here is the output if all gpu are mining correctly
...

   We can't change the remote API as many 3rd party applications rely on the current format. However what you are describing sounds like a bug in PhonixMiner - it should show the real hashrate for each GPU (with some delay but no more than 10-20 seconds depending on the size of moving average window). We will try to reproduce the problem here and fix it.

I confirm!
Today, 2 farms, 8 RX 580 40 minutes worked for the developer! And I do not need to write what to add! Add to your hands the ability to do everything right. Regardless of the settings, the program should work correctly. Reduce your greed!

    Please send us the full log or at least the part from before the devfee started to the end of these 40 minutes. You are right that this should never happen regardless of the used settings. We have had only a few similar reports in the past and it was found out to be a problem with the stratum thread freezing. However even this rare event is impossible in the latest version as the stratum thread is protected by a watchdog timer and if it freezes, the miner is restarted by the watchdog timer.

Hello PM dev is this possible on next new version of Phoenixminer  , the main update is applying memory straps/registers without flashing cards.
Like this:  https://bitcointalk.org/index.php?topic=5123724.0
but for Windows and with more features.

   We are working on something similar but we want to make it easier to use.

[Pilgrim75]

I apologize for the excessive emotionality in the previous message. Unfortunately, I did not save the logs and have already switched to another algorithm. I can only share the observation, this problem arose only on farms with a production level above 100MH.

[defaced]

Wait people actually use a miner that has a built in fee and no one can verify or validate the source? really?

[Digital_Seytan]

well, i switch back to Claymore...

1% better than hours of devfee by phoenixminer!

i don't have old logs
here is the link that 15 minutes devfee before i stop and switch back to claymore

https://gofile.io/?c=aYe0tA

I have had it a few times that phoenixminer, every 15 minutes devfee comes to mining for the developer there is certainly a bug present at phoenixminer 4.2.c. 4 x per hour devfee is certainly too much. therefore, to be sure, until a new version comes out, I go to claymore miner.

[PhoenixMiner]

well, i switch back to Claymore...

1% better than hours of devfee by phoenixminer!

i don't have old logs
here is the link that 15 minutes devfee before i stop and switch back to claymore

https://gofile.io/?c=aYe0tA

  Thank you for the log! It definitely helped us to identify the issue. If you look carefully in the log you posted, you will see that there is no DevFee prefix when posting shares - that is because the miner is not mining devfee at all. What is happening then? After some testing, the source of the problem is clear: the example epools.txt file, which is included in the zip file with the miner. If there is an epools.txt file in the same folder as the miner, it always reads it and adds the pools from there to the pools that you have specified at the command line (or in bat file, config.txt, etc.). This normally isn't a problem but if your main pool fails and the miner is not able to connect to it in three attempts, it switches to the next pool, which happens to be the on in the epools.txt file.

   So here is how to fix the issue (do one of the following things):
   - Delete the epools.txt file that comes with the miner or rename it to something else - the miner won'r read it and if you main pool fails, it will try to connect to it fovever
   - Open the epools.txt file and change the wallet (and pool if necessary) to your own wallet.

I apologize for the excessive emotionality in the previous message. Unfortunately, I did not save the logs and have already switched to another algorithm. I can only share the observation, this problem arose only on farms with a production level above 100MH.

  No problem, we would also be upset in similar situation. Still, we would never jeopardize our reputation with such stupid "trick". Most probably the problem was the same as above - using the default epools.txt file that comes with the miner. Just delete epools.txt file or change the wallet to your own and the issue will go away.

I have had it a few times that phoenixminer, every 15 minutes devfee comes to mining for the developer there is certainly a bug present at phoenixminer 4.2.c. 4 x per hour devfee is certainly too much. therefore, to be sure, until a new version comes out, I go to claymore miner.

  There is no bug in PhoenixMiner 4.2, just see above.

[pbfarmer]

well, i switch back to Claymore...

1% better than hours of devfee by phoenixminer!

i don't have old logs
here is the link that 15 minutes devfee before i stop and switch back to claymore

https://gofile.io/?c=aYe0tA

  Thank you for the log! It definitely helped us to identify the issue. If you look carefully in the log you posted, you will see that there is no DevFee prefix when posting shares - that is because the miner is not mining devfee at all. What is happening then? After some testing, the source of the problem is clear: the example epools.txt file, which is included in the zip file with the miner. If there is an epools.txt file in the same folder as the miner, it always reads it and adds the pools from there to the pools that you have specified at the command line (or in bat file, config.txt, etc.). This normally isn't a problem but if your main pool fails and the miner is not able to connect to it in three attempts, it switches to the next pool, which happens to be the on in the epools.txt file.

   So here is how to fix the issue (do one of the following things):
   - Delete the epools.txt file that comes with the miner or rename it to something else - the miner won'r read it and if you main pool fails, it will try to connect to it fovever
   - Open the epools.txt file and change the wallet (and pool if necessary) to your own wallet.

I apologize for the excessive emotionality in the previous message. Unfortunately, I did not save the logs and have already switched to another algorithm. I can only share the observation, this problem arose only on farms with a production level above 100MH.

  No problem, we would also be upset in similar situation. Still, we would never jeopardize our reputation with such stupid "trick". Most probably the problem was the same as above - using the default epools.txt file that comes with the miner. Just delete epools.txt file or change the wallet to your own and the issue will go away.

I have had it a few times that phoenixminer, every 15 minutes devfee comes to mining for the developer there is certainly a bug present at phoenixminer 4.2.c. 4 x per hour devfee is certainly too much. therefore, to be sure, until a new version comes out, I go to claymore miner.

  There is no bug in PhoenixMiner 4.2, just see above.

I got tripped up by this in the past - luckily realized the problem way before getting to the point of suspicion.  But still need to remember every release or new rig setup to comment out epools, since I always use config exclusively.

Might be worth rethinking this design...  one possible solution would be two different 'pool' flags - maybe '--pool' behavior ignores epools, while '--addpool' follows the current behavior?

[Digital_Seytan]

when comes the new version of phoenixminer dev this version starts the rig way too many, or crashes.

https://latest-miners.wixsite.com/latestminer

[Faizrakhmanov]

PhoenixMiner, extremely need -tt function in Linux. Please HEPL.

[Tokechan]

Hi! Do I need to restart miner when I send new config.txt through Remote Manager or it applies automatically the moment i sent it?

[Faizrakhmanov]

Hi! Do I need to restart miner when I send new config.txt through Remote Manager or it applies automatically the moment i sent it?

Hi. If you send remotely new config file miner start work with this new config. Additional miner reboot not needed.

[peoples]

@PhoenixMiner

can you explain how you create nonce ? Is it randomized, and how u randomize ?

Thanks

[jorm_11]

Hey fellas, see if anyone can help. I've been running a 4 GPUs set up for more than a year, and just this week out of the blue I got this error:

Code:

2019.04.14:13:41:02.645: main Phoenix Miner 4.2c Windows/msvc - Release build
2019.04.14:13:41:03.767: main CUDA version: 9.0, CUDA runtime: 8.0
2019.04.14:13:41:03.809: main No OpenCL platforms found
2019.04.14:13:41:03.810: main Available GPUs for mining:
2019.04.14:13:41:03.810: main GPU1: GeForce GTX 1070 (pcie 1), CUDA cap. 6.1, 8 GB VRAM, 15 CUs
2019.04.14:13:41:03.810: main GPU2: GeForce GTX 1070 (pcie 3), CUDA cap. 6.1, 8 GB VRAM, 15 CUs
2019.04.14:13:41:03.810: main GPU3: GeForce GTX 1070 (pcie 5), CUDA cap. 6.1, 8 GB VRAM, 15 CUs
2019.04.14:13:41:03.824: main NVML library initialized
2019.04.14:13:41:03.854: main NVML error in CudaProgram.cu:147 : GPU is lost (15)
2019.04.14:13:41:03.854: main NVML error in CudaProgram.cu:150 : Invalid Argument (2)
2019.04.14:13:41:03.872: main Nvidia driver version: 391.01

I thought it was a hardware issue, but nope. Everything is working fine (I replaced risers/cables, etc.). I have to unplug all GPUs in order to get the mobo to recognize all of them again. Any ideas? Thanks

[jorm_11]

Ok so I might have found the issue. Check this, I'm using a single SATA from the PSU to power up a riser; it turns out the pins of the connector are rusted, and that's why it was losing power intermittently. So I just connected the GPU in question to my server PSU, and voila.

[PhoenixMiner]

I got tripped up by this in the past - luckily realized the problem way before getting to the point of suspicion.  But still need to remember every release or new rig setup to comment out epools, since I always use config exclusively.

Might be worth rethinking this design...  one possible solution would be two different 'pool' flags - maybe '--pool' behavior ignores epools, while '--addpool' follows the current behavior?

   We will rename the sample epools.txt file to something else to avoid future problems like this.

PhoenixMiner, extremely need -tt function in Linux. Please HEPL.

   We are working on this, hopefully it will make it in the next release.

Hi! Do I need to restart miner when I send new config.txt through Remote Manager or it applies automatically the moment i sent it?

   If you have specified the command-line option -cdmrs some of the options are applied without restart. The full list is in the description of the -cdmrs option in the first post of this forum thread:

  -cdmrs Reload the settings if config.txt is edited/uploaded remotely. Note that most options require restart in order to change.
      Currently the follwing options can be changed without restarting: -mi, -gt, -sci, -clf, -nvf, and all hardware control parameters
      (-tt, -fanmin, -fanmax, -powlim, -tmax, -cclock, -cvddc, -mclock, -mvddc).

@PhoenixMiner

can you explain how you create nonce ? Is it randomized, and how u randomize ?

Thanks

   It is randomized and different (independent) for each GPU. The exact random algorithm doesn't matter as long as it has good distribution.

Ok so I might have found the issue. Check this, I'm using a single SATA from the PSU to power up a riser; it turns out the pins of the connector are rusted, and that's why it was losing power intermittently. So I just connected the GPU in question to my server PSU, and voila.

   It would be nice to have clear error messages from the GPUs when the 12V power is missing or unstable but unfortunately the GPU doesn't report such events.

[PhoenixMiner]

Important message for everyone that is running older versions of PhoenixMiner (before 4.2):

IMPORTANT! The versions of PhoenixMiner before 4.2 only support DAG epoch up to 265. ETC will reach epoch 266 in about 20 days, and ETH will reach epoch 266 in about two months. To ensure uninterrupted operation, please upgrade to 4.2 before epoch 266. If you are mining other coins, you can safely disregard this message.

The reason for this limitation is that we need to perform some quite complex calculations for each future DAG epoch in order to increase the hashrate of the optimized kernels. Recently we have added more computational resources and PhoenixMiner 4.2 will work without problems up to DAG epoch 329. We will increase this number significantly in the future releases.

[GKumaran]

Results:
Cards : Vega 64 (aircooled, reference, samsung)
Platform : Windows 10, 18.6.1
Miner : PheonixMiner 4.2c
Algo : Ethash
Clocks : 1216/1107/875 (ODT)
Actual : 1187/1107/850 (HWinfo)

Stock                                                                                                                                                           : 44.75 mh/s
Current Timing  --rp 12 --rc 44 --rfc 250 --rrds 3 --rrdl 3 --rcdrd 12 --rcdwr 5 --CL 19 --RAS 28 --REF 15600       : 50.12 (12% inc over stock)

Finally broke the Ethash 50mh/s barrier in windows 

https://bitcointalk.org/index.php?topic=5123724.msg50615480#msg50615480