Quote from: patrike on August 05, 2017, 08:46:32 AM

First of all, thanks for all feedback.[...]

You're welcome

Quote from: Dumpfdoesel on August 04, 2017, 07:00:51 PM

Undo retirement of ccminer-1.5.81_1 (SP-Mod 1.5.81)
It is much faster (3x!! on GTX 1080ti) on keccak, but useless on almost any other algo :-(
Option to specify any type of miner software, preferrably one per algo.
Some miner sw is considerable faster on a specific algo than others (e.g.
- For miner sw with cmdline switches the entire commandline should be configurable using variables:
eg. "-a %ALGO% -i 31 -o %URL% -u %USER% -p x -b 0.0.0.0:4028 -x 1 -y 2 -z 3"

There are already two ccminer versions included (2.1 and Alexis). In addition to that, you can still add you own Managed Software, where you can define that you want to use the old ccminer for Keccak only. With the Managed Software feature you can define which algorithms to use for each mining software.

Since the 'own managed software' is working now in 3.2.2 I can add any miner sw. Just what the doctor ordered - thanks for that!

Quote from: patrike on August 05, 2017, 08:46:32 AM

Good suggestion about the variables, it could make sense for Generic Miner.

I just love variables...

Quote from: patrike on August 05, 2017, 08:46:32 AM

Quote from: Dumpfdoesel on August 04, 2017, 07:00:51 PM

Option to run two (or more) miner instances on the same GPU, but so that
the miner sw does not get switched (when using profit switching) on all instances @ same time
Instead there should be a delay before the miner sw gets switched on the next instance (to the now most profitable algo!).
e.g.:
1. switch miner sw / algo on first instance
2. wait some time (configurable, e.g. 30 secs or 'profit switching interval / number of miner instances')
3. update profit list and dermine most profitable algo
4. on the next instance: if most profitable alto is different from the currently executed one then switch miner sw / algo
5. loop to 2 ... next instance
Why? I run two miner instances on the same GPU so I never loose hash time when swiching miner sw (e.g DAG preparation takes ages, before mining begins)

This is a very specific scenario for the profit switcher. The original idea was to keep it as simple as possible in contrast to Managed Miners where you can do almost anything. I will see if I can figure something out to handle this scenario in a good way.

A simple configurable delay and re-evaluation of most profitable miner before switching algo would do nicely.

Quote from: patrike on August 05, 2017, 08:46:32 AM

Quote from: Dumpfdoesel on August 04, 2017, 07:00:51 PM

Cumulated summary per miner group

What is the information you would like to see here, and where should it be presented?

Basically the same as if only one instance was selected (e.g. revenue, avg. hashrates)