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

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

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.

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.   

Hello,

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

see pic:

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?

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.

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,

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
.

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.

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 ?

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?

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.

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 ?

Is there documentation or tutorials for the custom scripting aspect?

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 ?

Options -> Coins & Profit -> Display Currency
Set to BTC

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.

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.

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,

Awesome Miner version 4.6

- GPU clocking improved by introducing GPU Clocking groups to support mixed clocking settings per GPU
- Custom Online Services can be added to support any Yiimp compatible pool
- Remote Proxy concept introduced to support very large scale mining operations
- The Change Pool and Add Pool menus are redesigned to include a searchable pool selection dialog, to support a larger number of pools.
- The Add Pool operation is added to the main toolbar and can be performed on all selected External Miners
- The Pool Change operation is made available with more mining software for a Managed Miner in the web interface
- SSH port configurable for External Miners
- Display temperature for Innosilicon A4+ miners
- Support for automatic configuration of Windows Defender
- Improved batch command execution to allow execution when a miner is starting or stopping, for Managed Miners, Managed Profit Miners and per algorithm for Profit Profiles
- Improved context menus and change detection for the Pool Balance feature
- Number of active miners at Yiimp compatible pools displayed in the Online Services tab
- Revenue and Profit displayed as separate columns in the Online Services tab
- Multiple miners can be selected and removed in a single operation from the Miners tab in the main window
- Enforce single instance of the Remote Agent application
- Indonesian Rupiah added as display currency
- Updates to Mining Dutch port numbers to avoid low difficulty ports by default
- Updates to Zergpool URL's to support the new sub domains per algorithm
- Claymore Dual Ethereum Miner 11.5
- PhoenixMiner 2.7c
- XMRig miner 2.4.5
- CastXMR 0.9.0
- Bminer 5.5
- Correction to benchmarking of Excavator miner
- Correction to Ignore GPU feature for the MSI Afterburner integration
- Correction to display of pool balance where the coin is unknown
- Correction to the profit switcher for disabled algorithms and custom pools
- Correction to power cost calculations for the profit switcher
- Correction to the Change pool action used via the Rules
- Correction to activating the main window when started with the minimized option enabled
- Minor corrections