The new beta version is finally ready. You can download PhoenixMiner 5.6d from here:

PhoenixMiner_5.6d_Windows.zip (GitHub)
PhoenixMiner_5.6d_Linux.tar.gz (GitHub)



The new features in this release are:

• The problem with the missing GPU temperatures on Nvidia GPUs is fixed
• Added native kernels for AMD RX6700 GPUs. These are faster than the generic kernels and produce a lot less stale shares
• Increase the max supported DAG epoch to 550 (should be enough to about Jan 2023)
• Full support for setting clocks, fan speeds, voltages, and memory timings of AMD RX6900/6800/6700 cards
• The specific hashrate is now shown in the form of kilo hashes per joule (kH/J). Example: if a GPU has hashrate of 30 MH/s with 100W power usage, the specific hashrate is 300 kH/J
• Added new command-line parameters -ttj and -ttmem, allowing automatic fan speed control based on GPU hotspot (junction), and memory temperatures respectively. Example: -ttmem 83 will keep the GPU memory temperature at or bellow 83C by increasing the fan speed as necessary. These parameters can be combined with -tt, as well as with each other. These options are supported only on AMD GPUs that report junction and memory temperatures
• Added new command-line parameters -tmaxj and -tmaxmem, allowing to decrease the GPU usage when the GPU hotspot (junction), or GPU memory temperatures are above the specified thresholds. These options are supported only on AMD GPUs that report junction and memory temperatures
• Added support for AMD Windows drivers 21.3.2, and 21.3.1
• Added support for AMD Linux drivers 20.50.x. Use this drivers only if you have Polaris or older GPUs, or the latest RX6x000 GPUs. WARNING: Vega, Radeon VII, and Navi GPUs won't work with these drivers!
• Turn off the zero fan feature on AMD cards whenever a fixed fan speed is used (e.g. -tt -40), or when an auto fan with min fan speed is used (e.g. -tt 63 -minfan 35). To disable this feature, add -fanstop 1 command-line parameter
• When -mcdag 1 is specified under Linux, the miner will not wait for the daggen.sh script to finish before starting to generate the DAGs. Instead it will for a fixed 7 seconds. This allows you to do all the following in the daggen.sh: turn off the overclocking of Nvidia GPUs, sleep for 30-60 seconds to allow time for DAG generation, and then re-apply the overclocking of the Nvidia GPUs
• Other small improvements and fixes

The support for -ttj, -ttmem, -tmaxj, and -tmaxmem for Nvidia 3090 and 3080 GPUs is not yet ready for release. We hope to have it ready for the final 5.6 release.

For more robust integrity check, you can use our GPG public key, which was verifyed with ETH transaction from our main devfee account as explained here: https://bitcointalk.org/index.php?topic=2647654.msg56755869#msg56755869.

Please let us know if you have any problems or questions related to PhoenixMiner 5.6d.

Please add RVN + ZIL mining, it has been done in another miner that doesn't work well with RX cards.

Above post is probably a scam, the numbers are waaay off. SO, BEWARE!

Back on topic, I cannot change mode for a vega under windows, from A mode to B mode. I already have 20.9.1 driver and I have installed the tdr fix and set compute. I define B, it defaults to A. What do I need to do? Does the page file size matter for this? Also the card is not the main display card.

Thank you for the clarification. Do I need pill for Aion?

For now I am mining eth, yes and I prefer to keep it that way,  but I want to reach the real speed, I've seen even 54mhs. All memory is Micron. Do I need to put any arguments in the miner, in phoenix?

Hello,

I've been trying to set up a 1080ti rig, and all I can get is 44mhs @+100/+1200, 190 PL. What am I doing wrong?

I think you need to read again, he said watt/hash ratio, if you don't know what that is, better to ask than to assume.

DO NOT CLICK! MALWARE!

Yes, anything below 5.0 for Phoenix miner now gives that error, even on 8gb cards.

The driver is the problem. Use 18.3.4 driver with "-acm" parameter in config.

Someone has this but for micron 4gb?

I am getting a hard reset everytime I try any of the straps. I have testing mode enabled, secure boot off, driver 19.4.1 installed and 8 hynix rx580 8gb cards on win 10. When it goes to apply straps, it gets to the point where it shows the strap has been applied to the 2nd card and then...boom, reset. Tried with all levels of strap (1->5). I am setting the clocks with overdriventool externally, at 1751mhz (pretty low for testing sake).

Both my z1 and z1+ soft-died today, both restart endlessly, showing "miner may not boot" on the interface, no matter how many hard reboots I do...what is going on, anyone else experienced this?

Anyone tested lower RTX cards like the 2080,2070 and 2060?

anyone tested grin pro miner speed under linux for amd?

Is there a way to make MTP require only 4gb vram? I'd wish to use P104 with this miner on MTP.

I think I figured out the problem, it was switching pools like crazy (I had the same pool 3 times in the cases)...but shouldn't it stop consuming while switching, and the end result shouldn't it be the same? Also it was mining on very low difficulty from what I could see, but the rejects were still low...Anyways, put a version that is 2 releases back and it works now, it stopped jumping around, and shows OK hashrate (not the best but acceptable). The bad thing now is that I can't spin down the rpm on the fans...so no way to keep it in the house.

The latest firmware for z1+ looks like it is stealing hashrate, a LOT of it. I had it set to 1000 freq with auto freq to 1, and it averaged 1.5gh while still consuming 1170w of power continuously, rejected shares/errors were under 3%. So for that power, the hashrate should have been 4 times higher, I think the hashrate is redirected, getting screwed once with the initial sale wasn't enough...now we get screwed with this.

I don't understand where is this "33-sync" version...also, the previous one (the last experimental one) didn't work on my system, said it is a 16bit application and it doesn't work on 64bits.

b5 was never able to get higher effective hashrate than b4 and q versions on the long term, I don't think you did your testing right. Since we're on this subject of bx versions, since b4, stability degraded. On b4 I found each morning 1 or 2 rigs would go offline, those work right with q version for example.