No I changed frequency using MSI Afterburner. But it needs to be installed on the PC. I checked Overdriventool, it looks perfect, but it seems it does not modify those frequencies in a card's bios directly. When I apply the max vram frequency to 700 MHz, it works ok, but in different PC the card has stock clocks again. So in order to have max frequency 700 MHz, either MSI Afterburner or this Overdriventool have to be used. I need the solution to modify those values directly in the card. Thanks a lot for any help!

hello guys. I have a lot of VEGA 64 LIQUID cards, unfortunately they are not able to handle the stocks VRAM frequencies (945 MHz). I had to force flash VEGA 56 bios (800 MHz), some of them are working, but some need even lower VRAM frequency 700 MHz. If I set it in MSI Afterburner to 700 MHz, everything is working. Can you help me to find the way how to modify BIOS directly to set 700 MHz so no overclock software is needed?

Is there any app useful to mod this frequency into VEGA 56 BIOS to 700 MHz? Thanks a lot for your help! Lukas

Hey PhoenixMiner, ever since the last ETH Epoch and the new 3.98GB DAG, I am seeing a slowdown on all my mining graphics cards. It varies from 5 - 10% depending on the card type and other settings. I am using version 5.3b. Any explanations as what could be the reason for this slowdown?

The slowdown remain after re-booting.

one of my rig...

windows 10 version 2004
amd driver 20.3.1
latest phoenix miner
two rigs both with 2 radeon VIIs

at dag switch to 379 both rigs went from 83 mHash per card to 75 mhash per card
the gt value was 50 on all cards
so re-ran phoenix and got new gt value of 6
but cards only recovered to 80.5 mhash

so the radeon VIIs have lost a little hash.
there was defintely some weirdness at dag switch over.
would love to get those missing hashes back. is driver 20.3.1 the problem??
great work phoenix . thank you for your time sorting these issues for us all.

   Not yet, but we received both 3080 and 3090, waiting for 3070. After the ETCHash work is finished, we will switch focus to the new GPUs.


   We can't reproduce this problem. Please tell us what GPU you are using, and the full command line (plus config.txt, if you are using it). Please note the following:

• -li should not be used together with -gpow - pick one or the other
• If you are using -gpow, make sure that -mi is not 0 or any other small value - it must be at least 6-7
• If you are using your main PC with your main GPU for mining, just add -mi 0 and do not use -li or -gpow - this will allow relatively smooth work on the display while the card is mining. Of course, the hashrate will be lower but you can't have both high hashrate, and quick to react GPU

   Yes, there will be Linux support for -straps too.



    6800/6800XT are not supported with native kernels - we don't have either card yet, so the miner falls back to the generic kernels, which are slower and produce more stale shares. Additionally, NiceHash just rejects all stale shares, and that is exactly what you are seeing. You should add -stales 0 when mining on NiceHash to avoid sending known (to miner) stale shares that will be rejected anyway. In order to minimize the stale shares when mining with the generic kernels, you may try to lower the mining intensity -mi to 10, 9, or even lower value. This will lower the speed somewhat but with 10-12% stale shares, it should be worthwhile trade off.




    In our test rigs all is fine even at epoch 400 - 1070Ti mining with over 30MH/s. If you are running Windows, try using older drivers (in our test rigs with 1070Ti we have drivers 397.64, and 456.71 - both work fine). If you are running Linux, you may try to add use 8 GB RAM on your rig, if you are running only 4 GB RAM now.



    Most probably mixed-up drivers. Remove the drivers with DDU, then check if they are really removed - they should be listed only as "Microsoft Basic Display Adapter" not as Radeon .... If necessary, run DDU again until you see only "Microsoft Basic Display Adapter"s in the Device Manager, only then install the new drivers.




   This is intentional - do not worry about it, the miner will force -eres to 0 for the next few epochs. The reason is as follows: there are two methods to create and organize the DAG buffer on AMD cards: the first one is better as it provides slightly higher hashrate, and slightly lower power usage. However it stops working when the DAG size is over 3.9-4 GB, and we are forced to use the second method. The exact limit depends on the drivers but eventually (around epoch 379-384) even 6GB and 8GB cards will have to use the second method. We are disabling the DAG pre-allocation (i.e. forcing -eres 0) in order to be able to use the first method as long as possible. Once the limit is crossed, the second method will be used and -eres will work again as expected.




   The errors are pretty clear - you have to run your .bat file with the "Run As Administrator" and make sure that EIO.dll, EIO.exe, and IOMap64.sys from the PhoenixMiner package are in the same folder. It is not enough to just copy the PhoenixMiner.exe from the new package if you want to use the "-rxboost" option.



   Try using -daglim with lower values  (the default is 4023). See the other recommendations for 4 GB cards in the first post of this thread.




   You need to run PhoenixMiner 5.2e, not the older version 5.1c.





   Try using newer drivers (20.5.x or later) and PhoenixMiner 5.2. However eventually (after several weeks at most) even the 8GB cards will have to switch to second method for DAG generation and organization as explained above. We are looking for a ways to remove this additional inefficiency caused by the big DAG buffer, but it seems that it will be hard to avoid. The good news is that it is not getting worse once the limit is crossed - the hashrate at epoch 400 and 450 is almost the same, the same goes for the power consumption.



   Unfortunately, no. We tried a lot of things, including some very clever tricks to increase the locality of memory accesses and lower the pressure on the TLB cache but the result was even worse than before.







  As explained above, nicehash rejects all stale shares. We can discover only some of the stale shares, but not all because only the pool itself decides which share is stale. In your case even -stales 0 won't make a big difference because only one of the rejected shares was discovered to be stale by the miner itself.





   Try using -fcm 2 or newer drivers. -tt with target temperature should work without problems. If it still doesn't work with the latest drivers, send us a log file to diagnose the problem.





   You only need to run it as administrator if you are using -rxboost or -straps. Check if the .bat file works normally (when not run as administrator) first. To diagnose possible problems, you can also open the "Command Prompt" as Administrator (you should see Administrator:Command Prompt in the title bar) and then run the .bat file from there to be able to see any errors.





   Try using -daglim with lower values for the last GPU (the default for Windows is 4023). In your case use -daglim 1,1,1,4016 to set the DAG limit for the last card to 4016MB and the first three will be on auto (4023MB).





   Not yet, will be implemented in a future version. For now, you may try -mt 2 -rxboost 1 which should give you a good speed up if the cards are not modded.





   From our testing only the Polaris memory controller benefits from the dual DAG buffer of the turbo kernels, there is no speed up on Vega, or Navi. We haven't tested RX6800 yet but it is unlikely that it will provide more speed with dual DAGs as it seems quite similar to Navi in this respect. On Polaris cards with 8GB however, the turbo kernels will work as expected for a long time when using etchash.

PhoenixMiner 5.2e is officially released. You can find the download link and the checksums in the first post of this thread.

It is the same release as the one that was released yesterday, so if you are already running it, there is no need to upgrade.

Hi everyone

I am having issue with 5.2d

When I turn Phoenix Miner on, it says "Press any key to continue".

Once I press any key with my keyboard, the miner closes


Any idea?

make sure you have both raisers and gpus powered form the same psu  I got in this way

Also interesting on vegas, as I do have some with device lost problem on 3psu rig with vegas...
I wonder if the post can be delayed by some parameter in bios... (if its the case, which would be hard to verify as I also have hw reset watchdog, so it may trigger device rediscovery...)
 Im interested too if we can delay POST or other solution will be nice

Multiple power supplies doesn't start synchronous at miliseconds, and bios when boots, doesn't found it. Is common problem at Vega 56-64. The only way is to use one single power supply of minimim 2700Watts for all graphic cards and MB too, and ATX mini power supplied from main power supply too.

https://www.mini-box.com/picoPSU-90-100W-power-kit

  Currently the big DAG buffer, which is required by the latest ETH and ETC DAG size, is not supported by the AMD BETA blockchain driver, which is quite old. We will try to make it work but don't hold your breath - your best option is to upgrade to new drivers, for example 20.4.2.


  The driver allows controlling the voltages only within certain limits. Try to set ti to 860 to see if it can be controlled at all with this driver. If it is successfully set to 860, then 850 mV is the minimum possible to be set via the driver. If you can't even set 860 mV successfully, then you may try to use newer driver, or third party tool for undervolting the memory.
  


 Which driver version?



  As long as you stay on driver 20.4.2, 8GB cards will work until epoch 390, after that you need to upgrade to PhoenixMiner 5.2d or later.



  It will be supported in 5.2e. But unless you managed to get RX6800, there is no need to use the latest driver.



   Yes, should be working with all drivers from the last year or so. You can also use -ttli to set the temperature at which the miner will start lowering speed if the fans can't keep the temperature set with -tt. Example: -tt 63 -ttli 67 -fanmax 60 : the miner will try to keep the temperature at 63C, but without setting the fans above 60%. If the temperature continues to climb, at 67C, the miner will start reducing hashrate just enough to keep the temperature around 67C. NOTE: In the newer drivers, -tmax no longer works, so use -ttli instead



  Can you tell us the driver version and what are you mining (ETH or ETC)? We can't detect any loss of hashrate on 8GB cards in our internal testing.




   Yes, -tmax no longer works on the newer drivers. You can use -ttli instead - it sets the temperature at which the miner will start lowering speed if the fans can't keep the temperature set with -tt. Example: -tt 63 -ttli 67 -fanmax 60 : the miner will try to keep the temperature at 63C, but without setting the fans above 60%. If the temperature continues to climb, at 67C, the miner will start reducing hashrate just enough to keep the temperature around 67C

Yes, it should be. Cause ETCHash and Ethash are identical up to epoch 390 and Zil uses epoch 0 - ETC + Zil should be no issue.

Sorry, I was wrong to write about the epoch.
I meant that when the epoch changed to #372 I was already using version 1.12 for a few hours.

Yes, I'm trying these settings too: --keepfree 16 --4g-alloc-size 3992
Currently it seems stable even if the hashrate has dropped by about 2MH  

@Lolliedieb
Hi, after about 12 hours of using version 1.12 I have 0 hw errors, so I can confirm that in my case this issue is solved. Thank you very much.

Today after a while that the epoch has changed, hashrate has dropped to 1.2Mh. Manually restarting the miner without 4GB related parameters, the hashrate returned to normal, but after a while it dropped again. I will try to play with 4GB params hoping to solve.

This should be fixed with newest release
See lolMiner 1.12 that saw light of day today