Author

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

jr. member
Activity: 756
Merit: 2
If a miner crashes, it does not stop normally. also does the reset of oc?
legendary
Activity: 3346
Merit: 1094
Awesome Miner version 6.6.1

 GPU mining
  - Native overclocking can be configured to automatically reset all overclocking parameters when a miner is stopped. Configurable via the Options dialog, GPU Settings section.
  - AMD Radeon VII supported with monitoring and native overclocking on Windows
 Configuration
  - Bulk edit of pools
  - Improved bulk edit of Managed Miners, to include command line parameters
 User interface
  - Ctrl+C can be used to copy all selected objects (miners, pools and more) from the lists in the Options dialog
 Integration
  - Modify Zpool API calls to be possible to identify and accept by Zpool
 Mining software
  - Lolminer 0.8.2
legendary
Activity: 3346
Merit: 1094
Another PAtrike suggestion. In the rules, which come by default use several, one that notifies me from time to time is when an RIG reaches a temperature of 80 degrees, although I stop mining to 84.

I do not feel like putting screenshot, but when it warns you it says something like

Rig5 High temperature warning

But, you can not improve that rule to tell me what AL-GO is. Many times I find that message, and I always think, what protocol would it have been? I do not know, or I'm in front of the computer when it gives the fault and know what protocol was undermining or I do not know anything. I only know that it warmed up a bit and it is already there, but I can not correct anything if I do not know that al-go was that temperature.

Thank you
I understand your point and I've received similar feedback in the past. It would be a concept where the trigger could transfer some information to the action, like algorithm, temperature, which device it was and so on.
jr. member
Activity: 756
Merit: 2
Another PAtrike suggestion. In the rules, which come by default use several, one that notifies me from time to time is when an RIG reaches a temperature of 80 degrees, although I stop mining to 84.

I do not feel like putting screenshot, but when it warns you it says something like

Rig5 High temperature warning

But, you can not improve that rule to tell me what AL-GO is. Many times I find that message, and I always think, what protocol would it have been? I do not know, or I'm in front of the computer when it gives the fault and know what protocol was undermining or I do not know anything. I only know that it warmed up a bit and it is already there, but I can not correct anything if I do not know that al-go was that temperature.

Thank you
legendary
Activity: 3346
Merit: 1094
Just asking I guess awesome miner doesn't Support AMD Radeon VII ?. I don't expect it to be added right now just want to know.
it only shows the hash rate no fan speed, temps etc.
I will verify the support within the next few days and get back to you.
Thanks

patrike if you fixed it, i now see everything with my AMD Radeon VII/Vega rig.!!!  
Nice that it's working better. Version 6.6 included most of the implementation for Radeon VII, but there are still a few adjustments in the pipeline for the fan speed and native overclocking. The plan is that it will be officially supported in version 6.6.1.
member
Activity: 126
Merit: 10
Just asking I guess awesome miner doesn't Support AMD Radeon VII ?. I don't expect it to be added right now just want to know.
it only shows the hash rate no fan speed, temps etc.
I will verify the support within the next few days and get back to you.


Thanks

patrike if you fixed it, i now see everything with my AMD Radeon VII/Vega rig.!!!  
legendary
Activity: 3346
Merit: 1094
Hi Patrik,

Need some info on the API calls to Yiimp pools.

Online Services tab --  Update Now

and

Options > Profit Switching - under General settings - Switching interval (minutes / seconds)

Does Awesome Miner send out an Agent Name when it polls the pools API for these, if so, what is it ?

If not, can one be added and give it a name so that pool owners can identify it and not block it.

Thanks.
I've just sent you a PM about this.
legendary
Activity: 3346
Merit: 1094
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.
Implementing an auto OC reset feature is quite easy so you can expect it soon.

I will enable it by default only for new installations. For existing systems you will have to enable it as a global setting in the Options dialog, GPU settings section, once it's available.

As it changes the behavior of the OC in Awesome Miner, I cannot introduce this change for everyone as it will be a new behavior. This is the reason why it only can be enabled by default for new installations, while all existings users will have to enable it.
full member
Activity: 270
Merit: 115
Hi Patrik,

Need some info on the API calls to Yiimp pools.

Online Services tab --  Update Now

and

Options > Profit Switching - under General settings - Switching interval (minutes / seconds)

Does Awesome Miner send out an Agent Name when it polls the pools API for these, if so, what is it ?

If not, can one be added and give it a name so that pool owners can identify it and not block it.

Thanks.

jr. member
Activity: 756
Merit: 2
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.
jr. member
Activity: 756
Merit: 2
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.
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!

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.
legendary
Activity: 3346
Merit: 1094
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
legendary
Activity: 3346
Merit: 1094
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.
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!
legendary
Activity: 3346
Merit: 1094
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,

Ability to Bulk Edit Miner Properties command line parameters and environment

This can come very handy on a larger GPU farm

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

Cloning of Pool Groups is already supported.
jr. member
Activity: 756
Merit: 2
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.
jr. member
Activity: 756
Merit: 2
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.
legendary
Activity: 1764
Merit: 1024
Hey Patrike, love the addition of the glow notification! However, the two are reversed. It should blink when it hasn't been checked, and stay steady when notifications haven't been cleared. Blinking is more annoying then just being orange, so order of annoyance and severity basically.

Thanks!
Thanks for the feedback. If you enabled this feature and have at least one non-acknowledged notification, the icon will blink a few times and then constantly glow - until you activate the main window. This is currently not two separate concepts and it will only blink for a short time.

I agree that constant blinking would be more annoying. Was your point that it should blink until you looked at the notification tab once?

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.
jr. member
Activity: 756
Merit: 2
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.
jr. member
Activity: 756
Merit: 2


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.
jr. member
Activity: 756
Merit: 2
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.
Jump to: