Bitcoin Forum
June 17, 2024, 02:08:42 AM *
News: Voting for pizza day contest
 
   Home   Help Search Login Register More  
Pages: « 1 ... 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 [263] 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 ... 647 »
  Print  
Author Topic: [Awesome Miner] - Powerful Windows GUI to manage and monitor up to 200000 miners  (Read 701413 times)
Dalba
Newbie
*
Offline Offline

Activity: 92
Merit: 0


View Profile
March 24, 2018, 06:52:23 PM
 #5241

Hello Patrike,

As you can see in the picture below, when you compare income, the best is not always the top revenue when you look at profit column (in this example lyra2z would be the most interesting).

https://i.imgur.com/9ws9wDi.jpg

For those like me who have precise power consumption in AM, could you add an option to switch mining using profit value instead of revenue value ?

 


FFS. Click on that label named "Profit"!

Shocked
I feel a little stupid...  

But if it works like this for online services, how do you do for coin tab ?
akadamson
Member
**
Offline Offline

Activity: 140
Merit: 18


View Profile
March 24, 2018, 07:47:19 PM
 #5242

Hello Patrike,

As you can see in the picture below, when you compare income, the best is not always the top revenue when you look at profit column (in this example lyra2z would be the most interesting).



For those like me who have precise power consumption in AM, could you add an option to switch mining using profit value instead of revenue value ?

 


FFS. Click on that label named "Profit"!

Shocked
I feel a little stupid...  

But if it works like this for online services, how do you do for coin tab ?

same way, click on the column heading it will sort big to little, click it again it will sort little to big, etc.
O-Coin
Jr. Member
*
Offline Offline

Activity: 61
Merit: 2


View Profile
March 24, 2018, 08:39:40 PM
 #5243

Raven Coin Calculate Profitability config.
Would this be accurate atleast for today?
Difficuly From Mining Software 13,020
Btc Value 0.00000325  From https://coinmarketcap.com/currencies/ravencoin/
Block Reward 5000

Shows about 30-32 per day on 8X1080ti


moppidoo
Jr. Member
*
Offline Offline

Activity: 348
Merit: 5


View Profile
March 24, 2018, 11:06:25 PM
 #5244

Raven Coin Calculate Profitability config.
Would this be accurate atleast for today?
Difficuly From Mining Software 13,020
Btc Value 0.00000325  From https://coinmarketcap.com/currencies/ravencoin/
Block Reward 5000

Shows about 30-32 per day on 8X1080ti




Use @Sootha's coin plugin is your best choice

https://bitcointalk.org/index.php?topic=2979494.0
O-Coin
Jr. Member
*
Offline Offline

Activity: 61
Merit: 2


View Profile
March 25, 2018, 02:13:08 AM
 #5245

Raven Coin Calculate Profitability config.
Would this be accurate atleast for today?
Difficuly From Mining Software 13,020
Btc Value 0.00000325  From https://coinmarketcap.com/currencies/ravencoin/
Block Reward 5000

Shows about 30-32 per day on 8X1080ti




Use @Sootha's coin plugin is your best choice

https://bitcointalk.org/index.php?topic=2979494.0

How is the setup/config on the plugin?  I like the idea of adding new coins and having them update realtime.
vtrsp1
Newbie
*
Offline Offline

Activity: 31
Merit: 0


View Profile
March 25, 2018, 07:34:29 AM
 #5246

hello patrike,

DTSM miner is not working in win 8.1 for me (EWBF is running fine) it starts up and shuts down.is the program not suporting win 8.1?


Make sure you installed the C++ 2015 redistributable.  It's required for DTSM.


oke thanks
patrike (OP)
Legendary
*
Offline Offline

Activity: 3346
Merit: 1094


View Profile WWW
March 25, 2018, 08:03:24 AM
 #5247

Hi Patrike,

my previous request probably been overlooked, could we add ability to batch update power consumption for profit profiles? (mining farm with old computers + mixture of cards means shuffling of hardware needed at times when old parts fail...pita when updating the power consumption one by one...) ... + when one forget to update due to hw change or added several new algos...things don't turn out too well with profit switching)

Cheers,
Just to make sure I understand the request - Is it batch update of power usage for all algorithms within a profile, or do you have multiple profiles where you want to change for example the Neoscrypt power usage for all selected profiles?

Awesome Miner - Complete solution to manage and monitor mining operations of ASIC, GPU and CPU miners
Optimized Antminer firmware - Increased hashrate, improved power efficiency and more features. For S9, S9i, S9j, T9+, L3+, S17, S17 Pro, S17+, T17, T17+, S19, S19 Pro, S19j, S19j Pro, T19
Up to 200,000 miners | Notifications | Native overclocking | Profit switching | Customizable rules | API | Windows application | Mobile web
patrike (OP)
Legendary
*
Offline Offline

Activity: 3346
Merit: 1094


View Profile WWW
March 25, 2018, 08:05:14 AM
 #5248

Thank you for the fix Patrike! - The Pool Change operation is made available with more mining software for a Managed Miner in the web interface

Hoping someone can point me in the right direction. I want the ability to switch to another pool/algo, which also requires switching the miner software. I've tried creating a pool group containing two different algo coins but this did not seem to work. If the managed miner is set to use Claymore for example, it tries using claymore even when choosing to change pool to a neoscript coin. I tried editing the managed software under options to a strict enable/disable for a miner for certain algo, but this did not seem to work either.
I think the feature Managed Templates can be of use here:
http://www.awesomeminer.com/help/managedtemplate.aspx

Awesome Miner - Complete solution to manage and monitor mining operations of ASIC, GPU and CPU miners
Optimized Antminer firmware - Increased hashrate, improved power efficiency and more features. For S9, S9i, S9j, T9+, L3+, S17, S17 Pro, S17+, T17, T17+, S19, S19 Pro, S19j, S19j Pro, T19
Up to 200,000 miners | Notifications | Native overclocking | Profit switching | Customizable rules | API | Windows application | Mobile web
patrike (OP)
Legendary
*
Offline Offline

Activity: 3346
Merit: 1094


View Profile WWW
March 25, 2018, 08:07:02 AM
 #5249

Is there documentation or tutorials for the custom scripting aspect?
For the C# scripting feature, please see:
http://www.awesomeminer.com/help/script.aspx

In many scenarios, it's more popular to use the Awesome Miner API and develop an external application instead:
http://www.awesomeminer.com/help/api.aspx

Awesome Miner - Complete solution to manage and monitor mining operations of ASIC, GPU and CPU miners
Optimized Antminer firmware - Increased hashrate, improved power efficiency and more features. For S9, S9i, S9j, T9+, L3+, S17, S17 Pro, S17+, T17, T17+, S19, S19 Pro, S19j, S19j Pro, T19
Up to 200,000 miners | Notifications | Native overclocking | Profit switching | Customizable rules | API | Windows application | Mobile web
eminer001
Newbie
*
Offline Offline

Activity: 140
Merit: 0


View Profile
March 25, 2018, 08:09:53 AM
 #5250

Patrike, there is a bug.

I noticed lately that online services are not updated as specified on "update interval" and online services table remains unchanged for more than half an hour sometimes when comparing AM with Nemos Miner statistics update at the same time.

I am thinking that because there are so many miners, most probably errors are returned from the pools with connection timeout. A very fast workaround would be to retry after 10 seconds a new pool statistics update and do not wait another update interval of a few minutes.

Waiting for the next update interval when again, it could be an error when one request is made might be too much and the miner could mine a very unprofitable coin that spiked for some minutes.

This might be also the problem that is causing Awesome Miner to be less profitable with current mining than 24h, against all logic. What I think it happens is that AM starts mining Tribus for example at $20/day/rig and after that profitability for tribus drops to $3/day/rig and because AM is not refreshing statistics, all rigs remain to mine at $3/day/rig even half an hour, and this leads to disastrous profitability if you use current statistics.

A solution might be introducing a very fast NodeJs socket based statistics on 2 separate servers(for fail safe) that will be used to send statistics to miners through the socket without any delay and that can handle easily 100,000 connections without noticeable cpu load. You will make on your server requests to pool API every 10 seconds, but you will avoid having Awesome Miner making  100,000 http requests to pool APIs that are overkill for all pools.

Like that you will reduce api load for pools by 10,000 times, by implementing this is a huge optimization for everyone.

What do you think, Patrike ?


Are you there ?
To check I used "view details" for the miner and seen that statistics are not being updated as supposed to. Most probably DDOS protection from datacenters denies the API requests to pools statistics because there or too many or simply all pool servers are overloaded by thousands of requests they receive every minute.

It is important to have a retry procedure at a few seconds after failed attempt for all failed or timeout errors from pools statistics until you implement a reliable socket based service.

Remember that pools refresh the statistics every 30 seconds and you can decrease the number of requests to pools from 500 per second (thousands of miners requesting HTTP pool statistics updates) to just one every 10 seconds and after that you can update all 100.000 miners next seconds using sockets. Like that you will decrease pool server load by at least 500 times.

I switched a few hundred rigs I have from Aweosome Miner to Nemos Miner 3.0 because it handles better statistics requests and also I have in Nemos 5 more miners that was not included in Awesome Miner (raven miner , poly, ...)  

What do you think, Patrike ?



Are you there, Patrike ?  

Statistics are not updating every X minutes, if one pool fails to return statistics, also all the other pools statistics are not updated, probably you have an error in the code.

Also I think it will be very useful to see on "VIEW DETAILS" what pool statistics was updated and when (because one pool might have failed statistics for half an hour and you can continue to mine Tribus for example at 10% of the amount you could mine X17 if you had statistics updated and not remained with outdated Tribus high statistics form half an hour ago), right ?
patrike (OP)
Legendary
*
Offline Offline

Activity: 3346
Merit: 1094


View Profile WWW
March 25, 2018, 08:22:07 AM
 #5251

Hi Patrike,

Another suggestion to add to the rules. Instead of implementing any complicated profit switching strategies, this one should be relatively easy since all information are seemly readily available but just not through the GUI and hard for us non-programmers to do through scripts.

Can we request a rule that reads the AM's statistics (globally or individual miners) on revenue and/or profit as reported in the Miners Tab in the main window (make both available and user can choose either per their preference) as a value and set a threshold such that if the Total revenue or profit is constantly below the threshold set by the user for certain time period (definable by user), then execute the "Profit Switching" action?

This way, even with long Profit switching interval, we'll be less likely be negatively affected by sudden spike in profit reporting.....and kind of spending a good portion of time actually mining unprofitably.
I agree that there should be a Trigger where you can trigger on a revenue/profit value.

In addition to re-trigger the profit switcher, it could also be used to stop a miner if the profit is too low, or start it again if the profit is getting higher. I've had a number of requests for these kind of behaviors, that could be solved with the same kind of profit-trigger.

Awesome Miner - Complete solution to manage and monitor mining operations of ASIC, GPU and CPU miners
Optimized Antminer firmware - Increased hashrate, improved power efficiency and more features. For S9, S9i, S9j, T9+, L3+, S17, S17 Pro, S17+, T17, T17+, S19, S19 Pro, S19j, S19j Pro, T19
Up to 200,000 miners | Notifications | Native overclocking | Profit switching | Customizable rules | API | Windows application | Mobile web
patrike (OP)
Legendary
*
Offline Offline

Activity: 3346
Merit: 1094


View Profile WWW
March 25, 2018, 08:24:44 AM
Last edit: March 25, 2018, 08:44:05 AM by patrike
 #5252

Hello,

how is it possible to add GPU fan speed and temp in Progress field like for Asics?

see pic:
I do understand your point here, but this isn't supported today.

Awesome Miner - Complete solution to manage and monitor mining operations of ASIC, GPU and CPU miners
Optimized Antminer firmware - Increased hashrate, improved power efficiency and more features. For S9, S9i, S9j, T9+, L3+, S17, S17 Pro, S17+, T17, T17+, S19, S19 Pro, S19j, S19j Pro, T19
Up to 200,000 miners | Notifications | Native overclocking | Profit switching | Customizable rules | API | Windows application | Mobile web
patrike (OP)
Legendary
*
Offline Offline

Activity: 3346
Merit: 1094


View Profile WWW
March 25, 2018, 08:28:19 AM
 #5253

Mining Dutch seems to be most profitable Pool for my Rigs (7).
However, Mining Dutch keeps failing for Not Producing any accepted shares within the config time.  I set this to 10min.

This is happeneng on all 5 workers that use the pool.

Any Suggestions ?


What hardware are you using? Mining Dutch uses different stratum ports for low - normal - high difficulty, using too low on highend hardware can cause massive rejection and ban from the pool. On the contrary, using low-end hardware on the higher difficulty ports can result in less accepted shares found given the same mining period.

Also, how often do you profit switch, AM seem to accumulate and not reset accept counter/timer when profit switching, so if you are mining high difficulty coins and didn't submit any shares for 5 min then AM did profit switching, and you were unlucky to find any shares for another 5 minutes after the switch, you will hit your 10min no shares accepted notification time I believe.

Im Using Nvidia Cards 8X1080Ti, 8X1080, 16X1070, 8X1070Ti.  Config in 5 8 card rigs.  I changed the port to the less difficult and that stopped the no shares issue but had opposite effect and started getting the miner misbehaving emails from Mining-Dutch LOL.  The emails had suggested Diff settings that are used in the password field.  You can also look at the diff= on the miningdutch worker page and then use that setting in the password field.  Seems mining dutch should have a better system but seems to be running for 12 + hours  without issue.  Seems mining dutch Neoscrypt usually most profitable for my Nvidia Cards.   
It's correct that Mining Dutch is a bit different compared to all the other predefined pools used by the profit switcher. They have different ports depending on what difficulty to use, and the port values can be manually changed in Awesome Miner via the Options dialog, Online Services section.

Although Mining Dutch may require some adjustments depending if it's used in a low-hashrate system or a high-hashrate system, the idea is that Awesome Miner includes this pool for the users that do prefer to use it.

Awesome Miner - Complete solution to manage and monitor mining operations of ASIC, GPU and CPU miners
Optimized Antminer firmware - Increased hashrate, improved power efficiency and more features. For S9, S9i, S9j, T9+, L3+, S17, S17 Pro, S17+, T17, T17+, S19, S19 Pro, S19j, S19j Pro, T19
Up to 200,000 miners | Notifications | Native overclocking | Profit switching | Customizable rules | API | Windows application | Mobile web
patrike (OP)
Legendary
*
Offline Offline

Activity: 3346
Merit: 1094


View Profile WWW
March 25, 2018, 08:43:34 AM
 #5254

patrike,

Found a little annoyance, first 6.0 bminer is out.

second, and the annoyance. if you define a custom version of software, tell it it's api and command compatible, and then define the path, when you start it the first time it doesn't take any specifically entered command line parameters that you may have entered. 

Third it doesn't show the pool name in the main display for the miner, in fact if it's using the built in version it does and if you select a user installed version and save that, it will drop the pool name and never show it again until you switch back to the built in version.
1) Bminer 6.0 will be included in the next release that soon will be made available.

2) I was trying to reproduce this without success. Was it in the Managed Software Properties you specified a command line argument for one of the algorithms - and then creating a Managed Miner, and once started the configured command line wasn't added?

3) I will do some additional testing of this. In general, if Awesome Miner has multiple pools matching a URL from the mining software, it will not display the name of the pool, only the URL.

Awesome Miner - Complete solution to manage and monitor mining operations of ASIC, GPU and CPU miners
Optimized Antminer firmware - Increased hashrate, improved power efficiency and more features. For S9, S9i, S9j, T9+, L3+, S17, S17 Pro, S17+, T17, T17+, S19, S19 Pro, S19j, S19j Pro, T19
Up to 200,000 miners | Notifications | Native overclocking | Profit switching | Customizable rules | API | Windows application | Mobile web
patrike (OP)
Legendary
*
Offline Offline

Activity: 3346
Merit: 1094


View Profile WWW
March 25, 2018, 08:48:13 AM
 #5255

Hi , can some on please explain  what is this?
 24.3.2018 г. 10:46:12.981 [024] Log of miner status[ManagedMiner#9 - RiG 1[/u][/b]]
  Type: Managed, EngineType: EthClayMiner, EngineSubType: Disabled, UseWorkerSuffix: True, WorkerSuffix: 1, ManagedProfitMiner: False
  Algorithm: Unspecified, LastStatusUpdate: 24.3.2018 г. 10:46:09, Enabled: True, InterfaceDisconnectedTimeUtc: 31.12.9999 г. 23:59:59
  State: Executing, ApiState: Connected, PendingCommand: False, MarkedForRemoval: False
  IsProfitMiner: False, IsManualStop: False, Autostart: True, Engine Type: EthClayMiner, Auto Download: False, EnginePath: C:\Users\Admin\AppData\Roaming\AwesomeMinerService\EthDcrMiner64_1\Claymore's Dual Ethereum+Decred_Siacoin_Lbry_Pascal AMD+NVIDIA GPU Miner v11.0\EthDcrMiner64.exe, Subtype: Disabled, CustomExecutable:
[ManagedMiner#10 - RiG 2]
[E]Failed to download string from: http://www.d3pool.eu/api/status
 System.Net.WebException: The remote server returned an error: (503) Server Unavailable.
 Type: External, EngineType: ZecEwbfMiner, EngineSubType: Disabled, UseWorkerSuffix: False, WorkerSuffix: , ManagedProfitMiner: False
  Algorithm: Equihash, LastStatusUpdate: 24.3.2018 г. 10:16:12, Enabled: True, InterfaceDisconnectedTimeUtc: 31.12.9999 г. 23:59:59
  State: ManualStopped, ApiState: Connected, PendingCommand: False, MarkedForRemoval: False

Current list of Managed Miners:
[ManagedMiner#14 - RiG 3]
why it's so many miners there? on my machine is only 8. What is this ManagedMiner #10 ?  What is this - False ?
and why i have this error all the time  - Accepted' has not increased in 8 minutes, rig is working but have this notification .
thank you
The naming #10 is just an internal ID number. It doesn't indicate that you have 10 miners in total, because you may not have any miner with ID 3 and 7 for example. This is simply a log entry with information about the miner, indicating True/False (= Yes/No ) for a number of properties.

You have enabled the rule Accept Progress (Options dialog, Rules section). When enabled, you will get a notification if your miners doesn't produce any shares that are accepted by the pool within 8 minutes. This could be an indication that even if your miners are hashing, they doesn't produce anything that is being accepted by the pool. If you have slow miners, this can happen without anything is wrong as it simply takes a while before you get any accepted work. If you have powerful miners and they don't produce any accepted shares, it's more likely that either the GPU's or the pool isn't doing what it should.

Awesome Miner - Complete solution to manage and monitor mining operations of ASIC, GPU and CPU miners
Optimized Antminer firmware - Increased hashrate, improved power efficiency and more features. For S9, S9i, S9j, T9+, L3+, S17, S17 Pro, S17+, T17, T17+, S19, S19 Pro, S19j, S19j Pro, T19
Up to 200,000 miners | Notifications | Native overclocking | Profit switching | Customizable rules | API | Windows application | Mobile web
patrike (OP)
Legendary
*
Offline Offline

Activity: 3346
Merit: 1094


View Profile WWW
March 25, 2018, 09:02:00 AM
 #5256

Patrike, there is a bug.

I noticed lately that online services are not updated as specified on "update interval" and online services table remains unchanged for more than half an hour sometimes when comparing AM with Nemos Miner statistics update at the same time.

I am thinking that because there are so many miners, most probably errors are returned from the pools with connection timeout. A very fast workaround would be to retry after 10 seconds a new pool statistics update and do not wait another update interval of a few minutes.

Waiting for the next update interval when again, it could be an error when one request is made might be too much and the miner could mine a very unprofitable coin that spiked for some minutes.

This might be also the problem that is causing Awesome Miner to be less profitable with current mining than 24h, against all logic. What I think it happens is that AM starts mining Tribus for example at $20/day/rig and after that profitability for tribus drops to $3/day/rig and because AM is not refreshing statistics, all rigs remain to mine at $3/day/rig even half an hour, and this leads to disastrous profitability if you use current statistics.

A solution might be introducing a very fast NodeJs socket based statistics on 2 separate servers(for fail safe) that will be used to send statistics to miners through the socket without any delay and that can handle easily 100,000 connections without noticeable cpu load. You will make on your server requests to pool API every 10 seconds, but you will avoid having Awesome Miner making  100,000 http requests to pool APIs that are overkill for all pools.

Like that you will reduce api load for pools by 10,000 times, by implementing this is a huge optimization for everyone.

What do you think, Patrike ?


Are you there ?
To check I used "view details" for the miner and seen that statistics are not being updated as supposed to. Most probably DDOS protection from datacenters denies the API requests to pools statistics because there or too many or simply all pool servers are overloaded by thousands of requests they receive every minute.

It is important to have a retry procedure at a few seconds after failed attempt for all failed or timeout errors from pools statistics until you implement a reliable socket based service.

Remember that pools refresh the statistics every 30 seconds and you can decrease the number of requests to pools from 500 per second (thousands of miners requesting HTTP pool statistics updates) to just one every 10 seconds and after that you can update all 100.000 miners next seconds using sockets. Like that you will decrease pool server load by at least 500 times.

I switched a few hundred rigs I have from Aweosome Miner to Nemos Miner 3.0 because it handles better statistics requests and also I have in Nemos 5 more miners that was not included in Awesome Miner (raven miner , poly, ...)  

What do you think, Patrike ?



Are you there, Patrike ?  

Statistics are not updating every X minutes, if one pool fails to return statistics, also all the other pools statistics are not updated, probably you have an error in the code.

Also I think it will be very useful to see on "VIEW DETAILS" what pool statistics was updated and when (because one pool might have failed statistics for half an hour and you can continue to mine Tribus for example at 10% of the amount you could mine X17 if you had statistics updated and not remained with outdated Tribus high statistics form half an hour ago), right ?

Awesome Miner will refresh the pool profitability information before each profit switching. If your profit switching interval is 2 minutes for example, Awesome Miner will connect to Nicehash, zpool and all the other every 2 minutes.

As you also point out, it's not that uncommon that some of these pools are down (at least from an API point of view) some period of times. Awesome Miner will of course fail to update the profit information during that period of time. However, as soon as the pool is responding to the API requests again, Awesome Miner will get the refreshed profit information before the next profit switching check is going to happen. It's generally not a good idea to try again within just a few seconds, because then you just put even more load on the poor server that is trying to recover.

Awesome Miner is also more friendly to the pool API's than some other software. When you have a many miners with Awesome Miner, it's only the main application that request the information from the pools - not each miner. With some other mining software where you don't have any centralized management, I assume each computer doing mining will put load on the pool API's.

If a single pool like zpool is down, it should not affect the statistics updates for all the others as these requests are allowed to fail individually. Based on your report here, I will however do some investigation here to see if there can be any scenario where it isn't working as expected. If you have found any specific way of reproducing it, please let me know. Thanks!

I do like your point about being able to see when the last updates was made. As these are global updates for the pools it should probably not go into the View Details of each miner, but in some application wide "Service Status". It would also be good so see if for example the WhatToMine API is unavailable in a similar way. Also, today you can see if Awesome Miner mark any pool as "Failed" in the View Details dialog. In the same global "Service Status" dialog, it would be good to see a summary of this. Then you can simply open this dialog and get a good understanding of if a few specific Nicehash pools are down, or the Zpool API hasn't been updated for 4 hours and so on.

Awesome Miner - Complete solution to manage and monitor mining operations of ASIC, GPU and CPU miners
Optimized Antminer firmware - Increased hashrate, improved power efficiency and more features. For S9, S9i, S9j, T9+, L3+, S17, S17 Pro, S17+, T17, T17+, S19, S19 Pro, S19j, S19j Pro, T19
Up to 200,000 miners | Notifications | Native overclocking | Profit switching | Customizable rules | API | Windows application | Mobile web
eminer001
Newbie
*
Offline Offline

Activity: 140
Merit: 0


View Profile
March 25, 2018, 09:23:01 AM
 #5257

Patrike, there is a bug.

I noticed lately that online services are not updated as specified on "update interval" and online services table remains unchanged for more than half an hour sometimes when comparing AM with Nemos Miner statistics update at the same time.

I am thinking that because there are so many miners, most probably errors are returned from the pools with connection timeout. A very fast workaround would be to retry after 10 seconds a new pool statistics update and do not wait another update interval of a few minutes.

Waiting for the next update interval when again, it could be an error when one request is made might be too much and the miner could mine a very unprofitable coin that spiked for some minutes.

This might be also the problem that is causing Awesome Miner to be less profitable with current mining than 24h, against all logic. What I think it happens is that AM starts mining Tribus for example at $20/day/rig and after that profitability for tribus drops to $3/day/rig and because AM is not refreshing statistics, all rigs remain to mine at $3/day/rig even half an hour, and this leads to disastrous profitability if you use current statistics.

A solution might be introducing a very fast NodeJs socket based statistics on 2 separate servers(for fail safe) that will be used to send statistics to miners through the socket without any delay and that can handle easily 100,000 connections without noticeable cpu load. You will make on your server requests to pool API every 10 seconds, but you will avoid having Awesome Miner making  100,000 http requests to pool APIs that are overkill for all pools.

Like that you will reduce api load for pools by 10,000 times, by implementing this is a huge optimization for everyone.

What do you think, Patrike ?


Are you there ?
To check I used "view details" for the miner and seen that statistics are not being updated as supposed to. Most probably DDOS protection from datacenters denies the API requests to pools statistics because there or too many or simply all pool servers are overloaded by thousands of requests they receive every minute.

It is important to have a retry procedure at a few seconds after failed attempt for all failed or timeout errors from pools statistics until you implement a reliable socket based service.

Remember that pools refresh the statistics every 30 seconds and you can decrease the number of requests to pools from 500 per second (thousands of miners requesting HTTP pool statistics updates) to just one every 10 seconds and after that you can update all 100.000 miners next seconds using sockets. Like that you will decrease pool server load by at least 500 times.

I switched a few hundred rigs I have from Aweosome Miner to Nemos Miner 3.0 because it handles better statistics requests and also I have in Nemos 5 more miners that was not included in Awesome Miner (raven miner , poly, ...)  

What do you think, Patrike ?



Are you there, Patrike ?  

Statistics are not updating every X minutes, if one pool fails to return statistics, also all the other pools statistics are not updated, probably you have an error in the code.

Also I think it will be very useful to see on "VIEW DETAILS" what pool statistics was updated and when (because one pool might have failed statistics for half an hour and you can continue to mine Tribus for example at 10% of the amount you could mine X17 if you had statistics updated and not remained with outdated Tribus high statistics form half an hour ago), right ?

Awesome Miner will refresh the pool profitability information before each profit switching. If your profit switching interval is 2 minutes for example, Awesome Miner will connect to Nicehash, zpool and all the other every 2 minutes.

As you also point out, it's not that uncommon that some of these pools are down (at least from an API point of view) some period of times. Awesome Miner will of course fail to update the profit information during that period of time. However, as soon as the pool is responding to the API requests again, Awesome Miner will get the refreshed profit information before the next profit switching check is going to happen. It's generally not a good idea to try again within just a few seconds, because then you just put even more load on the poor server that is trying to recover.

Awesome Miner is also more friendly to the pool API's than some other software. When you have a many miners with Awesome Miner, it's only the main application that request the information from the pools - not each miner. With some other mining software where you don't have any centralized management, I assume each computer doing mining will put load on the pool API's.

If a single pool like zpool is down, it should not affect the statistics updates for all the others as these requests are allowed to fail individually. Based on your report here, I will however do some investigation here to see if there can be any scenario where it isn't working as expected. If you have found any specific way of reproducing it, please let me know. Thanks!

I do like your point about being able to see when the last updates was made. As these are global updates for the pools it should probably not go into the View Details of each miner, but in some application wide "Service Status". It would also be good so see if for example the WhatToMine API is unavailable in a similar way. Also, today you can see if Awesome Miner mark any pool as "Failed" in the View Details dialog. In the same global "Service Status" dialog, it would be good to see a summary of this. Then you can simply open this dialog and get a good understanding of if a few specific Nicehash pools are down, or the Zpool API hasn't been updated for 4 hours and so on.

Thanks for the answer. Don't you think that a websocket type solution as I described above will help? With that you can do without any issues one single request every 5 or 10 seconds and after that send the response to all AM users and  you can free a lot the load on pool API requests. Also you will have past hours information about pools that miners do not have when initially connecting that will be useful also.

From my point of view additional delay after current pool statistics is refreshed (current pool statistics is refreshed every 30 seconds) will only make AM's performance lack behind Nemos miner or other software that can switch my miners faster than AM after pool statistics informed me that Tribus profitability just decreased 10 times and AM keeps me mining on Tribus for another 2 or more minutes (until statistics will work) instead of a few seconds how NemosMiner does now. 

Do you agree ?
ruplikminer
Jr. Member
*
Offline Offline

Activity: 504
Merit: 3


View Profile
March 25, 2018, 10:19:02 AM
 #5258

Hi Patrik,

not sure if it's an already known bug or not. But when I add coins based on QUARK the profit calculation is completely wrong. It's WAY higher than the real one. I tried with different ones and always the same problem.
patrike (OP)
Legendary
*
Offline Offline

Activity: 3346
Merit: 1094


View Profile WWW
March 25, 2018, 11:29:12 AM
 #5259

Patrike, there is a bug.

I noticed lately that online services are not updated as specified on "update interval" and online services table remains unchanged for more than half an hour sometimes when comparing AM with Nemos Miner statistics update at the same time.

I am thinking that because there are so many miners, most probably errors are returned from the pools with connection timeout. A very fast workaround would be to retry after 10 seconds a new pool statistics update and do not wait another update interval of a few minutes.

Waiting for the next update interval when again, it could be an error when one request is made might be too much and the miner could mine a very unprofitable coin that spiked for some minutes.

This might be also the problem that is causing Awesome Miner to be less profitable with current mining than 24h, against all logic. What I think it happens is that AM starts mining Tribus for example at $20/day/rig and after that profitability for tribus drops to $3/day/rig and because AM is not refreshing statistics, all rigs remain to mine at $3/day/rig even half an hour, and this leads to disastrous profitability if you use current statistics.

A solution might be introducing a very fast NodeJs socket based statistics on 2 separate servers(for fail safe) that will be used to send statistics to miners through the socket without any delay and that can handle easily 100,000 connections without noticeable cpu load. You will make on your server requests to pool API every 10 seconds, but you will avoid having Awesome Miner making  100,000 http requests to pool APIs that are overkill for all pools.

Like that you will reduce api load for pools by 10,000 times, by implementing this is a huge optimization for everyone.

What do you think, Patrike ?


Are you there ?
To check I used "view details" for the miner and seen that statistics are not being updated as supposed to. Most probably DDOS protection from datacenters denies the API requests to pools statistics because there or too many or simply all pool servers are overloaded by thousands of requests they receive every minute.

It is important to have a retry procedure at a few seconds after failed attempt for all failed or timeout errors from pools statistics until you implement a reliable socket based service.

Remember that pools refresh the statistics every 30 seconds and you can decrease the number of requests to pools from 500 per second (thousands of miners requesting HTTP pool statistics updates) to just one every 10 seconds and after that you can update all 100.000 miners next seconds using sockets. Like that you will decrease pool server load by at least 500 times.

I switched a few hundred rigs I have from Aweosome Miner to Nemos Miner 3.0 because it handles better statistics requests and also I have in Nemos 5 more miners that was not included in Awesome Miner (raven miner , poly, ...)  

What do you think, Patrike ?



Are you there, Patrike ?  

Statistics are not updating every X minutes, if one pool fails to return statistics, also all the other pools statistics are not updated, probably you have an error in the code.

Also I think it will be very useful to see on "VIEW DETAILS" what pool statistics was updated and when (because one pool might have failed statistics for half an hour and you can continue to mine Tribus for example at 10% of the amount you could mine X17 if you had statistics updated and not remained with outdated Tribus high statistics form half an hour ago), right ?

Awesome Miner will refresh the pool profitability information before each profit switching. If your profit switching interval is 2 minutes for example, Awesome Miner will connect to Nicehash, zpool and all the other every 2 minutes.

As you also point out, it's not that uncommon that some of these pools are down (at least from an API point of view) some period of times. Awesome Miner will of course fail to update the profit information during that period of time. However, as soon as the pool is responding to the API requests again, Awesome Miner will get the refreshed profit information before the next profit switching check is going to happen. It's generally not a good idea to try again within just a few seconds, because then you just put even more load on the poor server that is trying to recover.

Awesome Miner is also more friendly to the pool API's than some other software. When you have a many miners with Awesome Miner, it's only the main application that request the information from the pools - not each miner. With some other mining software where you don't have any centralized management, I assume each computer doing mining will put load on the pool API's.

If a single pool like zpool is down, it should not affect the statistics updates for all the others as these requests are allowed to fail individually. Based on your report here, I will however do some investigation here to see if there can be any scenario where it isn't working as expected. If you have found any specific way of reproducing it, please let me know. Thanks!

I do like your point about being able to see when the last updates was made. As these are global updates for the pools it should probably not go into the View Details of each miner, but in some application wide "Service Status". It would also be good so see if for example the WhatToMine API is unavailable in a similar way. Also, today you can see if Awesome Miner mark any pool as "Failed" in the View Details dialog. In the same global "Service Status" dialog, it would be good to see a summary of this. Then you can simply open this dialog and get a good understanding of if a few specific Nicehash pools are down, or the Zpool API hasn't been updated for 4 hours and so on.

Thanks for the answer. Don't you think that a websocket type solution as I described above will help? With that you can do without any issues one single request every 5 or 10 seconds and after that send the response to all AM users and  you can free a lot the load on pool API requests. Also you will have past hours information about pools that miners do not have when initially connecting that will be useful also.

From my point of view additional delay after current pool statistics is refreshed (current pool statistics is refreshed every 30 seconds) will only make AM's performance lack behind Nemos miner or other software that can switch my miners faster than AM after pool statistics informed me that Tribus profitability just decreased 10 times and AM keeps me mining on Tribus for another 2 or more minutes (until statistics will work) instead of a few seconds how NemosMiner does now. 

Do you agree ?
You are correct that websockets could reduce the load as it doesn't require the same frequent polling for new information. However, I don't think any of these pools provides any websocket interfaces today. It's only standard HTTP as far as I know.

Today the minimum profit switching interval is 60 seconds in Awesome Miner, as the profit switching interval can only be set in number of miners. I have received feedback a few times in the past about being able to define the profit switching interval in seconds as well. By allowing the user to specify 30 seconds (that's very frequent), you would also be able to get faster updates from the pools. However, I think it's a quite small gain in updating every 30 seconds compared to 60 seconds - but the best is of course to leave that decision to the user of the software.

Awesome Miner - Complete solution to manage and monitor mining operations of ASIC, GPU and CPU miners
Optimized Antminer firmware - Increased hashrate, improved power efficiency and more features. For S9, S9i, S9j, T9+, L3+, S17, S17 Pro, S17+, T17, T17+, S19, S19 Pro, S19j, S19j Pro, T19
Up to 200,000 miners | Notifications | Native overclocking | Profit switching | Customizable rules | API | Windows application | Mobile web
eminer001
Newbie
*
Offline Offline

Activity: 140
Merit: 0


View Profile
March 25, 2018, 12:17:45 PM
 #5260

Patrike, there is a bug.

I noticed lately that online services are not updated as specified on "update interval" and online services table remains unchanged for more than half an hour sometimes when comparing AM with Nemos Miner statistics update at the same time.

I am thinking that because there are so many miners, most probably errors are returned from the pools with connection timeout. A very fast workaround would be to retry after 10 seconds a new pool statistics update and do not wait another update interval of a few minutes.

Waiting for the next update interval when again, it could be an error when one request is made might be too much and the miner could mine a very unprofitable coin that spiked for some minutes.

This might be also the problem that is causing Awesome Miner to be less profitable with current mining than 24h, against all logic. What I think it happens is that AM starts mining Tribus for example at $20/day/rig and after that profitability for tribus drops to $3/day/rig and because AM is not refreshing statistics, all rigs remain to mine at $3/day/rig even half an hour, and this leads to disastrous profitability if you use current statistics.

A solution might be introducing a very fast NodeJs socket based statistics on 2 separate servers(for fail safe) that will be used to send statistics to miners through the socket without any delay and that can handle easily 100,000 connections without noticeable cpu load. You will make on your server requests to pool API every 10 seconds, but you will avoid having Awesome Miner making  100,000 http requests to pool APIs that are overkill for all pools.

Like that you will reduce api load for pools by 10,000 times, by implementing this is a huge optimization for everyone.

What do you think, Patrike ?


Are you there ?
To check I used "view details" for the miner and seen that statistics are not being updated as supposed to. Most probably DDOS protection from datacenters denies the API requests to pools statistics because there or too many or simply all pool servers are overloaded by thousands of requests they receive every minute.

It is important to have a retry procedure at a few seconds after failed attempt for all failed or timeout errors from pools statistics until you implement a reliable socket based service.

Remember that pools refresh the statistics every 30 seconds and you can decrease the number of requests to pools from 500 per second (thousands of miners requesting HTTP pool statistics updates) to just one every 10 seconds and after that you can update all 100.000 miners next seconds using sockets. Like that you will decrease pool server load by at least 500 times.

I switched a few hundred rigs I have from Aweosome Miner to Nemos Miner 3.0 because it handles better statistics requests and also I have in Nemos 5 more miners that was not included in Awesome Miner (raven miner , poly, ...)  

What do you think, Patrike ?



Are you there, Patrike ?  

Statistics are not updating every X minutes, if one pool fails to return statistics, also all the other pools statistics are not updated, probably you have an error in the code.

Also I think it will be very useful to see on "VIEW DETAILS" what pool statistics was updated and when (because one pool might have failed statistics for half an hour and you can continue to mine Tribus for example at 10% of the amount you could mine X17 if you had statistics updated and not remained with outdated Tribus high statistics form half an hour ago), right ?

Awesome Miner will refresh the pool profitability information before each profit switching. If your profit switching interval is 2 minutes for example, Awesome Miner will connect to Nicehash, zpool and all the other every 2 minutes.

As you also point out, it's not that uncommon that some of these pools are down (at least from an API point of view) some period of times. Awesome Miner will of course fail to update the profit information during that period of time. However, as soon as the pool is responding to the API requests again, Awesome Miner will get the refreshed profit information before the next profit switching check is going to happen. It's generally not a good idea to try again within just a few seconds, because then you just put even more load on the poor server that is trying to recover.

Awesome Miner is also more friendly to the pool API's than some other software. When you have a many miners with Awesome Miner, it's only the main application that request the information from the pools - not each miner. With some other mining software where you don't have any centralized management, I assume each computer doing mining will put load on the pool API's.

If a single pool like zpool is down, it should not affect the statistics updates for all the others as these requests are allowed to fail individually. Based on your report here, I will however do some investigation here to see if there can be any scenario where it isn't working as expected. If you have found any specific way of reproducing it, please let me know. Thanks!

I do like your point about being able to see when the last updates was made. As these are global updates for the pools it should probably not go into the View Details of each miner, but in some application wide "Service Status". It would also be good so see if for example the WhatToMine API is unavailable in a similar way. Also, today you can see if Awesome Miner mark any pool as "Failed" in the View Details dialog. In the same global "Service Status" dialog, it would be good to see a summary of this. Then you can simply open this dialog and get a good understanding of if a few specific Nicehash pools are down, or the Zpool API hasn't been updated for 4 hours and so on.

Thanks for the answer. Don't you think that a websocket type solution as I described above will help? With that you can do without any issues one single request every 5 or 10 seconds and after that send the response to all AM users and  you can free a lot the load on pool API requests. Also you will have past hours information about pools that miners do not have when initially connecting that will be useful also.

From my point of view additional delay after current pool statistics is refreshed (current pool statistics is refreshed every 30 seconds) will only make AM's performance lack behind Nemos miner or other software that can switch my miners faster than AM after pool statistics informed me that Tribus profitability just decreased 10 times and AM keeps me mining on Tribus for another 2 or more minutes (until statistics will work) instead of a few seconds how NemosMiner does now. 

Do you agree ?
You are correct that websockets could reduce the load as it doesn't require the same frequent polling for new information. However, I don't think any of these pools provides any websocket interfaces today. It's only standard HTTP as far as I know.

Today the minimum profit switching interval is 60 seconds in Awesome Miner, as the profit switching interval can only be set in number of miners. I have received feedback a few times in the past about being able to define the profit switching interval in seconds as well. By allowing the user to specify 30 seconds (that's very frequent), you would also be able to get faster updates from the pools. However, I think it's a quite small gain in updating every 30 seconds compared to 60 seconds - but the best is of course to leave that decision to the user of the software.

The minimum value is 2 minutes. I can not set 1 minute. Can you check ? We need at least 1 minute to avoid mining on unprofitable algo that is volatile (tribus, skunk, timetravel).
Pages: « 1 ... 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 [263] 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 ... 647 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!