Topic: [Awesome Miner] - Powerful Windows GUI to manage and monitor up to 200000 miners - page 154. (Read 703143 times)

Please do not take long to incorporate the solution please. I've had enough for the last 2 or 3 weeks.

I already found the RESET order, but make sure it also resets the millivolts, and that it is applied BEFORE starting to mine, because as I said, if it crashes, the output OC does not apply.

I personally would add this as something transparent. That is, the user does not have to configure or touch. That by default AM does it before starting to mine. The less the user has to learn, the fewer problems they will ask you.

First the miner reset, a few seconds later, the OC that has been selected for that Al-go is applied. It's something so simple and simple that you should not need a choice. Totally transparent to the user without doing anything, and we removed a lot of problems at once.

It seems good to me as you put it, a base OC or null that you specify it somewhere. And it will always be safer to run before mining, because it may end up crashing and not running, so having it reset before undermining and applying the user's OC is perfect. Make a normal stop or crash, when going to mine, along with the Start command the zero OC or reset and then the OC the user. The truth is that all this has driven me crazy.

Now for example if it crashes, it is very easy then not start well I have to be aware, and when the miner launches and before I fail, I give STOP to apply the OC output correcting the OC and millivolts.

I already have hardly any failures or problems. It has been hard for me to identify the problem. I do not have any fall of any miner, it could be considered normal But what happened to me until now was not normal, now I understand it and only those of us who handle so many options are exposed to have and discover failures.

Awesome Miner version 6.6

 ASIC mining
  - Improved support for Avalon 921 with display of chip temperature and more details
  - Obelisk SC1 second generation supported with hashrate and temperature information
  - Improved configuration of Antminer API Access to make it easier to only allow connections from the computer where Awesome Miner is running
  - Automatic API Access configuration can be configured to only be applied for specific miners and miner groups
 GPU mining
  - Improved mining software selection where older mining versions can be selected and the supported nVidia CUDA version can be detected
  - Global fan control using a fan/temperature curve with the native overclocking feature. Configurable in the Options dialog, GPU Settings section.
  - Remote Agent on Linux will report nVidia driver version and system memory usage
  - Mining software definitions can be updated without upgrading the Awesome Miner or Remote Agent version
  - GPU clocking groups improved to also support mapping based on the exact GPU name, GPU vendor and PCI Bus Id
  - Improved display of AMD GPU information on Linux with vendor and power usage
  - Added additional algorithms
 FPGA mining
  - Blackminer F1 FPGA supported with temperature display
 Configuration
  - SSH connection timeout configurable in the Options dialog, Advanced section. Default timeout is now set to 8 seconds.
 Features
  - Added a backup and restore feature to the toolbar Backup (renamed from Import/Export), intended for a complete backup of all configuration data
  - GPU miner diagnostics can be configured to run for up to 5 minutes before terminating
 User interface
  - Network scan improved to display more relevant information about the found miners
  - Network scan indicates the number of scanned IP addresses and the number of found miners
  - Added additional coin images
  - Description for Windows Uptime changed to System Uptime
  - Added menu item for launching the web interface for the selected ASIC miner. Available via the toolbar Tools -> Antminer&ASIC.
  - Display of total miner commands in queue for External Miners (for large systems only)
 Mining software
  - Claymore Ethereum Miner 14.7
  - Ethminer 0.18.0 rc0
  - TeamRedMiner 0.5.2
  - T-Rex Miner 0.12.1
  - GMiner 1.47
  - CpuMiner-Opt 3.9.4
  - SrbMiner 1.9.0
  - Nanominer 1.4
  - WildRig Miner 0.17.9
 Corrections
  - Added missing Blake2b pools
  - Improved detection of xauthority environment variable on Linux for nVidia clocking
  - Improved detection of when 'allcoins 1' needs to be added to the Claymore Ethereum miner command line
  - Initialize GPU clocking information when Remote Agent on Linux is starting, to speed up clocking operations
  - Correction to algorithm command line argument for user defined mining software
  - Correction to a timing issue where a miner group in Awesome Miner could be lost
  - Correction to user defined mining software customization for Remote Agent on Linux
  - Correction to z-enemy miner integration on Linux

Thanks for sharing your findings.

Today Awesome Miner can have a "Stop" profile for the clocking and it's possible to add a "Reset" command here manually if you go to the Options dialog, GPU Clocking Profiles section, add/edit a profile where you can add "Reset". This is supported on both AMD and nVidia and will send a overclocking reset command to the GPU drivers. This will restore all clocking/voltage/fan settings for a GPU to default values.

When a miner is either manually stopped or has crashed, Awesome Miner will run the specified "Stop" clocking profile.

Although it's possible to have a setup like this - it's a bit time consuming to setup. What I think is the way forward is to have a global setting like "Reset GPU clocking when miner has stopped". If enabled, Awesome Miner could reset the GPU clocking completely via a reset command to the GPU drivers. In your case it would also reset the voltage setting to default. Please let me know if you think a feature like this would make sense to have globally. Thanks!

Thanks for all good suggestions. It's all noted. Especially bulk operations should be a priority.

Cloning of Pool Groups is already supported.

Another failure. If I throw a coin with an OC that has a limitation of millivolts, and this miner crashes, the OC of stopping with the neutral OC does not apply. And therefore the limitation of millivolts of the previous currency remains again. When wanting to start mining again, as you go to another currency that needs more tension, the miner stays in offline miner in the AM interface

I think the most appropriate measure is to apply a neutral OC without limitation in millivolts before mining and before applying the OC that I have chosen. Then it will not matter if it has crashed.

After several hours trying to include an output OC with a limit of 1200mv volts 90 0 0 I no longer have the problem that both insisted and not many saw

It would be advisable that when you use functions for an OC, when you finish mining, return to a neutral state. This way you will get rid of questions and inconveniences for users.

Now I only have some miner failure due to OC times, I recessed and fixed it. But before if he used an OC with a low voltage, then he would stay, but when he switched from AL-GO to one that consumed more, he would not start the miners, and he would stay for hours and hours as seen in the previous captures, without giving an error , but without working.

Yup, assuming the person looking at the computer basically acknowledges them by looking at the AM window. Remaining orange is like a 'reminder' that something is still wrong, which is cleared by acknowledging the notifications.


Another small very useful tweak that has bugged me for some time. Please allow people to enable a debug mode or something, where they can pause a miner so when it freezes, it doesn't restart and the window remains active. Essentially what happens if you use a pause command line window in windows. This is extremely valuable for troubleshooting.

Bug and solution

I have seen something curious doing tests. That does not have to happen to many if they do not use the OC module with all its options.

I explain. Imagine that I launch an al-go and this in your OC has a limitation of 700mv for example 700mv 80 power 80 core 500 mem.

When finishing this service, if I change to another one that does not have a volt limitation, for example 85 90 500, it turns out that AM, the limitation to 700mv is brought from the previous one. Since I have not specified a maximum limit, it continues with the previous one.

This forces me to put an OC to finish mining that has 1500mv 90 0 0 to make it more neutral, and if the next al-go has no limitation of volts, it has a very high limit.

I also notice that when changing OC in the tests, during the first reboots the data of the previous OC remains instead of the new selected one., I suppose that there will be some cache to support 20,000 platforms.
my doubt is that if AM should take the parameters of OC to normal, when it ends up mining an al-go, so that the next one does not have limitations that come from behind, or I will be forced to put the OC to finish with 1500 90 0 0, for me to leave the values ​​in normal numbers.

Those who use ASIC, do not have to use the OC, those who use free or small versions, do not have the control of advanced OC, and for that reason many people do not fail, they have an average OC in Afherburner and do not have this problem.

I have 5 restart and reboot in rig 6, which I have set to all the logs the output OC to 1500 90 0 0, and now it does not fail.

I think you're already having more clues to the problem. I have noticed looking at the profile of OC and although it had the normal values, in that OC I did not limit the Volts, but if I marked the limitation of 700mv of another OC different. And there goes the problem.

6 restart anf reboot, I have no problems. Please check the OC module and please, if a following OC has no mv limitation, do not leave it as it was before, because that is what is causing the problem.

after 6 manual reboot, and without changing anything. Run cucka29 with gminer in nicehash. without changing anything. This is what I mean, it's driving me crazy.

try with 1080ti or rtx2080 Cucka29 with gminer 1.47 the same one that you incorporate, with the Windows updated to stop. In 1070 it happens very rarely.  It happens a lot also with nbminer

That equipment is I5 with 4 GB (also fails in the 1080ti with 8 gb ram), ssd and left over.

Acabao to do manual reboot and again is with cucka29 gminer 1.47 in "online interface" and does not start. But it happens with MTP, but if you want to try, you can use cucka29 or 31 or cuckcycle but try better with cuckca29 since it is the most recurrent.

I understand that the online interface is that somehow the connection with the machine is lost, but even if the connection is lost, the miner does not start seeing it on the remote screen.

As I mentioned, it occurs with rtx and 1080ti to a greater extent. I have installed all the updates including the last corrected version of 10.1 of cuda, I also have the 9.2, all the visual etc ... Everything is fine and at times it goes well and at long intervals it goes wrong.

I have tried even with OC of 50 0 0 and leaving everything to 0. If it does not start, it is no longer a problem of OC, nor temperature, that no one else recommends me to look because I am not a novice and all that I have already reviewed.

The 1705 creator versions, for what they have told me in the group, work, less hash, but it works. It's the ones we installed 1809, and there's still another version that I have not installed because it does not leave me, the 19xx

I can not be seeing that some or miners, I use very few, right now tell you that I only use Nicehash with 7 algos, to minimize changes
cucka29
cucka31
MTP
cucacycle
x16r
equihash 150.5
zhash 144.4

I only use 3 or 4 miners, cryptodredge, tt-rex, gminer, Nbminer

When more happens it is with Gminer and Nbminer, in the Cucka and MTP

In the capture puts 82% of time of mining, is unreal, all the time that is as in the previous capture, online interface counts as valid. That's the restarts. That rig is RTX and today it would have had more than 50 reboot

I am writing you this 2 message and still follow the RIG 6 with online interface and it does not restart ... I am fed up with this situation.

This is not an error by OC, nor by heat, nor anything that affects me. Deactivated the antivirus and Firewall completely. This is just an example of a rig, it happens to me in more rigs, it happens to more people in more RGIS.

When it is in that state, it does not fail, it does not give notification, it does not freeze the machine, if the machine were frozen the whatdog by USB would restart it. You can stay for hours, until I realize and reboot, and even after reboot sometimes does the same and we are in the same failure.

It does not communicate well the remote with AM, it can be the administrator mode, or it can be the last updates.

I repeat, it does not leave error notification because basically until I do not reboot it does not leave there, it can stay hours and hours.

This is killing me, some machines do it more, others do less. But especially the 1080ti and the rtx 2080, although to a lesser extent also in the 1070.

The admin mode matches me (this affects the fan curve and the limitation of volts), if I do not affect the administrator mode.

This failure is happening a lot and it is making me lose a lot of time every day. I had to create specific rules that if there is no HASH during X seconds, reboot, but sometimes it does so many times until at the end a miner starts.

As I said, it's not OC, it's not heat, it's not my configuration, it's an Intelibreeze failure.

Ability to Bulk Edit Miner Properties command line parameters and environment

This can come very handy on a larger GPU farm

In case the MSI-based package upgrade or removal fails, please use this tool from Microsoft to force the removal:
https://support.microsoft.com/en-us/help/17588/fix-problems-that-block-programs-from-being-installed-or-removed
Please also note that if there are any pending Windows updates (even small patches) about to be installed - it typically requires a reboot before you can install any software based on the MSI-installer concept.

For the other problems you describe it would be good to get some more specific details about when it's failing and what kind of fault isolation and troubleshooting steps you have taken already. General issues about GPU mining can be difficult to resolve when running a more complex setup with multiple mining software, multiple algorithms, multiple clocking settings and a frequent change between all of these. I would suggest trying to find a stable baseline on one of the miners, by making sure it's running 100% stable with a single mining software on a single algorithm. Then you can start to add more algorithm, then more software, then multiple OC profiles and so on to find out when it's breaking.

Previously you pointed out that your systems running an older Windows build was running more stable. Is that observation still correct?

I've also sent you a PM about a log file.

I almost always have some (but not all) rigs failed to update Remote Agent each time there's an update till 6.x.x the issue are less. However, usually due to slow network, CPU too slow to respond (shitty celerons....) and installer timeout. when this happens, my solution is remote into the rig, exit Remote Agent process or reboot if it won't terminate for some reason. go to your %appdata% /Roaming/AwesomeMinerService/ folder and manually run the downloaded installer from there, it almost always downloaded the installer fine, but just msiexec process either occupied by another process (including windows update) or timed out and need manual intervention, not sure if this will help with the remote not updating on your rigs.

As for other issues, I can't comment as I haven't had much Windows 10 rigs where OC was causing issues, then again, I only have 2 rigs that runs windows 10 and they are not full mining rigs, though they do run the 1903 build

Hi Patrik & Fellow Awesome Miners,

A few ideas (some might not necessarily be practical / useful)

• Ability to Bulk Edit Pool Properties - Especially Worker name, Worker password, Wallet Address, Profit Factor field
• Ability to clone Pool Groups
• In conjuction to above, ability to have the Pool Groups the ability to override the fields in point #1 (which can make the first 1 points obsolete and completelly replaced by this one IMHO), This is particularly useful for pools like Zergpool where one want's to switch between coin addresses/payout coin type/coin targeting/solo or shared mode switching
• Ability to fetch Auto-Exchange Status via pool API and consequently include/exclude from a Pool Group (mining a coin when AE is disabled generally means no reward when payout coin needed to be exchanged)
• Ability to parse Online Services' Actual payout % to individual pools according to their algorithm (Yiimp pools somehow seems to have poor luck, or at least I find mining on Zergpool generally have efforts way > 100% across all algos, shared or solo mining
• Ability to detect and compare coin price delta (daily, 7day, 30day ... etc) and set it as a rule trigger, basically interested in the pairs (BTC/USD, XXX/BTC where XXX is an Alt pair of choice) due to the delaying nature of auto-exchange and correlation between major coins espeically BTC leading entire crypto up and down, sometimes this can automate a more optimal exchange option rather than manual (i.e, sometime it's better to mine and AE to BTC, other times it is better perhaps to be paid in say, LTC for example)

Best Regards,

this is crazy. Now the remote fails me the installation in some machines, the other day in one, today in two. And the only way to fix it is to erase everything from awesome miner of REGEDIT, restart and install, otherwise, it will not let me.

Intelibreeze is accumulating errors, the program is becoming increasingly unstable and the proof is that I have never had problems with the updates but if lately.

When you want to realize, there will be many problems to solve.

Much development for Asic but you are leaving aside the windows and the errors that many people are reporting. I am dissatisfied lately of the resolution of failures in Windows and it is affecting me. Even if you lower the OC, or even if you leave it neutral 100 0 0 or 90 0 0, some rigs still remain in offline service or similar problems that did not happen 2 months ago.

Windows advances with its updates and the remote is giving problems, I mean intelinreeze.

Version 6.5.9 (Development preview of 6.6)

 GPU mining
  - Improved display of AMD GPU information on Linux with vendor and power usage
 Configuration
  - SSH connection timeout configurable in the Options dialog, Advanced section. Default timeout is now set to 8 seconds.
 Features
  - Added a backup and restore feature to the toolbar Backup (renamed from Import/Export), intended for a complete backup of all configuration data.
 User interface
  - Added menu item for launching the web interface for the selected ASIC miner. Available via the toolbar Tools -> Antminer&ASIC.
  - Display of total miner commands in queue for External Miners (for large systems only)
 Mining software
  - Nanominer 1.4
  - WildRig Miner 0.17.9
 Corrections
  - Correction to z-enemy miner integration on Linux

To get access to development versions, open the Options dialog in Awesome Miner. In the General section, enable Check for development versions. Then go to the Menu and click Check for updates.

Direct download links if needed:
https://www.awesomeminer.com/download/setupdev/AwesomeMiner.msi
https://www.awesomeminer.com/download/setupdev/AwesomeMinerRemoteService.msi

Ok thank you. So i believe he has some wrong settings in AM or he has another problem.