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.
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-removedPlease 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. |
|
|
|
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.msihttps://www.awesomeminer.com/download/setupdev/AwesomeMinerRemoteService.msi
|
|
|
|
Hello, I am presenting problems with my Awesome Miner since the last update. In the mining of NBMiner - Miniz to the minutes that is working I get that it is offline. Restarts by rule. But at the time it is lost time between reboots and offline. I already test with other miners and this error does not occur I have 1080ti.
Is the case that the mining software (NBMiner, Miniz) is crashing? No matter which algorithm is being used? Can you capture that with the Diagnostics button? Please note that the first time you run the Diagnostics it will only run the mining software for 30 seconds. You can then click the Advanced button to change it to 2 minutes and run again.
Hi Patrik,
another Problem with the new Version 6.5.8
i have to restart AM every morning because AM allocates all available RAM (over 13 GB - i have it running on a very fast PC with 16 GB Ram) after about 20 hours running. AM is not responding correct - i have to wait about 10 seconds for every click ...
after restart everything works fine again (AM needs 2.6 GB RAM) for about a day... then same procedure again...
BR Ralf
Then your AM installation is defect or with your windows is something wrong. I use AM on a windows pc with 4GB Ram and mining with CPU and GPU in backround, no impacts and it runs over month. no - it's not defect... but maybe i have a few more miners than you? in the moment 733?! in former versions of AM i had no problems... Hi Ralf, I've sent you a message about this with some requests for more details. 2.6 GB for 733 miners sounds fine, but 13 GB does not. Let's investigate and resolve this.
And how you checked that your AM Installation is not defect? I think it is a problem with your PC, my Awesomeminer version use only 260mb RAM with 40 Miner and many rules.
A other Instance with 20 miner uses only 175mb Ram. So i can´t believe that 700 uses so much.
Maybe Patrike can say how much ram AM use per miner.
In general Awesome Miner doesn't consume that much more memory when adding a larger number of miners. Managed Miners will however consume more than External Miners and using features like mining history will increase the memory usage. With 16 GB memory you should be able to run 20,000 ASIC miners. |
|
|
|
Hi, How can I update the miners to the latest version in Awesome miner. Usually Awesome miner alarms me that there is an available update, but I can see no update at this moment. Some miners have released updates such as Gminer 1.47, but latest version of Gminer in Awesome miner is 1.45. Please help me
Have you got both check for new options automatically check for development versions ticked under options/general? It's correct that you need to go for the development version in order to get to Gminer 1.47 at the moment. This will however improve now when the feature 'Update mining software definitions' has been made available. This makes it possible to get mining software updates more frequently to all users, no matter if you run the public version or the development version. |
|
|
|
pls add option to send keystrokes on console view and option to save OC profiles for the entire rig in 6.6 version
great work
Thanks for the feature suggestions - they are noted. It will unfortunately not be possible to include these in version 6.6 already as this release is planned for tomorrow and there are other feature to finalize first. Saving the existing overclocking for a rig to a Clocking Group is likely to be implemented before the send key feature. |
|
|
|
Version 6.5.8 (Development preview of 6.6) FPGA mining - Blackminer F1 FPGA supported with temperature display GPU mining - Mining software definitions can be updated without upgrading the Awesome Miner or Remote Agent version - GPU clocking groups can use exact GPU name mapping - Added algorithm Lyra2z330 User interface - Added additional coin images - Description for Windows Uptime changed to System Uptime Mining software - CpuMiner-Opt 3.9.4 - SrbMiner 1.9.0 - Improved detection of when 'allcoins 1' needs to be added to the Claymore Ethereum miner command line Corrections - 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 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.msihttps://www.awesomeminer.com/download/setupdev/AwesomeMinerRemoteService.msi
|
|
|
|
like they said, deactivate the windows update and configure for mining.
you can't blame AM because of that, they are not windows developer and they are not going to create something to do "auto configure" just with 1 click.
Thanks for your comments. You are correct that Awesome Miner cannot do everything to secure that the mining environment is in good shape - but I'm actually open to suggestions about what Awesome Miner could do better in the future. It may not be a one-click that solves everything, but there might still be something to improve. A feature to deploy some good configuration baseline for Windows could be a good feature to add in the future, where Awesome Miner can help you to disable Windows update, increase virtual memory if too low and so on. |
|
|
|
I've heard about the forecasts of the warm weather in south Europe.
I do know that you have lowered your OC already because of the warm weather - can you please see if the people in your Telegram group consider that as well? It's quite often users start to experience GPU mining stability issues more frequently in May-June - I get those reports every year.
Two things you could try in Options dialog, Mining Settings:
1) Enable "Use Ctrl+C" as some mining software behave better with the enabled.
2) Consider increasing "Pause when profit switcher starts mining" and "Wait for process stop before terminating" a bit.
Point one that uses CTROL + C, where I activate that in AM, because I do not understand it in any other way. DOndende have to put it? Please go to the Options dialog, Mining Settings section, where you will find this setting. Have you been able to narrow down the issue with some troubleshooting - for example if you take one of your systems and only run it with one specific mining software and a single algorithm with no customization at all. Do you still get the same stability problems in that case? |
|
|
|
Bug - the gpu oc profiles by name , do not differentiate between say a 1660 and a 1660 Ti
Even throug the names are slightly different only the 1660 profile is applied
The name matching is based on partial matching right now. If you define to apply a profile to "1660" it will apply this to a GPU with the name "Geforce GTX 1660" although you didn't have to type the exact name. The drawback is that it would also match "1660 Ti" as you point out, because of the partial matching. There will have to be a new matching rule like "GPU Name (exact)" for this scenario. I will look into that. |
|
|
|
I've noticed an issue with User-Defined Managed Software for CPU/GPU as it relates to the algorithm/-a parameter. See below for a log from a Linux agent that shows the command line is missing the "-a m7m" parameter, and therefore fails. Has anyone else seen this and have an idea how to address it? 6/20/19 7:51:24 PM.645 [014] [S][ManagedMiner#89 - HMDNoah1 CPU] : Adding pool: stratum+tcp://m7m.mine.ahashpool.com:6033
6/20/19 7:51:24 PM.645 [014] [S]Set execution permission for: /root/AwesomeMinerService/cpuminer-opt-3.9.4-linux_3/cpuminer
6/20/19 7:51:24 PM.651 [014] [S][ManagedMiner#89 - HMDNoah1 CPU] Properties: (WindowMode: ConsoleFormat, EngineType: 20, IsProfitMiner: False)
6/20/19 7:51:24 PM.652 [014] [S][ManagedMiner#89 - HMDNoah1 CPU] ====================================================================================================
6/20/19 7:51:24 PM.652 [014] [S][ManagedMiner#89 - HMDNoah1 CPU] /root/AwesomeMinerService/cpuminer-opt-3.9.4-linux_3/cpuminer -o stratum+tcp://m7m.mine.ahashpool.com:6033 -u [redacted] -p c=BTC --api-remote -b 0.0.0.0:4030
6/20/19 7:51:24 PM.652 [014] [S][ManagedMiner#89 - HMDNoah1 CPU] ====================================================================================================
6/20/19 7:51:24 PM.757 [014] [S]Set Diagnostics executable: /root/AwesomeMinerService/cpuminer-opt-3.9.4-linux_3/cpuminer
6/20/19 7:51:24 PM.758 [014] [S]Creating start script: /root/AwesomeMinerService/cpuminer-opt-3.9.4-linux_3/awesome-start.sh, Command:
stdbuf -o L "/root/AwesomeMinerService/cpuminer-opt-3.9.4-linux_3/cpuminer" -o stratum+tcp://m7m.mine.ahashpool.com:6033 -u [redacted] -p c=BTC --api-remote -b 0.0.0.0:4030 &> "/root/AwesomeMinerService/diag.txt"
Thanks for the details. I was able to reproduce and correct the issue. It was an issue introduced in the latest development release. There will be a new release available soon. Unfortunately this still seems to be an issue in 6.5.7. For this user defined Managed Software you added for CpuMiner - have you configured it to have the compatibility mode "Full" with CpuMinerOpt? I might have identified one more issue specific to the Remote Agent on Linux here, but only related to custom algorithm parameters. Yes, it is configured as Full (Command line and API). Sorry, I probably should have mentioned in my original post, but I saw some similar behavior with the Windows agent in 6.5.6 where it would not use the algorithm argument from the "Default command line argument" column, but would use an argument from the "User defined command line algorithm" column even if it was the same value. I worked around this by simply replicating all the default args as user defined args. But this workaround did not seem to work for the Linux agent. So this may be a combination of multiple issues. I'm happy to provide any additional info you might need to track this down. What I still could reproduce on Linux for 6.5.7 was that the "User defined command line" not being used correctly and I will of course correct that. It should however fallback to use the "Default command line argument" in 6.5.7 (didn't work in 6.5.6). Is it not even doing this fallback when you test it? |
|
|
|
Thanks for the feedback.
It's correct that Linux on Remote Agent doesn't include all features and all mining software. For mining software it's about 20 of them supported and the Claymore miners should work fine.
Can you please let me know the main features you are missing? The goal is of course to continue improving Remote Agent on Linux so all feedback is of course welcome. Thanks!
Hi Patrik. Thank you for paying attention to me. I confirm that none of the Caymore`s miners work by default. Only dances with a tambourine forced Dual miner to work and then only when I registered him completely the launch line in the profile. With the rest so far did not suffer. On the tab GPU there is no control of energy consumption. Its utilites report from my test rig ========================ROCm System Management Interface========================
================================================================================
GPU Temp AvgPwr SCLK MCLK Fan Perf PwrCap SCLK OD MCLK OD GPU%
0 67.0c 80.0W 1140Mhz 2150Mhz 100.0% manual N/A 0% 0% N/A
1 64.0c 83.0W 1140Mhz 2150Mhz 80.0% manual N/A 0% 0% N/A
2 66.0c 82.0W 1140Mhz 2150Mhz 60.0% manual N/A 0% 0% N/A
3 67.0c 88.0W 1140Mhz 2150Mhz 61.96% manual N/A 0% 0% N/A
4 64.0c 80.0W 1140Mhz 2150Mhz 80.0% manual N/A 0% 0% N/A
5 65.0c 84.0W 1140Mhz 2150Mhz 100.0% manual N/A 0% 0% N/A
6 66.0c 77.0W 1140Mhz 2150Mhz 61.96% manual N/A 0% 0% N/A
================================================================================
==============================End of ROCm SMI Log ============================== I will be glad to provide all possible assistance in testing the Linux Agent, if necessary. Sincerely, Vladimir. p.s. I do not see the possibility to insert screenshots. Remote Agent on Linux supports reporting GPU power usage, just like on Windows. On most Linux based mining systems, it should work out of the box. There are for example a number of users that run on other mining distributions like HiveOS, but just uses it as a Linux system with pre-installed drivers and everything - then installing Remote Agent on it and only use Awesome Miner. If you installed your own Linux system it might be something missing, so let's figure it out. 1) Could you please send me your Remote Agent log file (toolbar Tools -> Log File -> Remote Agent) for the Linux system where you don't see the power usage. 2) Please also use the Diagnostics button to start the Claymore miner and share the output with me. Thanks! |
|
|
|
Hi all I have Premium AM and over 10 mining rigs and so I decided to transfer my rigs to Linux... What was my disappointment when I installed it on a test rig AM Linux Agent  Very limited functionality compared to the Windows version, the lack of miners, the complete inoperability of all Claymor`s miners... Do not the AM developers understand that they have no competitors in the profitability of auto-switching on Linux? Developers need to pay more attention and time to finalize the functionality of their product in the Linux version. NiceHash has already begun developing its own NHOs, the scripts are being finalized in HiveOS, but I don’t see any alternatives to AM yet ... Dear developers of AM, can you still finish AM Linux Agent? sorry fo my not good Eng  Thanks for the feedback. It's correct that Linux on Remote Agent doesn't include all features and all mining software. For mining software it's about 20 of them supported and the Claymore miners should work fine. Can you please let me know the main features you are missing? The goal is of course to continue improving Remote Agent on Linux so all feedback is of course welcome. Thanks! |
|
|
|
Lyra2z330 Algo....
I can include that one. Is there anything in addition to CpuMinerOpt you can use for mining it? |
|
|
|
Help me , very hot day  Apart from dobe OC, both I and most of the people in my telegram have stability problems with the RIGS, are frequently restarted on Offline or simply when the currency changes, depending on what the miners will be, they stay offline and by a rule reboot miner ..... I hardly use the auto profit to avoid currency changes, and just the auto profit is one of the great qualities of AM. I still think it's a Windows problem, but we'll have to adapt what needs to be fixed. I've heard about the forecasts of the warm weather in south Europe. I do know that you have lowered your OC already because of the warm weather - can you please see if the people in your Telegram group consider that as well? It's quite often users start to experience GPU mining stability issues more frequently in May-June - I get those reports every year. Two things you could try in Options dialog, Mining Settings: 1) Enable "Use Ctrl+C" as some mining software behave better with the enabled. 2) Consider increasing "Pause when profit switcher starts mining" and "Wait for process stop before terminating" a bit. |
|
|
|
I've noticed an issue with User-Defined Managed Software for CPU/GPU as it relates to the algorithm/-a parameter. See below for a log from a Linux agent that shows the command line is missing the "-a m7m" parameter, and therefore fails. Has anyone else seen this and have an idea how to address it? 6/20/19 7:51:24 PM.645 [014] [S][ManagedMiner#89 - HMDNoah1 CPU] : Adding pool: stratum+tcp://m7m.mine.ahashpool.com:6033
6/20/19 7:51:24 PM.645 [014] [S]Set execution permission for: /root/AwesomeMinerService/cpuminer-opt-3.9.4-linux_3/cpuminer
6/20/19 7:51:24 PM.651 [014] [S][ManagedMiner#89 - HMDNoah1 CPU] Properties: (WindowMode: ConsoleFormat, EngineType: 20, IsProfitMiner: False)
6/20/19 7:51:24 PM.652 [014] [S][ManagedMiner#89 - HMDNoah1 CPU] ====================================================================================================
6/20/19 7:51:24 PM.652 [014] [S][ManagedMiner#89 - HMDNoah1 CPU] /root/AwesomeMinerService/cpuminer-opt-3.9.4-linux_3/cpuminer -o stratum+tcp://m7m.mine.ahashpool.com:6033 -u [redacted] -p c=BTC --api-remote -b 0.0.0.0:4030
6/20/19 7:51:24 PM.652 [014] [S][ManagedMiner#89 - HMDNoah1 CPU] ====================================================================================================
6/20/19 7:51:24 PM.757 [014] [S]Set Diagnostics executable: /root/AwesomeMinerService/cpuminer-opt-3.9.4-linux_3/cpuminer
6/20/19 7:51:24 PM.758 [014] [S]Creating start script: /root/AwesomeMinerService/cpuminer-opt-3.9.4-linux_3/awesome-start.sh, Command:
stdbuf -o L "/root/AwesomeMinerService/cpuminer-opt-3.9.4-linux_3/cpuminer" -o stratum+tcp://m7m.mine.ahashpool.com:6033 -u [redacted] -p c=BTC --api-remote -b 0.0.0.0:4030 &> "/root/AwesomeMinerService/diag.txt"
Thanks for the details. I was able to reproduce and correct the issue. It was an issue introduced in the latest development release. There will be a new release available soon. Unfortunately this still seems to be an issue in 6.5.7. For this user defined Managed Software you added for CpuMiner - have you configured it to have the compatibility mode "Full" with CpuMinerOpt? I might have identified one more issue specific to the Remote Agent on Linux here, but only related to custom algorithm parameters. |
|
|
|
Thanks - I will include this one |
|
|
|
Is it just me or ? When i set coincalc. as primary stats provider , i'm getting price of ETH of 390$, and ofc, wrong summary for day/month When i set WTM as primary, eth is OK, but then GRIN31 ( which i mine also with NV ) , im getting competely wrong numbers ( but then ETH is ok...) Can You check this or am i wrong somewhere Thanks Please go to the Options dialog, Statistics Provider section, and define a Minimum Exchange Volume of for example 0.01 BTC. This will remove exchanges with low volume that typically gives unrealistic values. There can of course be cases where some coin provider is reporting incorrect values for a specific coin even with this configuration made. |
|
|
|
Version 6.5.7 (Development preview of 6.6) ASIC mining - 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 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 Mining software - GMiner 1.47 - WildRig Miner 0.17.8 Corrections - 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 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.msihttps://www.awesomeminer.com/download/setupdev/AwesomeMinerRemoteService.msi
|
|
|
|
Patrike tip in case you decide to put double OC Day / Night
It's just in case you do it. I think that when defining the hours of night and day, only do it in a single place in options. And do not do al-go to al-go.
So in this way changing the time to all OCs at night or day would be done only from one place and not one at a time.
It's just in case you decide to do it. You can add it in Options the choice of night / day schedules.
Thanks - Yes, that would make sense. It would however be even more flexible if you could point the Clocking Profile condition to a rule trigger you define. If you would define a Time Trigger that would be for 9 PM - 6 AM, you would have your night mode. You could then modify this rule to only trigger for certain groups of miners - and all of a sudden you have the flexibility to use time, miner and other conditions that are supported by the rules to decide which clocking profile to use. You could of couse have a single rule with a single time interval if you want to keep it simple - but you could have more than one rule if you want different and more complex ways of selecting Clocking Profiles - maybe with different time for different miner groups. Please note that the rules would only be used to decide if a trigger condition is met - they are not intended to execute any actions. Please note that this concept doesn't exist today - it's just an idea. |
|
|
|
I've noticed an issue with User-Defined Managed Software for CPU/GPU as it relates to the algorithm/-a parameter. See below for a log from a Linux agent that shows the command line is missing the "-a m7m" parameter, and therefore fails. Has anyone else seen this and have an idea how to address it? 6/20/19 7:51:24 PM.645 [014] [S][ManagedMiner#89 - HMDNoah1 CPU] : Adding pool: stratum+tcp://m7m.mine.ahashpool.com:6033
6/20/19 7:51:24 PM.645 [014] [S]Set execution permission for: /root/AwesomeMinerService/cpuminer-opt-3.9.4-linux_3/cpuminer
6/20/19 7:51:24 PM.651 [014] [S][ManagedMiner#89 - HMDNoah1 CPU] Properties: (WindowMode: ConsoleFormat, EngineType: 20, IsProfitMiner: False)
6/20/19 7:51:24 PM.652 [014] [S][ManagedMiner#89 - HMDNoah1 CPU] ====================================================================================================
6/20/19 7:51:24 PM.652 [014] [S][ManagedMiner#89 - HMDNoah1 CPU] /root/AwesomeMinerService/cpuminer-opt-3.9.4-linux_3/cpuminer -o stratum+tcp://m7m.mine.ahashpool.com:6033 -u [redacted] -p c=BTC --api-remote -b 0.0.0.0:4030
6/20/19 7:51:24 PM.652 [014] [S][ManagedMiner#89 - HMDNoah1 CPU] ====================================================================================================
6/20/19 7:51:24 PM.757 [014] [S]Set Diagnostics executable: /root/AwesomeMinerService/cpuminer-opt-3.9.4-linux_3/cpuminer
6/20/19 7:51:24 PM.758 [014] [S]Creating start script: /root/AwesomeMinerService/cpuminer-opt-3.9.4-linux_3/awesome-start.sh, Command:
stdbuf -o L "/root/AwesomeMinerService/cpuminer-opt-3.9.4-linux_3/cpuminer" -o stratum+tcp://m7m.mine.ahashpool.com:6033 -u [redacted] -p c=BTC --api-remote -b 0.0.0.0:4030 &> "/root/AwesomeMinerService/diag.txt"
Thanks for the details. I was able to reproduce and correct the issue. It was an issue introduced in the latest development release. There will be a new release available soon. |
|
|
|
|
Show Posts
