The new beta version is finally ready. You can download PhoenixMiner 5.7a from here:

PhoenixMiner_5.7a_Windows.zip (GitHub)
PhoenixMiner_5.7a_Linux.tar.gz (GitHub)



The new features in this release are:

• Added lock core clock
• 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.7 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.7a.

Thanks guys - temp could be a factor - I ran these in the mid 50's (F) so nice and cool for them. My customer is running in an apartment - so probably 70 or something. So maybe a heat issue. Nothing to do about that other than back it down a bit unless he wants to cool it better. Hopefully he'll get a voltage for his main power so we can see if that may be a factor too.

I sold a miner S9-13.5T running Awesome Miner firmware. It was tuned to run reliably at 15.6TH/s - and I had it mining at these settings for well over a year. It was configured with chain 5 at 743MHz/8.5V, chain 6 at 743MHz/8.6V and chain #7 at 725MHz/8.8V. Then individual chips were reduced in frequency from there until everything was in the "green" zone.  But this is causing my customer mining errors - seems like more chips were going into the yellow and red zones at his location. So he reduced it to like 700MHz across the board (not sure of voltage at the moment) and is trying to adjust from there. But, my question is why is this happening? My thoughts are that maybe his source voltage is less and/or Hz differences? At my location, I had constant 240-248V - pretty constant at 60Hz. So could this be the difference? He's ordering a Kill-A-What type meter now so he can monitor these things. But I can't think of why else he is having different results.

Wow, how can anyone afford to miner here? I mean, the design seems great - but at this point with once per year payouts - that's rough. Too bad there isn't some sort of marketing campaign to get a lot of people to jump on all at once the get the blocks coming in faster. It looks like it was doing pretty well at one point - if the payouts were less all the fees usually involved, what prompted people to pull their miners elsewhere? That's a shame.

I guess I was just surprised that with all the air flow I have and the target temps - this would have kept the good - but I suppose still in the deeper core of the chips they would be getting hotter. Which I suspect is what is happening to cause the X's as their performance drops.

Currently they are completely normal again - no X's, S's, missing boards, anything - all fine!

Thanks again!

How often are payouts made from this pool? Is it only after a block has been found? It was nearly a year between the last 2 blocks if I understand this correctly - does that mean we have a year between payouts as well? I just need to make sure I don't allocate to much mining power here as I have to pay my utilities out of my mining earnings.

Ok everyone - long story short - these miners seem to be back to normal with no changes! 

After finding them all out of kilter yesterday and restarting and power cycling a couple times (including one of those times for at least 45 minutes) with the external large fans still running - and still all messed up like described - I just shut it all down until I could see what everyone thought. I didn't want to damage them by leaving them on that way and it was getting late with work coming in the morning.

So, maybe a hiccup with Nicehash? Or they needed to be left off longer to "reset"? I don't know.

But, they came back up running on Nicehash - as usual with all the hash boards and chips back in operation at normal hash rates. I still setup a ViaBTC account and moved my 4 L3+/++ units as well as 4 of my S9's there and currently have the other 4 S9's on ckpool.

I appreciate the effort you guys offered and wish I knew better what happened and why it cleared up. Nicehash seems like a likely candidate from the comments so far with this ending as well - maybe they just fixed their bug?

Crazy!

Thanks @mikeywith!

I am still muddling through everything. I only have one miner back on at the moment and looking at the pools to figure out accounts, settings, how to deal with payouts, etc... BUT, the one miner that I brought up is obviously still connected to NH and it is running like nothing ever happened. I HOPE the others will follow suite, but I want to prepare for these other pools first, before bringing the others up that is.

---

Ok everyone - long story short - these miners seem to be back to normal with no changes! 

After finding them all out of kilter yesterday and restarting and power cycling a couple times (including one of those times for at least 45 minutes) with the external large fans still running - and still all messed up like described - I just shut it all down until I could see what everyone thought. I didn't want to damage them by leaving them on that way and it was getting late with work coming in the morning.

So, maybe a hiccup with Nicehash? Or they needed to be left off longer to "reset"? I don't know.

But, they came back up running on Nicehash - as usual with all the hash boards and chips back in operation at normal hash rates. I still setup a ViaBTC account and moved my 4 L3+/++ units as well as 4 of my S9's there and currently have the other 4 S9's on ckpool.

I appreciate the effort you guys offered and wish I knew better what happened and why it cleared up. Nicehash seems like a likely candidate from the comments so far with this ending as well - maybe they just fixed their bug?

Crazy!

I am just now home and starting to work on it. So far many of the suggestions come with assumptions or comments that I clarified in my OP - so I am responding to those and also answering other ideas. Don't get so worked up. I said I would try these ideas when I got home - and that is what I am now doing. But, I am taking down settings, etc... before so I don't have to start from scratch. I had everything shut down until I could get to it, so bringing stuff back up piecemeal to do it.... relax!

Workin' on it...

I am getting ready to point a miner (or few) to your pool. But have a few questions.

Does it support ASICBoost?
Should I set my URL to other to use #xnsub?
Are there any other configs that can be set - like #xnsub?

Sorry, I looked around and didn't readily find these answers.

Thanks!

Not sure what you mean - again, I manually configured them - one at a time directly on their web interface and not via Awesome Miner. I used Awesome Miner once 2+ months ago to push template settings to them, and when I saw the results - I configure them manually after that. I haven't touched them for close to a month now - only monitoring, during which time the have had restarts due to 1 or 2 power drops we had during that time - but again, a couple of weeks ago. The only recent activity was the restarts I did when I found them like this yesterday.

Hopefully it's not some BS from NH, but with the miners configured to maintain temps at 76 and plenty of fan power - I don't understand how NH could cause their temps to go high enough to cause them problems - and doubly so when AM logs don't show any temp spikes. But maybe the fans in this scenario kept the temps ok, even though the chips may have been had frequencies set crazy high? But how could NH have modified chip frequencies? And again for a virus or hackers - the hashing gain seems to have went to my NH account - not elsewhere. This is weird and that is why I am here.

I haven't specifically posted there, but I did not configure these setting through Awesome Miner. I used Awesome Miner to push the firmware to the machines, then I manually tuned them myself through the miners web interface. And then they have been running - with corresponding has rate since (around 2 months). So I wouldn't think this would be an issue with Awesome Miners. I still look at the miners web interface as much as I do through Awesome Miner - since installing their (VNISH) firmware and I have found them to show corresponding values. Every setting I have configures and saved has stuck. I did not like the template patterns that Awesome Miner used to configure the miners for voltages and clock speeds - so I manually configured them directly. Reduced power and increased hash rates over their templates and have been running stably since. If I started having problems with them her and there on an individual basis I might would consider this to be related to the issue - but for them to all crap out within 30 minutes of each other after running with no issue for a couple of months, I don't think so. But, I will check with Patrik to see if he is aware of anything like viruses or other issues.

I have the #xnsub option enabled with Nicehash. My miner fans are all running well plus I have additional large fans pulling 3200CFM across 12 miners (4 are L3+/++ units). Also, miner's firmware is set to target a temp of 76 and if the logs from Awesome Miners are correct (and I believe they are) the temps never went above this.

I will try ckpool too when I can. I'll probably turn on one breaker - which runs 2 miners - I can point one at viaBTC and one at ckpool - maybe, depends on my testing, I only have one SD card to try booting from at the moment, but I guess I could try them before booting up from the SD card.

Thanks!

Voltage was tested at just a little over 240V. My power has thus far been very steady. I have a commercial power run just for my miners.

I have a LOT of xxx, I think sss too (I'm not home now where I can look, but pretty sure about the sss). Even hash boards not showing up. All of my miners were running fine - all hash boards were active - no lost chips on any of them. Until bang - now they all look like they got hit by a low level EMP!

I can give it a try on viabtc - but to me this looks like hardware at this point. If a virus/hack did this - then there's not much to do, but if Nicehash did this somehow - that's another story.

These units act like they had their frequencies on the chains/chips set so high that it burned them out - or is still set so high that they are just not able to run properly. Again, making me wonder about a virus that is running them at higher frequencies the the miner's web interface is showing - like the virus is hiding the true frequencies from the web interface.

I have additional fans on these units (to help cool them - to them point that if their own fans were not running - they might still be fine running. There's no indications that power dropped. Our house and the miners are coming off of the same transformer - they just have a feed from the transformer to a meter for the house, and another feed to a commercial meter for my miners. Nothing in the house gives any indication that power dropped. Sagged - possibly, but wouldn't that just cause the miners to drop some chips or chains temporarily? Once power cycled - especially with 45 minutes down before powering back up, that they would come back on normal?

What do you mean about setting a level in the password to keep from switching so much - I did not know there were things to be done with the password to effect anything?

I will try the viaBTC when I get home. That's one of the things that makes me question getting hacked or a virus though. My network is very inaccessible from the outside. I mean, I would HAVE to run a VPN to gain access. My ISP, oddly, issues private IPs to the WAN connection. So like 192.168.x.x, 172.16.x.x, or 10.x.x.x type addresses. So I can't use remote access software other than ones like TeamView or LogMeIn that have a host side application that links to their online systems to allow for making connections via their intermediary websites. And currently - I don't have a VPN or any of those remote access systems setup. I am careful about my computers as well - I am an IT guy, and I have (to my knowledge) not had a virus on any of my systems for better than 30 years - at least that wasn't a controlled scenario. I have no indications of any viruses on my computers in the network - at least nothing that virus scanning in finding.

The firmware has a tab in it that will scan the miner for it looks like 3 known viruses - and that is showing that none is found. But, I don't really know the virus world for miners. I would think there are more than 3 and like with PC's would be being changed and new ones being made that might evade this firmware's detection.

I'll let you know what I see with viaBTC - but I'm not optimistic - the chips and chains don't look happy before they even start trying to get and process packets - so, I don't honestly think that it makes any difference what pool I connect to at this point.

---

I think my issue is with the hardware at this point. It's not the amount of the payouts or hashing power seen by Nicehash that I'm concerned with. My miners chips and chains (hash boards) look like they are damaged or trying to run at too high of a frequency for the voltage they are configure for. Currently I have all the hash boards running between 8.5v to 8.8v with frequencies of 725M to 762M - and then the individual chip frequencies adjusted for ones that could not keep up with the board level frequency setting. Now they all act like the voltages are still where I set them, but they are trying to use frequencies well over 762M - causing the chips to not be able to run properly or at all and/or hash boards dropping out completely.

Again, my concern here that something has gotten on them and is actually running the frequencies higher than the firmware is configure for and showing in their web interfaces. That could explain the 25% increase in BTC payouts from Nicehash and why the hardware is having the problems it is having - I just don't know how to verify it or fix it - or if like Philipma1957 said - somehow Nicehash switching - thrashed them somehow.

Thanks.

The choice of pool can cause chips to be marked as X's in the web interface of the miner, chains to drop, and chain status (in the miner web interface tab "Miner Status") to go from Healthy down to Slowed and cause the miner to restart? I have never had this problem with any pool including Nicehash and I've been mining with them for 2 years.

I use Awesome Miner software to manage my miners. About 2 months ago I started using the Awesome Miner Antminer Firmware. I tuned them myself - lowered voltages to 8.5V and set frequencies to 762, then, based on number of chips on a board that were not running in their happy zone, I upped voltage by 0.1 and lowered the frequency. After getting the boards so that they were at a point were most of the chips were in their happy zone, I then reduced to individual chip frequencies until I got them very consistently into their happy green zone. For the last month, my 8 S9s (S9s: S9, S9i, S9j - 13.5 to 14.5TH/s), have been running fine. Then today when I came home from work they were all only running for a few minutes each, so I check them and they are running very badly - MANY chips at 0 and red, missing whole boards, all of them only getting up to around a third or less of their regular hash rate. The firmware is set to restart them when there are more than 5 X's on a chain - so they were just setting there restarting themselves every few minutes.

Something appears to have changed around noon or so yesterday. I mine with Nicehash - and they are paying out ever 4 hours. I am generally, as of late, at around 0.00042000 to 0.00046000BTC per 4 hours cycle. But yesterday the payout at 4PM was 0.00054000BTC, then at 8PM it was 0.00055000BTC, at midnight is was 0.00051000BTC, at 4AM this morning it was 0.00064000BTC, at 8AM it was 0.00056000BTC, at noon it was 0.00058000BTC, and at 4PM it was at 0.00059000BTC. Now, I got home and saw them looking all screwed up at around 5PM and Nicehash was showing a significant drop-off after the 4PM payout - so I assume they were still running strong at 4PM as these payout are like 25% higher than normal. I restarted them all via Awesome Miner and that made no difference. I shut off the power to them via the power panel breakers and restarted them. No change. I did it again, but left them off for about 45 minutes, but still not difference. I exported the Awesome Miner history and reviewed it, for the last 30 days, and there is not change in temps or hashrate recorded for these miners before or during this 25% uptick in mining payouts from Nicehash. I NEVER get these kind of jumps in payouts from Niceshash - here and there it may get 0.00048000BTC or something, but nothing like these numbers.

I also checked the power - they are all running on Antminer APW3++ PSUs at 240V and the outlets are testing good. I thought maybe a 120V leg had dropped and they may not have been getting enough power to run properly, but this does not seem to be the case.

When I look at the web interface of the miners with the Awesome Miner Firmware running on them and check the chip frequency page where it also shows the status of the chips - MANY of them are now red 0's and almost all of the rest are in the orange/yellow zone where they are not happy (the green zone). When I was tuning them, when the were like this, I would lower the frequency on those chips by a few selections lower in the drop-down list (like from 750M to 743M or lower) and after doing this a few times which a batch of chips at a time - I got them all into the green zones. This is what is look like now. It's like the frequency is set too high for the voltage and now they are out of the happy green zone again. But, the board frequencies and voltages are the same as I had them, with the same per chip frequencies as well - yet now all 8 miners are acting like I really jacked up the frequencies on the boards. Which could make sense with the much larger payouts on Nicehash. But the web interfaces just don't show like there has been any changes to the voltages or frequencies of anything.

But to have them all running fine for well over a month with no issues and then they all go crazy at the same time - it feels like a virus or hack since everything else seems to check out. But why would they hack me, up the hashing power, and still direct it to my pool? Unless just to cause damage?

So, what do you think? What can I do, check, or whatever at this point to get them back to normal? If I re-install the firmware via using the web interface to flash/update the firmware - would this overwrite the hack/virus? All of my S9's have SD card slots, so I can boot from them directly. I was thinking of trying to boot one from SD with like Braiins OS to see if it works normal like that. But I am worried at this point if whatever is going on here has damaged my miners. Any ideas, suggestions, etc... would be great!

Thanks in advance!

Thanks! My circuit will effectively be like what you mentioned - but more advanced. I will monitor the exterior temperature, the miner intake temperature, the temperature of the interior space being heated, and the temperature of the room the miner cabinet is located in - or the exhaust heat (toggle-able) if the room temp isn't an issue. This will allow for blending air from outside to keep the intake at proper temps if too cold - and with code changes and available relays also looping in cooling sources in warm weather. It will act as a thermostat for the interior heated space in terms of the miners. Just have to set the HVAC thermostat to heat just below and cool to just above. I will be integrating this with MQTT so as to allow some integration with home automation systems like OpenHAB for remote and dynamic adjustments as well as my only remote management site. The circuit will also have smoke detection built in so intake and exhaust sides of the miner cabinet can be monitored for smoke - allowing the circuit to power down everything. To be able to do that - it will also be able to turn on/off the miners via power relays. With the MQTT integration this would allow for remote shutdown and restart when software control to a miner cannot be gained remotely. Manual overrides on the circuit via push buttons and via the MQTT system to force airflow in whatever direction in preferred - outside or interior - or turning dynamic temperature control off - meaning fans blow outside, or and outright shut down. It's pretty cool! Most of this is already coded. I need to integrate the MQTT aspects and the intake blending - but the rest is done. The circuit is designed and the breadboard prototype is operational. It will have the main PCB and sub-PCBs for the remote temp/humidity sensors that will be connected via standard CAT5/5e/6 network cables with standard network wiring - so no special pin-outs. Sensors should be good out to around 200' if I recall properly (haven't looked for a bit on that spec).

I have more deeper areas to delve into on the home automation side as well - but MQTT helps with that as well.

Anyway - it has been a fun project and I'd say right now - between heat pump power and propane - it has saved us around $2500 dollars so far. I also put in a separate commercial service to the house - it REALLY cut down on the power bills. Home power is like $0.107/KWh and the commercial power feed is running a bit under $0.07/KWh. So right now - my S9's with stock firmware are still profitable even without the power and propane considerations on the home side. I'm still a happy camper at the moment!  


Thanks @philipma1957! I just may get those. I have been buying low priced MERV 3/4 throw aways - at 12 for $36 - so that gets me to about $144 per year - so in a little over 1 year these would pay for themselves and they look like they would be easier to deal with as well. Do you use either of the cleaning/deodorizing sprays they suggest? Considering these do have the air coming into the home air space - what would be your though on these from your experience? That adds another $50 to the cost for these two sprays per what time frame...

I have 12 miners running on my bottom floor - almost a basement - but not. It is still in renovation stage. So, I have a place where two large windows are going to eventually go. I have 2 gable fans mounted on the wall where the windows will go to blow air outside with automatic gable shutters over them. In front of this, I built a cabinet with a division wall between the front of the miners and the exhaust side. The exhaust side encloses the 2 gable fans that blow outside. The front side is enclosed using 4 1"x16"x20" MERV3 air conditioning filters to filter the incoming air from the room. Then on the top of the enclosure - also pulling air out of the exhaust side I put 2 more gable fans that blow the air up. I then built a duct over top of these two fans that bring the air through a 2'x2' hole in the floor going into the main floor of the house (second floor). Next to this 2'x2' hole is another 2'x2' hole - all with side walls and chicken wire put over them so stuff cannot fall into them - including pets. This second 2'x2' area allows air from the main floor to flow into the bottom floor - creating a way for air cycling without having to use the HVAC system fans to try to move the air around. Besides that - the HVAC cannot match the air flow capacity of the gable fans. I have all 4 gable fans on smart outlets. I use an Ecobee 3 thermostat in the house. It can be used with IFTTT to turn on/off the two pairs of fans based on the house internal temp. However, I ran into issues where IFTTT alone was not switching all 4 fans at the same time - sometimes with a few minutes delay - not cool. So, I found the servie APILIO.com that allows deeper logic programming integration with IFTTT. So now, when the temp in the house goes below 69F in the house - IFTTT sets a boolean variable on APILIO to true. This triggers APILIO to turn off the 2 outside fans and turns on the 2 inside fans - this happens practically simultaneously - MUCH better then IFTTT doing it. And equally, if the inside temp goes above 69F, then the APILIO variable of set to false and then APILIO then turn off the 2 fans blowing inside and turns on the fans blowing outside.

With my 8 - S9's and 4 -L3+/++ units - in central - higher elevation WV (USA) I can heat our 1800sqft house down to about 12F outside temps. The 3000+cuft per minute of air flow from 2 gable fans cycles the air fast enough that it heats the house faster than out central HVAC system does. With the cabinet built as is and the ducting (about 8') horizontally away from being directly over the miners - the miner sound is really very mild.

I keep the Ecobee set to heat the house if the inside temp goes below 68 and to cool it to 70. So the house usually sits very nicely at 69 without the HVAC system comming on at all in winter and only to cool in warmer weather. As the miners are blowing outside in that case it works very well. The bottom floor usually stays in the 60's on its own - which actually help to cool the miners in summer. I allow outside air to come into the bottom floor as well so that it doesn't pull cooled air from the house when the HVAC is trying to cool.

The biggest issue I have had so far is Ecobee has been having problems for a while now where they are not pushing the house temp changes to IFTTT consistently - so, on occasion the house ends up at 75+ degrees with the HVAC trying to cool it back to 70 or the heat kick on on the HVAC because the miners are still having their warm air blown outside. I use Amazon Alexa and have setup routines there so that I can tell Alexa to send the miner heat inside or outside - but I cannot do it based on thermostat readings from there - at least that I have figured out yet. But still it is working much more than not - it has it's phases. Sometime this is working very well, other times there are days in a row where it is constantly messing up and has to be manually dealt with. Again - I currently believe Ecobee is 99.9% of the problem.

I am 95% done with a custom circuit design to take this logic over completely - including all temp sensors, fan relays, etc. All designed and coded - but need to get the PCBs made and then I can build it. Then the Ecobee problem goes away.

The 2'x2' holes in the floor are also temporary as this is in the location where a set of stairs will be built from the main floor to the bottom floor - probably this summer.

This has almost completely heated our home for last winter and this. Only a few times - while it is working properly - has the HVAC needed to kick in for lower temps that the miners could not handle on their own. We filled our propane tank before last winter and the gauge has barley moved since. We have a heat pump on the HVAC - but the miners have rendered it useless for heating as the heat well below its cutover point from heat pump to switching over to the propane aux heat. It does still handle the cooling though.

Once the reno is done - I will still blow the fans out of the installed windows and will be adding a duct from outside that can be blended with inside air so that when the weather get too cold for the miners to run - the air can be blended on the intake to warm it a bit. They don't like running near the freezing point. In my top duct into the main floor - I have a small opening there that allows some of the heat to go down there to help heat the bottom floor a bit. As it is still open to outside air - in the low 20's the air in the bottom floor will approach freezing - with this little opening - it keeps it in the low to mid 40's.

I'm really overall pretty happy with it - and will love it when my circuit is in my hands



These images are before I added in the top fans and duct to upstairs.

@patrike It would be great if you could split the Awsome Miner thread into 2 threads - one for GPU and another for ASIC - finding ASIC stuff in here with all the GPU/CPU related stuff is like a needle in the haystack.

I have a question - is the current firmware on the Antminer backed up when installing the Awesome Miner firmware? I would like to try it, but I don't see the process to revert back if I don't like it - or if I decide to sell the unit and want to put the original firmware back.


Thanks!

Hmmm - glad I asked. I had been primarily looking at 250v - 10A relays - but was just not sure that was enough to cut it. I will look into the contactors you suggest as well. I get the point of the surge being from the PSU - poor wording on my part - and obviously relevant. I am using all APW3++ PSU's - and one APW7.

Thanks!