[Awesome Miner] - Powerful Windows GUI to manage and monitor up to 200000 miners

[coinzforu]

Hi There,

Is it possible to configure AwesomeMiner to monitor an Avalon 741 ?

UPDATE:

Managed to figure it out.  On the Avalon, I had to change the "API Allow" setting under the advanced options

[1714119173]

1714119173

[1714119173]

1714119173

[1714119173]

1714119173

[omshree]

Hi, using AM for a Baikal farm, but if I change pool from within AM, the algorithm always jumps to X11, regardless of the coin, making it useless. Is there a solution for it, to configure the algorithm too for baikal, as the pool change is working, but only invalid shares occur.

[puwaha]

Today Awesome Miner is not saving the profit information from these coin statistics sources, it only uses the API's provided by them to get current profit (configurable to 24h actual profit in the next release).

Yes, I'm aware that this data was only a current statistic.  We had talked about this a few weeks ago where I made the suggestion to have a small database, caching this information to have AM build it's own moving average for display and use in the logic of profit-switching, if the user chooses that method.  I only brought it up again, because I want people to understand what these figures represent.  I think a 24 hour or longer moving average would be a really neat feature to have, and I'm eager to play with it to see if my theories hold true in real life.

I had also emailed you a few months ago about something similar for the temperatures and hashrate graphs on the Dashboard tab, if they or other statistics were cached in a database for analysis, probably in a small database.  You mentioned that AM wasn't doing this currently, which is fine.  I realize adding a database of some of these values might be a significant feature to add, but it might be good to expose some of this data to the user to make some deeper analysis of their miners if they choose to do so.  I think it would be a cool feature to add that would make Awesome Miner stand out, especially for your larger miner customers who have the bandwidth to do this kind of analysis (or us number nerds!)  And of course, I would expect this feature to only be available in a higher cost edition of AM.  No pressure from me... I'm just trying to help with some ideas on how to make AM better, and more effective for users.

There's already a ton of features I haven't gotten around to testing like the the Profit Factors like you mention below.

If you only select Nicehash, Zpool and MPH for the profit switcher, then the information from WhatToMine and Coins tab isn't used. However, if you add a custom pool or pools, it may be a single coin pool for Dash or Signatum. For these single coin pools, the profit information from WhatToMine is used - which is also what you see on the Coins tab. If for example Signatum is more profitable than what Nicehash and the others have, the profit switcher will go for Signatum. So the profit switcher is already comparing single coin pools (WhatToMine statistics) with the multipools (Nicehash, ... statistics).

For a given Profit switching profile, you can compare the Profit values in the Coins tab and the Online services tab.

That's what I assumed was going on under the hood, but I'm glad you clarified it here.  I think the more exposure the user has to some of the logic or where AM is using what statistics where is helpful to the user to understand how to setup AM so that it works for their situation.  It's already very very flexible in many different scenarios, but that flexibility comes at a learning curve cost for the end user.

Would it be possible to add the Whattomine statistics to the Online Services tab?  If I'm reading your quote above correctly, AM will use both tabs for profit switching if I had selected the NH and custom pool profit, but it might be confusing to the user how AM uses those two tabs differently.  Or at the very least some labels on the tabs (Coins and Online Services) so that the user understands how those two sets of data are used by AM.

What you can do if you don't like Nicehash except when it's super-profitable is to define a lower "Profit factor" in the Options dialog, Online servies section. For each pool from Nicehash, zpool and MPH, you can specify for example 80% Profit factor. That will make it look less profitable for Awesome Miner, but if it becomes much more profitable than a single coin, the profit switcher would still use it.

Thank you, this definitely would have been a future question.

[Chapster]

Hello Patrike:

Thanks for the new updates. I really appreciate that you are opening up the program and, step by step, making things more customizable and less hard coded.
For that reason I upgraded my copy to Premium two days ago.
Even though the program still doesn't allow me to do the things I want, I feel it will be there soon.

In that regard, is it possible to make AwesomeMiner ask directly AfterBurner to switch to X profile depending on the algorithm being ran?
I know that you recently added the capability to modify settings for each GPU but I find it more difficult and cumbersome to do it from AM as opposed to doing it from AfterBurner where I already have all the profiles I need and every card adjusted for max efficiency.

Right now I'm doing it by using a rule which detects the pool URL and also detects when the miner connection is established and then launches an external program to force AfterBurner to switch the profile.
Unfortunately, that detection is not always accurate and sometimes AM doesn't execute the rule.

The same happens with the "Check Statistics->Accepted" rule. That one is really buggy and is only triggered after the accepted number is above 10.
To test it, I configured several notifications with several "Accepted", from 0 to 20.
The ones from 0-10 were never ever triggered and the rest would sometimes trigger and sometimes not.

[puwaha]

I get that FOMO when using Nicehash, because in AM, the daily rate it shows is usually much lower than the "profit" that MPH or Zpool show.  I'll mine at NH for a few hours then ask myself why am I mining at such a lower rate than what I was getting at MPH for instance.  Then I wonder, why am I even bothering chasing coins, and go back to mining my favorite single coins and turn off profit switching.

I want to like NH, but it's got big fees, you only get paid what the buyers "market" will pay out, and just doesn't seem as profitable as the others.  I think there is a thread here, where someone put 3 equal rigs on NH, MPH, and ZPool for seven days and surprisingly ZPool came out ahead.  I was always hesitant to use ZPool because it's had some bad reviews in the past of them "stealing" large percentages of hashrates, intentionally switching your rigs to less profitable algos because they need to level out others and more.

I think I'll give Zpool a go through AM for 24 hours and see what happens.

I tried MPH for two weeks and it didn't make the cut for me. I have 6 cards and my hashrate got divided into so many coins that it took forever to exchange on the first week. On the second week I manually limited the algos to Daggerhashimoto and Equihash and earnings were still lower than NH. I think the reason is what I stated before, by the time they exchange the price of the coin isn't the same. I barely made 0.010 BTC with MPH in one week, while I consistently make 0.017 BTC in NH per week.

The high fees are really an illusion produced by the "lower fees" of the other pools. Yeah, you mine at 0.9% in MPH, but you still pay a fee for exchange, cash out and miner fee. When you add all the fees it's pretty much the same (still lower, but not that much to say you're earning way more). Yeah, NH charges a 4% fee for payments to an external wallet, but that's it (of course there's also the miner fee). And if you have enough hash power to make about 0.03 BTC per day, then mining to the NH wallet gets cheaper and cheaper.

This is a really good point about the "veiled" processes going on with MPH and Zpool.  It's just too hard to predict how your coins will be treated if you use their auto-conversion or auto-exchange features. That makes the simplicity of using NH a positive in it's favor.

EDIT:
Argh!  Looks like Zpool is having troubles again today, so I won't be able to do a 24 hour analysis of them until they get a little more stable.  I don't know what I would do without the notifications from Awesome Miner.  I should really do a deeper dive on the rules to see if there's a better way to automate situations like this.

[omshree]

So there is no solution for Baikal mines to change pool via AM?

[patrike]

Hi, using AM for a Baikal farm, but if I change pool from within AM, the algorithm always jumps to X11, regardless of the coin, making it useless. Is there a solution for it, to configure the algorithm too for baikal, as the pool change is working, but only invalid shares occur.

So there is no solution for Baikal mines to change pool via AM?

Hi,
The are a number of users running Baikal miners with Awesome Miner, and from a monitoring point of view it works great. However, the pool change operation in combination with a change of algorithm is for sure an issue. Baikal miners uses an older version of sgminer, and it looks like that interface doesn't support change of algorithms. I had one users that recently tried to contact Baikal about this to see if they could do anything about it - but I don't have any updates on it right now.

From an Awesome Miner point of view I can unfortunately not do anything about this situation, as Awesome Miner is using the cgminer and sgminer interface standards (API), and it doesn't look like the Baikal miners fully support that.

[patrike]

Today Awesome Miner is not saving the profit information from these coin statistics sources, it only uses the API's provided by them to get current profit (configurable to 24h actual profit in the next release).

Yes, I'm aware that this data was only a current statistic.  We had talked about this a few weeks ago where I made the suggestion to have a small database, caching this information to have AM build it's own moving average for display and use in the logic of profit-switching, if the user chooses that method.  I only brought it up again, because I want people to understand what these figures represent.  I think a 24 hour or longer moving average would be a really neat feature to have, and I'm eager to play with it to see if my theories hold true in real life.

I had also emailed you a few months ago about something similar for the temperatures and hashrate graphs on the Dashboard tab, if they or other statistics were cached in a database for analysis, probably in a small database.  You mentioned that AM wasn't doing this currently, which is fine.  I realize adding a database of some of these values might be a significant feature to add, but it might be good to expose some of this data to the user to make some deeper analysis of their miners if they choose to do so.  I think it would be a cool feature to add that would make Awesome Miner stand out, especially for your larger miner customers who have the bandwidth to do this kind of analysis (or us number nerds!)  And of course, I would expect this feature to only be available in a higher cost edition of AM.  No pressure from me... I'm just trying to help with some ideas on how to make AM better, and more effective for users.

There's already a ton of features I haven't gotten around to testing like the the Profit Factors like you mention below.

In the future it should probably be some improvement to the Performance history feature that is quite limited today. I fully agree that the amount of information Awesome Miner should be able to collect is large, and that very interesting analysis could be applied to this data. These ideas makes perfect sense.

I've also been thinking about if this entire deep analysis field could be another kind of application, possibly developed by someone else, in the future. Awesome Miner do provide API's that can be used to extract a lot of information. An external application could collect a lot of data based on that and do more advanced analysis and processing on it.

If you only select Nicehash, Zpool and MPH for the profit switcher, then the information from WhatToMine and Coins tab isn't used. However, if you add a custom pool or pools, it may be a single coin pool for Dash or Signatum. For these single coin pools, the profit information from WhatToMine is used - which is also what you see on the Coins tab. If for example Signatum is more profitable than what Nicehash and the others have, the profit switcher will go for Signatum. So the profit switcher is already comparing single coin pools (WhatToMine statistics) with the multipools (Nicehash, ... statistics).

For a given Profit switching profile, you can compare the Profit values in the Coins tab and the Online services tab.

That's what I assumed was going on under the hood, but I'm glad you clarified it here.  I think the more exposure the user has to some of the logic or where AM is using what statistics where is helpful to the user to understand how to setup AM so that it works for their situation.  It's already very very flexible in many different scenarios, but that flexibility comes at a learning curve cost for the end user.

Would it be possible to add the Whattomine statistics to the Online Services tab?  If I'm reading your quote above correctly, AM will use both tabs for profit switching if I had selected the NH and custom pool profit, but it might be confusing to the user how AM uses those two tabs differently.  Or at the very least some labels on the tabs (Coins and Online Services) so that the user understands how those two sets of data are used by AM.

I have been getting requests about combining the tabs for Coins and Online services. From a profit presentation point of view, it makes sense to combine them, because that's exactly what the profit switcher is doing. If you have Signatum on top at $12 on the Coins tab and Nicehash X11 on top at $11 on the Online services tab, the profit switcher will go for Signatum - if you have that as a custom pool to the profit switcher. So from a profit number point of view, combining makes sense.

Then we have the other aspect, and that is what kind of information to present about individual coins and about pools like Nicehash. For coins you have much more data and exchange rates and so on, and also the option to edit the coin properties. Combining this together with something like Nicehash could look strange. I'm not saying that these two tabs will be separate for all future, just that there are both benefints and drawbacks with both solutions.

[patrike]

Hello Patrike:

Thanks for the new updates. I really appreciate that you are opening up the program and, step by step, making things more customizable and less hard coded.
For that reason I upgraded my copy to Premium two days ago.
Even though the program still doesn't allow me to do the things I want, I feel it will be there soon.

In that regard, is it possible to make AwesomeMiner ask directly AfterBurner to switch to X profile depending on the algorithm being ran?
I know that you recently added the capability to modify settings for each GPU but I find it more difficult and cumbersome to do it from AM as opposed to doing it from AfterBurner where I already have all the profiles I need and every card adjusted for max efficiency.

Right now I'm doing it by using a rule which detects the pool URL and also detects when the miner connection is established and then launches an external program to force AfterBurner to switch the profile.
Unfortunately, that detection is not always accurate and sometimes AM doesn't execute the rule.

The same happens with the "Check Statistics->Accepted" rule. That one is really buggy and is only triggered after the accepted number is above 10.
To test it, I configured several notifications with several "Accepted", from 0 to 20.
The ones from 0-10 were never ever triggered and the rest would sometimes trigger and sometimes not.

I've recently added the option to select GPU clocking profile for a Managed Miner, and being fully aware that this is not the complete solution. Please note that the GPU clocking profiles you can save in Awesome Miner isn't related to the profile concept in MSI Afterburner. Awesome Miner needs to control this on a large scale and cannot assume you already have identical setup of profiles in MSI Afterburner on all computers.

What I'm planning to do is to use the configuration dialog for the Managed Software, where you per algorithm can configure both the built-in software and user defined mining software, and add the GPU clocking profile setting in here as well. That would make it possible to have one GPU clocking profile for for each algorithm for each mining software. Endless flexibility!

The Accept progress rule is typically used to compare current Accepted share value with a previous one, to make sure it's increasing. If you set it to compare with a value 5 minutes ago, it will take at least 5 minutes before it can trigger, and then it will only trigger if Accepted share is identical (which indicates that the mining isn't progressing as it should). Is this the scenario you are using with your Accept rule or is it another case you want to take care of? Maybe you could send a screenshot of the properties of this Accept trigger so I get a complete understanding of it.

[breich]

I personally feel it's better to look at a coin's average... maybe 24 hours is a good indicator, but I prefer longer averages to the tune of 3 days to a week.  You will get much more consistent profits by mining a coin that stays popular at #3 all week than trying to chase coins that tank before you can see the profits.  It's kind of counter-intuitive.  I'm hoping Patrike can add some more customization in determining the parameters on how the profit switching works.  Whattomine.com already has parameters to look at 24 hour, 2 day, and 3 day averages.

I started looking into this a little while ago when it was discussed last time, and I found a way to support 24h avg statistics for Nicehash, zpool and WhatToMine - but not for Mining Pool Hub.

I will go ahead and make the implementation for these sources that supports it, because it's only a small implementation. I will add a new settings in the Options dialog (probably in the Statistics sub section for Coins&Profit) where you can select between "Current" and "24h average". This will be used for the information you see on the Coins tab, the Online Services tab and for the profit switcher.

You are correct that WhatToMine is very flexible here, but the other sources are not.

Yes, the only way you could do it with MPH is to have AM keep it's own running average every time it checks WTM or Coinwarz.  Which kind of lends itself to a couple of questions I've had.

When using profit switching, AM is strictly relying on what NH, MPH, and ZPool say is the most profitable, correct?  the Coins tab data is really just there for convenience?  Is there a way to match what WTM says is "most profitable" to one of the profit-switching services?  Or does that happen only when you use a custom pool grouping with a managed profit miner?

Another question I have deals with the hashrates defined in the Algorithms or Profit Profiles.  When we manually put in the hashrates or use the really awesome new benchmarking feature... should the rates defined there be a single card or the entire rig?  Does AM extrapolate that I have  6 cards and use the multiple rate when determining if switching to a different algorithm should be done?

As long as your benches are all the same--pegged for one card or pegged for six--it doesn't much matter.  Personally I have a separate profile for my 1070 rig as they actually hash slightly different from my 1080 Ti rigs.  Each set of my benches are pegged to 1x of that card. 

[Chapster]

The Accept progress rule is typically used to compare current Accepted share value with a previous one, to make sure it's increasing. If you set it to compare with a value 5 minutes ago, it will take at least 5 minutes before it can trigger, and then it will only trigger if Accepted share is identical (which indicates that the mining isn't progressing as it should). Is this the scenario you are using with your Accept rule or is it another case you want to take care of? Maybe you could send a screenshot of the properties of this Accept trigger so I get a complete understanding of it.

No, I'm comparing it to some specific value. Examples:

This one is NEVER triggered:


This one is sometimes triggered (same result if you choose "equals" instead of "less than or equals")



This one is almost always triggered:

[puwaha]

Another question I have deals with the hashrates defined in the Algorithms or Profit Profiles.  When we manually put in the hashrates or use the really awesome new benchmarking feature... should the rates defined there be a single card or the entire rig?  Does AM extrapolate that I have  6 cards and use the multiple rate when determining if switching to a different algorithm should be done?

As long as your benches are all the same--pegged for one card or pegged for six--it doesn't much matter.  Personally I have a separate profile for my 1070 rig as they actually hash slightly different from my 1080 Ti rigs.  Each set of my benches are pegged to 1x of that card. 

After I posted that, I thought about it for a minute and realized the same thing.  I also have separate benchmarked profiles for my 1070s and 1080tis.  I think the issue that someone may run into is if they have a rig full of mixed cards.  It's not as easy or clean to define for someone who has a mixed AMD and nvidia rig for instance.  The neat thing about Awesome Miner, is that you can deal with these situations.  It takes a little cleverness though.

You could setup two managed miners to point to the same host, and set the managed software to only use GPU 0,1,2 in the custom command line settings (applying an AMD profit profile), and then another managed miner to use managed software to only use GPU 3, 4, 5 (and applying an nvidia profit profile).

Of course, the mining software has to support targeting specific GPUs at the command line level, and there may be other ways of dealing with mixed rigs that I haven't thought of off the top of my head.

[puwaha]

Today Awesome Miner is not saving the profit information from these coin statistics sources, it only uses the API's provided by them to get current profit (configurable to 24h actual profit in the next release).

Yes, I'm aware that this data was only a current statistic.  We had talked about this a few weeks ago where I made the suggestion to have a small database, caching this information to have AM build it's own moving average for display and use in the logic of profit-switching, if the user chooses that method.  I only brought it up again, because I want people to understand what these figures represent.  I think a 24 hour or longer moving average would be a really neat feature to have, and I'm eager to play with it to see if my theories hold true in real life.

I had also emailed you a few months ago about something similar for the temperatures and hashrate graphs on the Dashboard tab, if they or other statistics were cached in a database for analysis, probably in a small database.  You mentioned that AM wasn't doing this currently, which is fine.  I realize adding a database of some of these values might be a significant feature to add, but it might be good to expose some of this data to the user to make some deeper analysis of their miners if they choose to do so.  I think it would be a cool feature to add that would make Awesome Miner stand out, especially for your larger miner customers who have the bandwidth to do this kind of analysis (or us number nerds!)  And of course, I would expect this feature to only be available in a higher cost edition of AM.  No pressure from me... I'm just trying to help with some ideas on how to make AM better, and more effective for users.

There's already a ton of features I haven't gotten around to testing like the the Profit Factors like you mention below.

In the future it should probably be some improvement to the Performance history feature that is quite limited today. I fully agree that the amount of information Awesome Miner should be able to collect is large, and that very interesting analysis could be applied to this data. These ideas makes perfect sense.

I've also been thinking about if this entire deep analysis field could be another kind of application, possibly developed by someone else, in the future. Awesome Miner do provide API's that can be used to extract a lot of information. An external application could collect a lot of data based on that and do more advanced analysis and processing on it.

If you only select Nicehash, Zpool and MPH for the profit switcher, then the information from WhatToMine and Coins tab isn't used. However, if you add a custom pool or pools, it may be a single coin pool for Dash or Signatum. For these single coin pools, the profit information from WhatToMine is used - which is also what you see on the Coins tab. If for example Signatum is more profitable than what Nicehash and the others have, the profit switcher will go for Signatum. So the profit switcher is already comparing single coin pools (WhatToMine statistics) with the multipools (Nicehash, ... statistics).

For a given Profit switching profile, you can compare the Profit values in the Coins tab and the Online services tab.

That's what I assumed was going on under the hood, but I'm glad you clarified it here.  I think the more exposure the user has to some of the logic or where AM is using what statistics where is helpful to the user to understand how to setup AM so that it works for their situation.  It's already very very flexible in many different scenarios, but that flexibility comes at a learning curve cost for the end user.

Would it be possible to add the Whattomine statistics to the Online Services tab?  If I'm reading your quote above correctly, AM will use both tabs for profit switching if I had selected the NH and custom pool profit, but it might be confusing to the user how AM uses those two tabs differently.  Or at the very least some labels on the tabs (Coins and Online Services) so that the user understands how those two sets of data are used by AM.

I have been getting requests about combining the tabs for Coins and Online services. From a profit presentation point of view, it makes sense to combine them, because that's exactly what the profit switcher is doing. If you have Signatum on top at $12 on the Coins tab and Nicehash X11 on top at $11 on the Online services tab, the profit switcher will go for Signatum - if you have that as a custom pool to the profit switcher. So from a profit number point of view, combining makes sense.

Then we have the other aspect, and that is what kind of information to present about individual coins and about pools like Nicehash. For coins you have much more data and exchange rates and so on, and also the option to edit the coin properties. Combining this together with something like Nicehash could look strange. I'm not saying that these two tabs will be separate for all future, just that there are both benefints and drawbacks with both solutions.

I think the fact that Nicehash and Zpool obscure the actual coin you are mining would be a challenge, as you mention.  But in the end, the user just wants to make sure his miner is mining the most profitable coin or algorithm.

[breich]

Another feature request: can we get a profit switching threshold?  Suppose I'm using the managed profit miner with a stats pull every 2 minutes, and profit switching every 5 minutes.  Let's say the current best algorithm is Equihash at $3/day.  At the next profit switching interval, Equihash is still at $3/day, but Groestl is at $3.10/day.  Personally, I don't want to profit switch over to Groestl, because the gain in return is not worth the 5-10 second downtime from profit switching.  However, if Groestl were at $4/day, then I'd want to profit switch.  So, if I were able to define my threshold at 25%, i.e. there needs to be at least a 25% difference in price for a swap, then I'd be able to avoid the switches that are -EV.  In our example, at a 25% threshold I wouldn't be profit switching unless Groestl/the current best algo were worth $3.75/day.

[rafaeldelrey]

AwesomeMiner have been reporting wrong numbers for profitability.  $760.4 per day, for a dual GTX 1070.  I am using version 3.2, which looks like the latest one.  When I try to download new miner, it says there are updates, but I need a newer version of AM.  Any tip for solving this?

[STSMiner]

AwesomeMiner have been reporting wrong numbers for profitability.  $760.4 per day, for a dual GTX 1070.  I am using version 3.2, which looks like the latest one.  When I try to download new miner, it says there are updates, but I need a newer version of AM.  Any tip for solving this?

Click these tabs...

Main > Options >  (New window opens}

Select the General option, you will see in the right side the options for

Software updates >> Tick all the boxes

Click OK to save.

Select Menu Tab

Check for updates let it install and restart.

Then check the update for mining definitions.

Close software down (big red X)

Restart software and mine.

[patrike]

The Accept progress rule is typically used to compare current Accepted share value with a previous one, to make sure it's increasing. If you set it to compare with a value 5 minutes ago, it will take at least 5 minutes before it can trigger, and then it will only trigger if Accepted share is identical (which indicates that the mining isn't progressing as it should). Is this the scenario you are using with your Accept rule or is it another case you want to take care of? Maybe you could send a screenshot of the properties of this Accept trigger so I get a complete understanding of it.

No, I'm comparing it to some specific value. Examples:

This one is NEVER triggered:

This one is sometimes triggered (same result if you choose "equals" instead of "less than or equals")

This one is almost always triggered:

Thanks - not I understand the scenario. There is a 60 second delay from when a miner interface is connected until the Check Statistics triggers can trigger. This was originally to prevent triggering on low hashrates because the mining didn't have a chance to get started.

The same delay applies to Accepted as well, which probably explain your scenarios where a very low Accepted value would happen within the first minute, and doesn't trigger, while when you set it to a higher value, it will trigger.

[Chapster]

Another feature request: can we get a profit switching threshold?  Suppose I'm using the managed profit miner with a stats pull every 2 minutes, and profit switching every 5 minutes.  Let's say the current best algorithm is Equihash at $3/day.  At the next profit switching interval, Equihash is still at $3/day, but Groestl is at $3.10/day.  Personally, I don't want to profit switch over to Groestl, because the gain in return is not worth the 5-10 second downtime from profit switching.  However, if Groestl were at $4/day, then I'd want to profit switch.  So, if I were able to define my threshold at 25%, i.e. there needs to be at least a 25% difference in price for a swap, then I'd be able to avoid the switches that are -EV.  In our example, at a 25% threshold I wouldn't be profit switching unless Groestl/the current best algo were worth $3.75/day.

I second this

[Chapster]

Thanks - not I understand the scenario. There is a 60 second delay from when a miner interface is connected until the Check Statistics triggers can trigger. This was originally to prevent triggering on low hashrates because the mining didn't have a chance to get started.

The same delay applies to Accepted as well, which probably explain your scenarios where a very low Accepted value would happen within the first minute, and doesn't trigger, while when you set it to a higher value, it will trigger.

Thanks for your reply.
Even so, I'm still having issues with a very different set of rules.
Most of the time this is triggered but it fails from time to time:


Like I said, I'm trying to get AM to invoke an external program to force Afterburner to switch profile.
Unfortunately, for some reason, sometimes AM fails to trigger those rules (I have a notification to keep track of when the rule is triggered, so I'm 100% sure that is not the external program which is failing).

[patrike]

Thanks - not I understand the scenario. There is a 60 second delay from when a miner interface is connected until the Check Statistics triggers can trigger. This was originally to prevent triggering on low hashrates because the mining didn't have a chance to get started.

The same delay applies to Accepted as well, which probably explain your scenarios where a very low Accepted value would happen within the first minute, and doesn't trigger, while when you set it to a higher value, it will trigger.

Thanks for your reply.
Even so, I'm still having issues with a very different set of rules.
Most of the time this is triggered but it fails from time to time:


Like I said, I'm trying to get AM to invoke an external program to force Afterburner to switch profile.
Unfortunately, for some reason, sometimes AM fails to trigger those rules (I have a notification to keep track of when the rule is triggered, so I'm 100% sure that is not the external program which is failing).

I've just made a small change to the "Detect miner API" rule, because it was a possible timing issue that could have been the reason for the problem you describe. I was however not able to reproduce the problem myself, so please try with the new version 3.2.9 and get back to me with your findings.