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

Globalboosty

newbie

Activity: 21

Merit: 0

Quote from: zergbitcore on March 25, 2018, 08:35:48 PM

Patrike,
The latest AM update has the bug with bitcore.
https://yadi.sk/i/uqfHdHCe3TkFyE
It worked well on 5 rigs before. I tried to delete my bitcore settings and keep only yours, also tried to restart the software, restart the rigs, tried to disable/enable bitcore algo with no effect. Ahashpool and Zpool bitcore profit looks ok. the problem is exist only with bitcore profit for Hasrefinery and Zergpool.

Please, make fix

It seems the problem is not the AM software. HR and ZP display 0 for actual profit for bitcore. If choose estimate profit instead it works well.

segotiwul

member

Activity: 322

Merit: 10

if we are going to play on the windows screen and have difficulties because the sever is still spinning, then we can open Windows 8.1 / 10 WHQL right away, because of the severity of the sever and the growing knowledge.

streaml1ne

newbie

Activity: 32

Merit: 0

I've got a new rig and for some reason I'm not able to benchmark anything with Excavator (the new version). I keep getting the error:

Code:

=========================== www.nicehash.com =========================
   Excavator v1.4.4a_nvidia GPU Miner for NiceHash.
   Copyright (C) 2018 NiceHash. All rights reserved.
   Developed by
   djeZo, dropky, voidstar, and agiz
   with help and contributions from
   zawawa, pallas, Vorksholk, bitbandi, ocminer, and Genoil.
=========================== www.nicehash.com =========================

Build time: 2018-02-16 13:11:25
Build number: 4645
Provided startup commandline:
   "C:\Users\user\AppData\Roaming\AwesomeMinerService\excavator\excavator.exe" -c awesome.json -p 4028

[01:03:31][0x00000f20][info] Log started
[01:03:31][0x00000f20][info] core | Found CUDA device: GeForce GTX 1070
[01:03:31][0x00000f20][info] core | Found CUDA device: GeForce GTX 1060 3GB
[01:03:31][0x00000f20][info] api | Listening on 127.0.0.1:4028
[01:03:31][0x00000f20][error] core | Command file - invalid JSON: [
[01:03:31][0x00000f20][info] core | Initialized!

The json file includes:

Code:

[
{"time":0,"commands":[
{"id":1,"method":"algorithm.add","params":["lyra2rev2","benchmark",""]}
]},
{"time":3,"commands":[
{"id":1,"method":"worker.add","params":["0","0"]},
{"id":1,"method":"worker.add","params":["0","1"]},
{"id":1,"method":"worker.add","params":["0","2"]},
{"id":1,"method":"worker.add","params":["0","3"]},
{"id":1,"method":"worker.add","params":["0","4"]},
{"id":1,"method":"worker.add","params":["0","5"]},
{"id":1,"method":"worker.add","params":["0","6"]},
{"id":1,"method":"worker.add","params":["0","7"]},
{"id":1,"method":"worker.add","params":["0","8"]},
{"id":1,"method":"worker.add","params":["0","9"]},
{"id":1,"method":"worker.add","params":["0","10"]},
{"id":1,"method":"worker.add","params":["0","11"]},
{"id":1,"method":"worker.add","params":["0","12"]}
]},
{"time":10,"loop":10,"commands":[
{PrintWorkerSpeed},
{"id":1,"method":"algorithm.print.speeds","params":["0"]}
]}
]

zergbitcore

newbie

Activity: 17

Merit: 0

Patrike,
The latest AM update has the bug with bitcore.
https://yadi.sk/i/uqfHdHCe3TkFyE
It worked well on 5 rigs before. I tried to delete my bitcore settings and keep only yours, also tried to restart the software, restart the rigs, tried to disable/enable bitcore algo with no effect. Ahashpool and Zpool bitcore profit looks ok. the problem is exist only with bitcore profit for Hasrefinery and Zergpool.

Please, make fix

akadamson

member

Activity: 140

Merit: 18

Patrike,

Can you update the WTM coin symbols in the next release, there are a number that are there currently that don't have a symbol in AM - thanks for all the hardwork, it's really a pleasure to use.

akadamson

member

Activity: 140

Merit: 18

Quote from: puwaha on March 25, 2018, 03:48:54 PM

Quote from: eminer001 on March 25, 2018, 07:17:45 AM

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).

I can't see any reason you'd want to profit-switch every 1 minute. Depending on the mining software, it can take a few minutes to ramp up to maximum hash rate. BMiner and CCminer are great examples of this. Plus most block times are longer than 1 minute. The pool doesn't have any fresh information about the statistics of that coin until the next block.

And depending on the pool's share mechanism (PPS vs PPLNT) you can actually be penalized for mining so shortly.

I've come to the same conclusions. Can't remember what the default is, but I've set the switch interval to 10 mins and the threshold to 3% Experience shows that *NOT* chasing the high price of the minute (or in this case 10 mins) and due to most of the multi/multi's being PPLNS, I stay ramped which more than makes up for chasing

puwaha

sr. member

Activity: 700

Merit: 294

Quote from: eminer001 on March 25, 2018, 07:17:45 AM

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).

I can't see any reason you'd want to profit-switch every 1 minute. Depending on the mining software, it can take a few minutes to ramp up to maximum hash rate. BMiner and CCminer are great examples of this. Plus most block times are longer than 1 minute. The pool doesn't have any fresh information about the statistics of that coin until the next block.

And depending on the pool's share mechanism (PPS vs PPLNT) you can actually be penalized for mining so shortly.

patrike

legendary

Activity: 3346

Merit: 1094

Awesome Miner version 4.6.1

- Antminer V9 supported
- Added several new algorithms, including CryptonightV7
- Performance History export via CSV file includes miner IP address if no description is set
- User interface improvements to the Benchmark dialog
- D3pool integration disabled
- Excavator miner is instructed to print the speed of all workers in the console window by default
- Bminer 6.0
- CastXMR 0.9.1
- Correction to SIA block explorer integration to handle large balance numbers
- Correction to profit switcher when all available Ethereum pools was marked to be ignored due to no increase in number of accepted shares
- Minor corrections

patrike

legendary

Activity: 3346

Merit: 1094

Quote from: ?? on ??

Hello
is there somewhere a link for setup Baikal X10 and B?
thanks Thomas

Hi. I don't have any experience in using this miner myself, by I do know that there are a number of users running Awesome Miner together with Baikal miners. There might a Baikal specific thread where more experienced users can help out as well.

From an Awesome Miner point of view, you add it as an External Miner:
http://www.awesomeminer.com/help/externalwizard.aspx

patrike

legendary

Activity: 3346

Merit: 1094

Quote from: ?? on ??

Hi Patrike,

A small and quick request, in your next release can you include that your benchmarking window be expandable instead of a fixed size on Windows?
I occasionally take screenshots to do comparisons when miners get updated or when I'm trying to tweak the GPUs. Or even better if you could allow it to export to an excel or CSV file.

Much thanks and great work!

Thanks for your nice feedback. I was just doing a few minor UI corrections to the benchmark dialog and I will make it resizable as well. The export feature will have to be a future improvement.

patrike

legendary

Activity: 3346

Merit: 1094

Quote from: Bob-Bit on March 25, 2018, 09:16:35 AM

Ok, I have what would seem to be a simple request. Can we have different profit switching intervals on different miners that can be set on individual profit profiles independently? I have a GPU miner, CPU miner, and AMD miner on my local main machine, and then I have 4 Baikal ASIC miners setup as remote miners also. Also just added a remote mining pc with one AMD card.(for now) I have the profit switching interval set to 27 minutes. If I notice that the profit from the main GPU miner has tanked, and I hit restart on it, the timer resets, and the other miners won't profit switch till the main miner timer gets to 28 minutes. If the profit tanks again, the whole process repeats, and if the other miners look like they are doing badly, they have to be restarted manually as well, and it isn't clear (at least with the Baikals) that they are going to the most profitable coin (It seems like they switch to miningpoolhub no matter what, then do an actual profit switch maybe 15 minutes later) It would be invaluable to have separate timers on each profit profile that work independently. Sometimes I see the main miner is doing great, and I change the profit switching interval to 45 minutes (basically doubling it) so it doesn't switch, but this affects all the miners, and obviously it would be much better if they were independent of one another. Thanks for all your hard work and improvements Patrike! They don't go unnoticed on this end!

Thanks for the feedback on this. I agree that having a setting for the interval per profile would make sense.

powerstr

newbie

Activity: 107

Merit: 0

Hello!
the reaction rate on pampas fell...
auto-switching does not always happen when you select a profit coin!

akadamson

member

Activity: 140

Merit: 18

Quote from: patrike on March 25, 2018, 03:43:34 AM

Quote from: akadamson on March 23, 2018, 04:41:50 PM

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.

2) happened only the first time I started the miner it didn't pick up the addition of a command line arg for a managed miner, it did on the second start however. (note the miner was running when I made that change so this might have had something to do with it)

I wonder if on 3) above, it's because it's a stratum+ssl not tcp? It doesn't show the name or the url

Bob-Bit

jr. member

Activity: 241

Merit: 6

Ok, I have what would seem to be a simple request. Can we have different profit switching intervals on different miners that can be set on individual profit profiles independently? I have a GPU miner, CPU miner, and AMD miner on my local main machine, and then I have 4 Baikal ASIC miners setup as remote miners also. Also just added a remote mining pc with one AMD card.(for now) I have the profit switching interval set to 27 minutes. If I notice that the profit from the main GPU miner has tanked, and I hit restart on it, the timer resets, and the other miners won't profit switch till the main miner timer gets to 28 minutes. If the profit tanks again, the whole process repeats, and if the other miners look like they are doing badly, they have to be restarted manually as well, and it isn't clear (at least with the Baikals) that they are going to the most profitable coin (It seems like they switch to miningpoolhub no matter what, then do an actual profit switch maybe 15 minutes later) It would be invaluable to have separate timers on each profit profile that work independently. Sometimes I see the main miner is doing great, and I change the profit switching interval to 45 minutes (basically doubling it) so it doesn't switch, but this affects all the miners, and obviously it would be much better if they were independent of one another. Thanks for all your hard work and improvements Patrike! They don't go unnoticed on this end!

patrike

legendary

Activity: 3346

Merit: 1094

Quote from: eminer001 on March 25, 2018, 07:17:45 AM

Quote from: patrike on March 25, 2018, 06:29:12 AM

Quote from: eminer001 on March 25, 2018, 04:23:01 AM

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).

So there are actually two values here.

The lowest value for the profit switcher (Options dialog, Profit Switching section) is 1 minute.
The lowest value for the coin statistics (Options dialog, Statistics section) is 2 minutes. This one mainly makes sense if you don't use the profit switcher or if your profit switcher is on a slow interval.

However, if you set your profit switcher to 1 minute, Awesome Miner will use 1 minute for all statistics updates as well (WhatToMine, Nicehash, zpool, ...).

moppidoo

jr. member

Activity: 348

Merit: 5

Quote from: patrike on March 25, 2018, 03:03:24 AM

Quote from: moppidoo on March 21, 2018, 05:03:48 PM

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?

Hi Patrike,

Sorry for the confusion, yes it's to batch update power usage for all/multiple algos at once within a profit profile.

eminer001

newbie

Activity: 140

Merit: 0

Quote from: patrike on March 25, 2018, 06:29:12 AM

Quote from: eminer001 on March 25, 2018, 04:23:01 AM

Quote from: patrike on March 25, 2018, 04:02:00 AM

Quote from: eminer001 on March 25, 2018, 03:09:53 AM

Quote from: eminer001 on March 24, 2018, 03:03:18 AM

Quote from: eminer001 on March 22, 2018, 03:06:01 AM

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).

patrike

legendary

Activity: 3346

Merit: 1094

Quote from: eminer001 on March 25, 2018, 04:23:01 AM

Quote from: patrike on March 25, 2018, 04:02:00 AM

Quote from: eminer001 on March 25, 2018, 03:09:53 AM

Quote from: eminer001 on March 24, 2018, 03:03:18 AM

Quote from: eminer001 on March 22, 2018, 03:06:01 AM

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.

ruplikminer

jr. member

Activity: 504

Merit: 3

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.

eminer001

newbie

Activity: 140

Merit: 0

Quote from: patrike on March 25, 2018, 04:02:00 AM

Quote from: eminer001 on March 25, 2018, 03:09:53 AM

Quote from: eminer001 on March 24, 2018, 03:03:18 AM

Quote from: eminer001 on March 22, 2018, 03:06:01 AM

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 ?

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