Bitcoin Forum
May 27, 2024, 08:41:15 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 212 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 ... 647 »
  Print  
Author Topic: [Awesome Miner] - Powerful Windows GUI to manage and monitor up to 200000 miners  (Read 701302 times)
moppidoo
Jr. Member
*
Offline Offline

Activity: 348
Merit: 5


View Profile
March 22, 2018, 02:17:53 AM
 #5221

Anyone know if I can change the Revenue per month and per day to display in BTC. I don't care about fiat would rather know what's the BTC estimate.


Thanks.

Options -> Coins & Profit -> Display Currency
Set to BTC
eminer001
Newbie
*
Offline Offline

Activity: 140
Merit: 0


View Profile
March 22, 2018, 08:06:01 AM
Last edit: March 22, 2018, 04:59:32 PM by eminer001
 #5222

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 ?


rsup
Newbie
*
Offline Offline

Activity: 29
Merit: 0


View Profile
March 22, 2018, 07:16:43 PM
 #5223

Is there documentation or tutorials for the custom scripting aspect?
O-Coin
Jr. Member
*
Offline Offline

Activity: 61
Merit: 2


View Profile
March 22, 2018, 07:27:04 PM
 #5224

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 ?
eminer001
Newbie
*
Offline Offline

Activity: 140
Merit: 0


View Profile
March 22, 2018, 07:51:53 PM
 #5225

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 ?


The only solution is to have every day test miners (with a single gpu each - you get the same results if you use 12 gpus for each) all pools with different wallets for each pool. The wallet for the pool with the best BTC payment performance will be used for the rest of the rigs.

Any other statistic that is either current, 24h estimate or 24h actual has no relevance when you compare with this method.  Pool administrators must respond in minutes to forks or issues and the pools that are failing to do this have bad BTC payments when you compare with statistics that made that pool be in the top of estimates when mining.

Pool fee has zero relevance also, because besides visible fee, there is another parameter that is called EXCHANGE_FEE and some pools have high values for it (it is 6% and 10% for others, and some might have it at 0%, you can not know, you must see real payments).

I hope everyone use this method because it's the best. To use it, you just have to select just one GPU, because if you use 1 gpu or 12 gpus for this test, the difference between pools is exactly the same.

With this method you do not waste your money and with 6 gpus you can test 3 pools with both current and 24h estimates.

This method is also bulletproof to  any trick pools might use like: inflating estimates, editing the code (you only have to edit one line of code and pools can steal 10% from all your income) , changing database values, and many others.

I also suggest to Patrike to implement a variation of this solution besides others he has in mind,  because pools are not fair, and real payments are the only fair part you can check and evaluate pools.

Let me know if you find better solutions.
wr9966
Newbie
*
Offline Offline

Activity: 2
Merit: 0


View Profile
March 22, 2018, 10:33:46 PM
 #5226

Greetings, I've tried reading the AM help pages and doing a key word search here, but I still cannot seem to find an answer.

I have a 6 GPU rig (AMD x2 & NVidia x4) that I have up and running on AM.  I have a second 6 GPU rig (NVidia x6) that I have up and running AM.  The split rig is running two instances of managed profit manager, one for the AMD cards and another for the NVidia card.  When mining by itself, it runs fine.  The second right is running one instance of AM.

I have purchased the PRO addition, as I have a couple of other miners I want to get setup as well, and I want to use the networking function to run the miners from one instance of AM on my main rig.

My quandry is that when I try to do setup a "new miner" using network scan for the split rig, AM only seems to see one of the instances on the split rig, not both.  I can select either NVidia or AMD, but I cannot seem to find a way to select both while using managed profit manager on the split rig.

I hope that makes sense. 

Is there a way to use the networking function so that the main instance of AM sees both remote instances on a split rig?
Dalba
Newbie
*
Offline Offline

Activity: 92
Merit: 0


View Profile
March 22, 2018, 11:12:04 PM
 #5227

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 ?


The only solution is to have every day test miners (with a single gpu each - you get the same results if you use 12 gpus for each) all pools with different wallets for each pool. The wallet for the pool with the best BTC payment performance will be used for the rest of the rigs.

Any other statistic that is either current, 24h estimate or 24h actual has no relevance when you compare with this method.  Pool administrators must respond in minutes to forks or issues and the pools that are failing to do this have bad BTC payments when you compare with statistics that made that pool be in the top of estimates when mining.

Pool fee has zero relevance also, because besides visible fee, there is another parameter that is called EXCHANGE_FEE and some pools have high values for it (it is 6% and 10% for others, and some might have it at 0%, you can not know, you must see real payments).

I hope everyone use this method because it's the best. To use it, you just have to select just one GPU, because if you use 1 gpu or 12 gpus for this test, the difference between pools is exactly the same.

With this method you do not waste your money and with 6 gpus you can test 3 pools with both current and 24h estimates.

This method is also bulletproof to  any trick pools might use like: inflating estimates, editing the code (you only have to edit one line of code and pools can steal 10% from all your income) , changing database values, and many others.

I also suggest to Patrike to implement a variation of this solution besides others he has in mind,  because pools are not fair, and real payments are the only fair part you can check and evaluate pools.

Let me know if you find better solutions.

I guess you have made your own tests. So what is the most efficient pool for you between those predefined in online services in Awesome Miner ?
moppidoo
Jr. Member
*
Offline Offline

Activity: 348
Merit: 5


View Profile
March 22, 2018, 11:16:10 PM
 #5228

Greetings, I've tried reading the AM help pages and doing a key word search here, but I still cannot seem to find an answer.

I have a 6 GPU rig (AMD x2 & NVidia x4) that I have up and running on AM.  I have a second 6 GPU rig (NVidia x6) that I have up and running AM.  The split rig is running two instances of managed profit manager, one for the AMD cards and another for the NVidia card.  When mining by itself, it runs fine.  The second right is running one instance of AM.

I have purchased the PRO addition, as I have a couple of other miners I want to get setup as well, and I want to use the networking function to run the miners from one instance of AM on my main rig.

My quandry is that when I try to do setup a "new miner" using network scan for the split rig, AM only seems to see one of the instances on the split rig, not both.  I can select either NVidia or AMD, but I cannot seem to find a way to select both while using managed profit manager on the split rig.

I hope that makes sense. 

Is there a way to use the networking function so that the main instance of AM sees both remote instances on a split rig?

Hi, Firstly you are running the remote split rig via AM Remote Service correct?

if that's the case, you don't need to run separate instance of the Remote Service, as AM will interact with just the single instance of the remote service, what you need is to create 2 separate profit profiles (one for AMD, one for Nvidia)

In the profit Profiles you've created, go to each enabled mining software and configure them with commandline options that are specific to the mining software to specify the enabled cards (you'll need to find out the device index of the cards yourself) by using the -d or -di directive for say, ccminer and claymore respectively, do the same for sgminer, your choice of equihash, cryptonight....etc. and benchmark them once you got that setup and verified working.
eminer001
Newbie
*
Offline Offline

Activity: 140
Merit: 0


View Profile
March 23, 2018, 06:27:48 AM
 #5229

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 ?


The only solution is to have every day test miners (with a single gpu each - you get the same results if you use 12 gpus for each) all pools with different wallets for each pool. The wallet for the pool with the best BTC payment performance will be used for the rest of the rigs.

Any other statistic that is either current, 24h estimate or 24h actual has no relevance when you compare with this method.  Pool administrators must respond in minutes to forks or issues and the pools that are failing to do this have bad BTC payments when you compare with statistics that made that pool be in the top of estimates when mining.

Pool fee has zero relevance also, because besides visible fee, there is another parameter that is called EXCHANGE_FEE and some pools have high values for it (it is 6% and 10% for others, and some might have it at 0%, you can not know, you must see real payments).

I hope everyone use this method because it's the best. To use it, you just have to select just one GPU, because if you use 1 gpu or 12 gpus for this test, the difference between pools is exactly the same.

With this method you do not waste your money and with 6 gpus you can test 3 pools with both current and 24h estimates.

This method is also bulletproof to  any trick pools might use like: inflating estimates, editing the code (you only have to edit one line of code and pools can steal 10% from all your income) , changing database values, and many others.

I also suggest to Patrike to implement a variation of this solution besides others he has in mind,  because pools are not fair, and real payments are the only fair part you can check and evaluate pools.

Let me know if you find better solutions.

I guess you have made your own tests. So what is the most efficient pool for you between those predefined in online services in Awesome Miner ?

The pool that has the best real BTC payments today will not be the best one tomorrow and the only solution is that everybody that invested his own money and has more than 10 or 20 gpus should have at least 3 gpus testing the pools with separate wallets all the time and simply disable pools that have the lowest profitability. You should only trust the real payment values, never the estimates. 

Not doing so you are loosing large amounts of your money that you paid to purchase the hardware and do not forget that you also pay for electricity, not the pool administrator that should only take care about having the best profitability for his pool
.
moppidoo
Jr. Member
*
Offline Offline

Activity: 348
Merit: 5


View Profile
March 23, 2018, 08:59:23 AM
 #5230

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.



Example is SIB and quite some amount of neoscrypt coins, the difficulty can go up and down to a few hundreds to thousands rather quickly meaning a good portion of the time per day (I would say at least 2 hours @ 5min switching interval...set this low because of the high fluctuating difficulty scenario) actually generating only a fraction of the peak revenue rate.

While the above scenario is certainly much pronounced when using "Current" setting in Statistics, it is still frequent even using 24Hour settings (both actual and Estimate), one example is DGB-Skein...it can still spike since pool stats via Online Services take precedence over WhatToMine API and cause unwanted time spent on the algo/coin when revenue drops sharply within 2 or 3 minutes just after switching.


Hope to see the ability to set such rule  in the near future, it should help pool (grass)hoppers like me immensely.

Thank You,
moppidoo
Jr. Member
*
Offline Offline

Activity: 348
Merit: 5


View Profile
March 23, 2018, 09:10:34 AM
 #5231

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.
vtrsp1
Newbie
*
Offline Offline

Activity: 31
Merit: 0


View Profile
March 23, 2018, 12:31:44 PM
 #5232

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?
sergw
Member
**
Offline Offline

Activity: 159
Merit: 12


View Profile
March 23, 2018, 12:44:33 PM
 #5233

Hello,

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

see pic:
O-Coin
Jr. Member
*
Offline Offline

Activity: 61
Merit: 2


View Profile
March 23, 2018, 01:30:41 PM
 #5234

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.   
akadamson
Member
**
Offline Offline

Activity: 140
Merit: 18


View Profile
March 23, 2018, 09:41:50 PM
 #5235

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.
puwaha
Sr. Member
****
Offline Offline

Activity: 700
Merit: 294


View Profile
March 24, 2018, 06:25:07 AM
 #5236

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.
eminer001
Newbie
*
Offline Offline

Activity: 140
Merit: 0


View Profile
March 24, 2018, 08:03:18 AM
 #5237

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 ?



Dalba
Newbie
*
Offline Offline

Activity: 92
Merit: 0


View Profile
March 24, 2018, 11:09:12 AM
 #5238

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 ?

 
nemzy
Newbie
*
Offline Offline

Activity: 13
Merit: 0


View Profile
March 24, 2018, 12:37:42 PM
 #5239

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
zaqwsx
Jr. Member
*
Offline Offline

Activity: 58
Merit: 5


View Profile
March 24, 2018, 03:25:43 PM
 #5240

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"!
Pages: « 1 ... 212 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 ... 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!