[ANN] Miner Control 1.6.1 - Auto profit switching miner controller - page 43.

StuffOfInterest

sr. member

Activity: 401

Merit: 250

Quote from: superresistant on November 18, 2014, 06:38:50 AM

This piece of software is amazing.
I would be even more amazing with monero mining support.

What do you think ?

Miner Control can mine anything because it doesn't actually do the mining. All Miner Control does is contact pools to get pricing info and then launch an external mining program with the configuration you specify. There is nothing which will keep it from mining Monero. The problem comes in getting pricing info. Miner Control works by calling to a pool's API to retrieve pricing info. Those prices need to be in Bitcoin in order to rank the profitability and select which pool/algo to mine. So, short answer is yes you can use Miner Control to mine Monero but only if the pool has a pricing API in Bitcoin.

superresistant

legendary

Activity: 2142

Merit: 1131

This piece of software is amazing.
I would be even more amazing with monero mining support.

What do you think ?

lextad

newbie

Activity: 29

Merit: 0

+++++++++AMD +++++++++++
hello resend i have a encounter some problems with the the new and old sgminer and miner control i star the auto and start to show DEAD if i rung the sgminers will run's with out problem.
This is the conf.file (i have change all the important thins )
This was check with http://jsonlint.com/ is good
Thanks for the help

Code:

{
    "general": {
        "power": 0.09,
        "exchange": 300,
        "currencycode": "USD",
        "mintime": 4,
        "maxtime": 120,
        "switchtime": 3,
        "deadtime": 10,
        "logerrors": true,
        "logactivity": true,
        "gridsortmode": 1,
        "minerkillmode": 0,
        "traymode": 1,
        "donationpercentage": 2,
        "donationfrequency": 240,
        "remotesend": true,
        "remotereceive": true
    },
    "algorithms": [
        { "name": "x11", "hashrate": 5251, "power": 49, "aparam1": "", "aparam2": "sgminer.exe", "aparam3": "-a x11" },
        { "name": "x13", "hashrate": 4024, "power": 49, "aparam1": "", "aparam2": "sgminer.exe", "aparam3": "-a x13" },
        { "name": "x14", "hashrate": 4024, "power": 52, "aparam1": "", "aparam2": "sgminer.exe", "aparam3": "-a x14" },
        { "name": "x15", "hashrate": 3270, "power": 52, "aparam1": "", "aparam2": "sgminer.exe", "aparam3": "-a x15" },
        { "name": "nist5", "hashrate": 15682, "power": 54, "aparam1": "", "aparam2": "sgminer.exe", "aparam3": "-a nist5" },
        { "name": "neoscrypt", "hashrate": 80, "power": 54, "aparam1": "", "aparam2": "sgminer.exe", "aparam3": "-a neoscrypt" }
    ],
    "nicehash": {
        "account": "1Ced7sziGNldjJ564xnqcYyDpjCfqTS25DC7n",
        "worker": "270x",
        "sparam1": "-o stratum+tcp://stratum.nicehash.com",
        "sparam2": "-p x",
        "weight": 0.90,
        "algos": [
            { "algo": "x11", "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:3336 -u _ACCOUNT_._WORKER_ _SPARAM2_", "usewindow":  true },
            { "algo": "x13", "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:3337 -u _ACCOUNT_._WORKER_ _SPARAM2_", "usewindow":  true },
            { "algo": "x15", "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:3339 -u _ACCOUNT_._WORKER_ _SPARAM2_", "usewindow":  true },
            { "algo": "scrypt", "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:3333 -u _ACCOUNT_._WORKER_ _SPARAM2_", "usewindow":  true },
            { "algo": "scryptn", "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:3335 -u _ACCOUNT_._WORKER_ _SPARAM2_", "usewindow":  true },
            { "algo": "keccak", "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:3338 -u _ACCOUNT_._WORKER_ _SPARAM2_", "usewindow":  true },
            { "algo": "nist5", "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:3340 -u _ACCOUNT_._WORKER_ _SPARAM2_", "usewindow":  true },
            { "algo": "neoscrypt", "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:3341 -u _ACCOUNT_._WORKER_ _SPARAM2_", "usewindow":  true },
            { "algo": "sha256", "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:3332 -u _ACCOUNT_._WORKER_ _SPARAM2_", "usewindow":  true }
        ]
    },
    "westhash": {
        "account": "1Ced7sziGNLnfuc4xnqcYyDDrfD526256fqTBzC7n",
        "worker": "270x",
        "sparam1": "-o stratum+tcp://stratum.westhash.com",
        "sparam2": "-p x",
        "algos": [
            { "algo": "x11", "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:3336 -u _ACCOUNT_._WORKER_ _SPARAM2_", "usewindow":  true },
            { "algo": "x13", "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:3337 -u _ACCOUNT_._WORKER_ _SPARAM2_", "usewindow":  true },
            { "algo": "x15", "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:3339 -u _ACCOUNT_._WORKER_ _SPARAM2_", "usewindow":  true },
            { "algo": "scrypt", "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:3333 -u _ACCOUNT_._WORKER_ _SPARAM2_", "usewindow":  true },
            { "algo": "scryptn", "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:3335 -u _ACCOUNT_._WORKER_ _SPARAM2_", "usewindow":  true },
            { "algo": "keccak", "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:3338 -u _ACCOUNT_._WORKER_ _SPARAM2_", "usewindow":  true },
            { "algo": "nist5", "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:3340 -u _ACCOUNT_._WORKER_ _SPARAM2_", "usewindow":  true },
            { "algo": "neoscrypt", "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:3341 -u _ACCOUNT_._WORKER_ _SPARAM2_", "usewindow":  true }
        ]
    },
    "trademybit": {
        "apikey": "13f0ad617c24230cccb5387258f1a07fde0d0fba0dfacSdf265b1hysdI25dfgF14582c6366b4",
        "account": "lex",
        "worker": "270x",
        "sparam1": "-o stratum+tcp://east01.us.trademybit.com",
        "sparam2": "-p x",
        "algos": [
            { "algo": "x11", "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:4440 -u _ACCOUNT_._WORKER_ _SPARAM2_", "usewindow":  true },
            { "algo": "x13", "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:5550 _ACCOUNT_._WORKER_ _SPARAM2_", "usewindow":  true },
            { "algo": "x15", "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:6660 _ACCOUNT_._WORKER_ _SPARAM2_", "usewindow":  true },
            { "algo": "nist5", "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:7770 _ACCOUNT_._WORKER_ _SPARAM2_", "usewindow":  true },
            { "algo": "neoscrypt", "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:8880 _ACCOUNT_._WORKER_ _SPARAM2_", "usewindow":  true },
            { "algo": "scrypt", "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:3330 _ACCOUNT_._WORKER_ _SPARAM2_", "usewindow":  true },
            { "algo": "scryptn", "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:2220 _ACCOUNT_._WORKER_ _SPARAM2_", "usewindow":  true }
        ]
    },
    "yaamp": {
        "account": "1Ced7sziGNLnDjjmKL2qcYyDpjCfqTBzC7n",
        "sparam1": "-o stratum+tcp://y2aamp.com",
        "sparam2": "-p x",
        "algos": [
            { "algo": "x11", "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:3533 -u _ACCOUNT_ _SPARAM2_", "usewindow":  true },
            { "algo": "x13", "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:3633 _ACCOUNT_ _SPARAM2_", "usewindow":  true },
            { "algo": "x14", "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:3933 _ACCOUNT_ _SPARAM2_", "usewindow":  true },
            { "algo": "x15", "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:3733 _ACCOUNT_ _SPARAM2_", "usewindow":  true },
            { "algo": "quark", "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:4033 _ACCOUNT_ _SPARAM2_", "usewindow":  true },
            { "algo": "nist5", "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:3833 _ACCOUNT_ _SPARAM2_", "usewindow":  true },
            { "algo": "scrypt", "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:3433 _ACCOUNT_ _SPARAM2_", "usewindow":  true }
        ]
    },
    "wafflepool": {
        "account": "1Ced7sziGNLnfuS2DFxnqcYyDpS515FG2qTBzC7n",
        "worker":  "270x",
        "sparam1": "-o stratum+tcp://useast.wafflepool.com",
        "sparam2": "-p x",
        "algos": [
            { "algo": "x11", "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:3331 -u _ACCOUNT_._WORKER_ _SPARAM2_", "usewindow":  true },
            { "algo": "x13", "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:3330 _ACCOUNT_._WORKER_ _SPARAM2_", "usewindow":  true },
            { "algo": "scrypt", "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:3333 _ACCOUNT_._WORKER_ _SPARAM2_", "usewindow":  true },
            { "algo": "scryptn", "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:3332 _ACCOUNT_._WORKER_ _SPARAM2_", "usewindow":  true }
        ]
    },
    "ltcrabbit": {
        "apikey": "bb06dc752562fe018b2072c61a936DRgt2365e85649b578bec83dcd4265FGth9868f88ba3eac",
        "account": "lex",
        "worker":  "270x",
        "sparam2": "-p x",
        "algos": [
            { "algo": "x11", "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ -o stratum+tcp://x11.ltcrabbit.com:3332 -u _ACCOUNT_._WORKER_ _SPARAM2_", "usewindow":  true },
            { "algo": "scrypt", "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ -o stratum+tcp://scrypt.ltcrabbit.com:3333 _ACCOUNT_._WORKER_ _SPARAM2_", "usewindow":  true }
        ]
    }
}

jjjordan

sr. member

Activity: 271

Merit: 251

Quote from: DemosMirak on November 16, 2014, 09:02:59 AM

Mind you, I know next to nothing about coding, but wouldn't it be possible to use the miner to check for life? Let's say you're mining with miner A, and you want to check if service B is alive. You then start miner B, and if it gets a block or other sign of life, you close miner A and let miner B do it's thing. If it doesn't get a sign of life, you close miner B and let miner A continue.

Yeah dude, I thought of that as well. But having 10 pools to check it means MC has to open 10 instances of a miner? Every minute?...

Even with 5 that would be too much.
Anyhow - I hope there are more knowledgeable people that can help with how to check for an alive pool. Maybe someone from the sgminer devs? The sgminer code is available for everybody to look at, right? If somebody can read it that would be great.

DemosMirak

full member

Activity: 146

Merit: 100

Mind you, I know next to nothing about coding, but wouldn't it be possible to use the miner to check for life? Let's say you're mining with miner A, and you want to check if service B is alive. You then start miner B, and if it gets a block or other sign of life, you close miner A and let miner B do it's thing. If it doesn't get a sign of life, you close miner B and let miner A continue.

StuffOfInterest

sr. member

Activity: 401

Merit: 250

Quote from: jjjordan on November 16, 2014, 12:27:10 AM

Quote from: Travis9x on November 15, 2014, 10:16:48 PM

Quote from: jjjordan on November 15, 2014, 12:11:14 PM

Quote from: Travis9x on November 15, 2014, 09:50:50 AM

Quote from: jjjordan on November 15, 2014, 01:06:28 AM

....
It will be even worse if there is no rented rig (all MRR are dead) - there will be at least 2min pause every switchtime...
Am I missing something? Maybe there is another way to do it?
I think it would be the ideal way if MC could check for pools viability before switching to them?
And then switches to the first alive pool going from the most profitable down...

Since you're using it to manually switch between renters, which will only do so when one goes down, you don't really need any "switch time" at all. I'd say set it to something extremely low, or even 0, so there is little-to-no wait time when switching.

Travis, I might not be getting exactly what your idea is, but here is some more detailed explanation:
First 4 pools (MRR in name) are rentals. They will be all dead, OR only one will be alive.
MC should switch when one of them gets alive AND switch back to profit based when all the rentals are dead.
Here is a simple block diagram:

I achieved that, but the main problem is in order to do the "IF" statement MC has to go through (start mining at) all the pools based on their profitability,
which means there will be a lot of down time (retries before a pool is declared dead). That is because a check for an alive renting pool should be done once
every 1 or 2 mins. So even if there is no change in which pools are alive or dead there will be an interruption of mining for pool status check. So that was my initial idea -
Could Miner Control check pool viability without actually interrupting current mining?

Like is it possible to start new instance of ccminer that only checks if pools are dead or alive?
And only initiate a switch if there is a change in the profitability/availability of pools?
I am pretty sure that is the way c/sgminer works (without the profitability part).

You are correct. SGminer/CGminer already have this function built-in, since AMD cards were all the rage for cryptomining at first. NVIDIA mining only just recently began to have some advantage over AMD, so the mining tools for NVIDIA are still being developed. I think you may be one of the first people I've heard of who is seriously wanting to use NVIDIA cards for mining rental, so that's why you're finding some difficulty in finding a tool for this purpose, specifically for NVIDIA GPUs. The need simply wasn't there before, so you're basically breaking new ground.
Fortunately, what you need should be a reasonably simple feature that could be added to MinerControl (I can't see it being as easy to directly build it in to ccMiner), since it would basically only have to ping the "dead" servers (at least in your case, and if I'm understanding the nature of these rental servers correctly). There could be a "switch" value in the config file, that would flag certain pools as rentals. When starting to mine, or whenever the "dead" timer expires, any dead pools which are flagged would be pinged first to check on alive status, before trying to mine them. This rental mining feature would be an entirely new mode in MinerControl, so there would be some work in coding that, but the technical aspects are fairly simple.
Unfortunately I've become rather busy lately and so I don't have the time to tinker with the idea myself, but I'm sure StuffOfInterest would be happy to add it to the wishlist of features, if you ask him nicely. Wink

Alright, I'll be the most nicest people out here...

As for renting - we are all mining to get some BTC, am I correct?
And if you can provide mining to somebody else for higher profit, then why not?

So StuffOfInterest - I must say again I admire thee for what you are doing here and how this is helpful to all of us.
I also have some ideas about the logic behind pool switching. This will switch to the first "priority" pool (it has to be defined as such) that is alive
which makes it kind of a "failover" strategy for "priority" pools and if they are all dead/missing it will be profit based for the rest of them as
it is now. It might not be any particular language, but it's way easier for me to show logic in code, rather than describe it in plain text.

Code:

{
foreach (all_priority_pools as current_pool) {
     if (current_pool[status]==alive) {
         return current_pool; exit ;
         }
foreach (all_pools_except_priority as current_pool) {
     /*... profit based switching as it is now ... */
     }
}

OK, here is the problem for adding this to Miner Control. How does Miner Control go about testing of the pool is alive? It currently has no logic for communicating with the stratum server. One thing I've considered is building a stratum proxy into Miner Control but unless I see a straight forward example in something that translates easily to C# it probably won't happen as I'm too time pressed to add major features like this currently. I suppose we wouldn't have to implement the entire logic but we would need to at least have a good model for the connection setup and teardown piece as this is how you would determine if the port is open. I've honestly never dug into stratum so I don't know what all is going on there.

You've put an impressive amount of effort into getting this working already. I never imagined someone pushing Miner Control that far.

jjjordan

sr. member

Activity: 271

Merit: 251

Quote from: Travis9x on November 15, 2014, 10:16:48 PM

Quote from: jjjordan on November 15, 2014, 12:11:14 PM

Quote from: Travis9x on November 15, 2014, 09:50:50 AM

Quote from: jjjordan on November 15, 2014, 01:06:28 AM

....
It will be even worse if there is no rented rig (all MRR are dead) - there will be at least 2min pause every switchtime...
Am I missing something? Maybe there is another way to do it?
I think it would be the ideal way if MC could check for pools viability before switching to them?
And then switches to the first alive pool going from the most profitable down...

Since you're using it to manually switch between renters, which will only do so when one goes down, you don't really need any "switch time" at all. I'd say set it to something extremely low, or even 0, so there is little-to-no wait time when switching.

Travis, I might not be getting exactly what your idea is, but here is some more detailed explanation:
First 4 pools (MRR in name) are rentals. They will be all dead, OR only one will be alive.
MC should switch when one of them gets alive AND switch back to profit based when all the rentals are dead.
Here is a simple block diagram:

I achieved that, but the main problem is in order to do the "IF" statement MC has to go through (start mining at) all the pools based on their profitability,
which means there will be a lot of down time (retries before a pool is declared dead). That is because a check for an alive renting pool should be done once
every 1 or 2 mins. So even if there is no change in which pools are alive or dead there will be an interruption of mining for pool status check. So that was my initial idea -
Could Miner Control check pool viability without actually interrupting current mining?

Like is it possible to start new instance of ccminer that only checks if pools are dead or alive?
And only initiate a switch if there is a change in the profitability/availability of pools?
I am pretty sure that is the way c/sgminer works (without the profitability part).

You are correct. SGminer/CGminer already have this function built-in, since AMD cards were all the rage for cryptomining at first. NVIDIA mining only just recently began to have some advantage over AMD, so the mining tools for NVIDIA are still being developed. I think you may be one of the first people I've heard of who is seriously wanting to use NVIDIA cards for mining rental, so that's why you're finding some difficulty in finding a tool for this purpose, specifically for NVIDIA GPUs. The need simply wasn't there before, so you're basically breaking new ground.
Fortunately, what you need should be a reasonably simple feature that could be added to MinerControl (I can't see it being as easy to directly build it in to ccMiner), since it would basically only have to ping the "dead" servers (at least in your case, and if I'm understanding the nature of these rental servers correctly). There could be a "switch" value in the config file, that would flag certain pools as rentals. When starting to mine, or whenever the "dead" timer expires, any dead pools which are flagged would be pinged first to check on alive status, before trying to mine them. This rental mining feature would be an entirely new mode in MinerControl, so there would be some work in coding that, but the technical aspects are fairly simple.
Unfortunately I've become rather busy lately and so I don't have the time to tinker with the idea myself, but I'm sure StuffOfInterest would be happy to add it to the wishlist of features, if you ask him nicely. Wink

Alright, I'll be the most nicest people out here...

As for renting - we are all mining to get some BTC, am I correct?
And if you can provide mining to somebody else for higher profit, then why not?

So StuffOfInterest - I must say again I admire thee for what you are doing here and how this is helpful to all of us.
I also have some ideas about the logic behind pool switching. This will switch to the first "priority" pool (it has to be defined as such) that is alive
which makes it kind of a "failover" strategy for "priority" pools and if they are all dead/missing it will be profit based for the rest of them as
it is now. It might not be any particular language, but it's way easier for me to show logic in code, rather than describe it in plain text.

Code:

{
foreach (all_priority_pools as current_pool) {
     if (current_pool[status]==alive) {
         return current_pool; exit ;
         }
foreach (all_pools_except_priority as current_pool) {
     /*... profit based switching as it is now ... */
     }
}

Travis9x

full member

Activity: 170

Merit: 100

Quote from: jjjordan on November 15, 2014, 12:11:14 PM

Quote from: Travis9x on November 15, 2014, 09:50:50 AM

Quote from: jjjordan on November 15, 2014, 01:06:28 AM

....
It will be even worse if there is no rented rig (all MRR are dead) - there will be at least 2min pause every switchtime...
Am I missing something? Maybe there is another way to do it?
I think it would be the ideal way if MC could check for pools viability before switching to them?
And then switches to the first alive pool going from the most profitable down...

Since you're using it to manually switch between renters, which will only do so when one goes down, you don't really need any "switch time" at all. I'd say set it to something extremely low, or even 0, so there is little-to-no wait time when switching.

Travis, I might not be getting exactly what your idea is, but here is some more detailed explanation:
First 4 pools (MRR in name) are rentals. They will be all dead, OR only one will be alive.
MC should switch when one of them gets alive AND switch back to profit based when all the rentals are dead.
Here is a simple block diagram:

I achieved that, but the main problem is in order to do the "IF" statement MC has to go through (start mining at) all the pools based on their profitability,
which means there will be a lot of down time (retries before a pool is declared dead). That is because a check for an alive renting pool should be done once
every 1 or 2 mins. So even if there is no change in which pools are alive or dead there will be an interruption of mining for pool status check. So that was my initial idea -
Could Miner Control check pool viability without actually interrupting current mining?

Like is it possible to start new instance of ccminer that only checks if pools are dead or alive?
And only initiate a switch if there is a change in the profitability/availability of pools?
I am pretty sure that is the way c/sgminer works (without the profitability part).

You are correct. SGminer/CGminer already have this function built-in, since AMD cards were all the rage for cryptomining at first. NVIDIA mining only just recently began to have some advantage over AMD, so the mining tools for NVIDIA are still being developed. I think you may be one of the first people I've heard of who is seriously wanting to use NVIDIA cards for mining rental, so that's why you're finding some difficulty in finding a tool for this purpose, specifically for NVIDIA GPUs. The need simply wasn't there before, so you're basically breaking new ground.
Fortunately, what you need should be a reasonably simple feature that could be added to MinerControl (I can't see it being as easy to directly build it in to ccMiner), since it would basically only have to ping the "dead" servers (at least in your case, and if I'm understanding the nature of these rental servers correctly). There could be a "switch" value in the config file, that would flag certain pools as rentals. When starting to mine, or whenever the "dead" timer expires, any dead pools which are flagged would be pinged first to check on alive status, before trying to mine them. This rental mining feature would be an entirely new mode in MinerControl, so there would be some work in coding that, but the technical aspects are fairly simple.
Unfortunately I've become rather busy lately and so I don't have the time to tinker with the idea myself, but I'm sure StuffOfInterest would be happy to add it to the wishlist of features, if you ask him nicely. Wink

jjjordan

sr. member

Activity: 271

Merit: 251

Quote from: Travis9x on November 15, 2014, 09:50:50 AM

Quote from: jjjordan on November 15, 2014, 01:06:28 AM

....
It will be even worse if there is no rented rig (all MRR are dead) - there will be at least 2min pause every switchtime...
Am I missing something? Maybe there is another way to do it?
I think it would be the ideal way if MC could check for pools viability before switching to them?
And then switches to the first alive pool going from the most profitable down...

Since you're using it to manually switch between renters, which will only do so when one goes down, you don't really need any "switch time" at all. I'd say set it to something extremely low, or even 0, so there is little-to-no wait time when switching.

Travis, I might not be getting exactly what your idea is, but here is some more detailed explanation:
First 4 pools (MRR in name) are rentals. They will be all dead, OR only one will be alive.
MC should switch when one of them gets alive AND switch back to profit based when all the rentals are dead.
Here is a simple block diagram:

I achieved that, but the main problem is in order to do the "IF" statement MC has to go through (start mining at) all the pools based on their profitability,
which means there will be a lot of down time (retries before a pool is declared dead). That is because a check for an alive renting pool should be done once
every 1 or 2 mins. So even if there is no change in which pools are alive or dead there will be an interruption of mining for pool status check. So that was my initial idea -
Could Miner Control check pool viability without actually interrupting current mining?

Like is it possible to start new instance of ccminer that only checks if pools are dead or alive?
And only initiate a switch if there is a change in the profitability/availability of pools?
I am pretty sure that is the way c/sgminer works (without the profitability part).

Travis9x

full member

Activity: 170

Merit: 100

Quote from: jjjordan on November 15, 2014, 01:06:28 AM

Quote from: StuffOfInterest on November 13, 2014, 11:52:20 AM

Quote from: jjjordan on November 13, 2014, 10:32:50 AM

About the failover - Is there a failover only mode (prioritized pool list) or is it only profit based mode?
I know for the failover mode workaround - using algo weights and so on, but it's very annoying if you have 10-15 pools or so.
So clean failover mode would be great - "disabling" profit switching and using pools based on a priority list.

There is a section for configuring manual pools. This works in conjunction with having the miners exit if unable to connect (which flags them as dead) to fall back to less and less profitable services. See the first post in the thread for how to configure.

So I got it up and running in "manual profit based priority" mode.
I faced couple of problems:

1. I use MRR to rent my rigs. This means pool configuration like that:

Code:

code stuff

So my miner will automatically start mining to one of the MRR pools (high "profitability" with price:100) if anybody rents some of them. So far so good, but let's say X15 MRR is rented.
Miner Control (MC) starts in auto mode:
- Mining at X11 MRR - MC tries 3 times with 10s pause (-r 3 -R10) total of 30s before it declares pool as dead
- Mining at X13 MRR - there it goes another 30s
- Starts mining at X15 MRR which will be alive.
- switchtime is 2min - even better to be 1min, because I'd want my renter to get his hashrate sooner. That means every 2min of mining will be followed by 1min of waiting when declaring dead pools.

It will be even worse if there is no rented rig (all MRR are dead) - there will be at least 2min pause every switchtime...
Am I missing something? Maybe there is another way to do it?
I think it would be the ideal way if MC could check for pools viability before switching to them?
And then switches to the first alive pool going from the most profitable down...

Since you're using it to manually switch between renters, which will only do so when one goes down, you don't really need any "switch time" at all. I'd say set it to something extremely low, or even 0, so there is little-to-no wait time when switching.

jjjordan

sr. member

Activity: 271

Merit: 251

Quote from: StuffOfInterest on November 13, 2014, 11:52:20 AM

Quote from: jjjordan on November 13, 2014, 10:32:50 AM

About the failover - Is there a failover only mode (prioritized pool list) or is it only profit based mode?
I know for the failover mode workaround - using algo weights and so on, but it's very annoying if you have 10-15 pools or so.
So clean failover mode would be great - "disabling" profit switching and using pools based on a priority list.

There is a section for configuring manual pools. This works in conjunction with having the miners exit if unable to connect (which flags them as dead) to fall back to less and less profitable services. See the first post in the thread for how to configure.

So I got it up and running in "manual profit based priority" mode.
I faced couple of problems:

1. I use MRR to rent my rigs. This means pool configuration like that:

Code:

    "manual": {
        "account": "xxxxxx",
        "sparam1": "stratum+tcp://us-central01.miningrigrentals.com:3333",
        "algos": [
            { "algo": "x11 MRR", "price": 100, "fee": 0, "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_ -u _ACCOUNT_.100001 -p x", "usewindow": true },
            { "algo": "x13 MRR", "price": 100, "fee": 0, "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_ -u _ACCOUNT_.100003 -p x", "usewindow": true },
            { "algo": "x15 MRR", "price": 100, "fee": 0, "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_ -u _ACCOUNT_.100004 -p x", "usewindow": true },
            { "algo": "nist5 MRR", "price": 100, "fee": 0, "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_ -u _ACCOUNT_.100002 -p x", "usewindow": true },
            { "algo": "x11 manual", "price": 1, "fee": 0, "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ stratum+tcp://manualpool.com:3333 -u manualaccount -p x", "usewindow": true },
            { "algo": "x13 manual", "price": 1, "fee": 0, "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ stratum+tcp://manualpool.com:3333 -u manualaccount -p x", "usewindow": true },
            { "algo": "x15 manual", "price": 1, "fee": 0, "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ stratum+tcp://manualpool.com:3333 -u manualaccount -p x", "usewindow": true },
            { "algo": "nist5 manual", "price": 1, "fee": 0, "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ stratum+tcp://manualpool.com:3333 -u manualaccount -p x", "usewindow": true },
        ]
    }

So my miner will automatically start mining to one of the MRR pools (high "profitability" with price:100) if anybody rents some of them. So far so good, but let's say X15 MRR is rented.
Miner Control (MC) starts in auto mode:
- Mining at X11 MRR - MC tries 3 times with 10s pause (-r 3 -R10) total of 30s before it declares pool as dead
- Mining at X13 MRR - there it goes another 30s
- Starts mining at X15 MRR which will be alive.
- switchtime is 2min - even better to be 1min, because I'd want my renter to get his hashrate sooner. That means every 2min of mining will be followed by 1min of waiting when declaring dead pools.

It will be even worse if there is no rented rig (all MRR are dead) - there will be at least 2min pause every switchtime...
Am I missing something? Maybe there is another way to do it?
I think it would be the ideal way if MC could check for pools viability before switching to them?
And then switches to the first alive pool going from the most profitable down...

2. Had to define more "algos" so I can tell different pools in "manual" service even though both pools use same algorithm. (cosmetic issue, more of annoyance but not functionality)
Example:

Code:

        { "name": "x11 NiceHash", "hashrate": 5435, "power": 49, "aparam1": "C:\\CryptoMining\\ccminer-maxwell-optimized-1.47.sp", "aparam2": "ccminer.exe", "aparam3": "-q -r 3 -R 10 -a x11 --no-color -o" },
        { "name": "x11 Blackcoinpool", "hashrate": 5435, "power": 49, "aparam1": "C:\\CryptoMining\\ccminer-maxwell-optimized-1.47.sp", "aparam2": "ccminer.exe", "aparam3": "-q -r 3 -R 10 -a x11 --no-color -o" },

int3ractivodular

sr. member

Activity: 280

Merit: 250

TECHNOLOGY, BABY!

Great work as usual, keep it up! Love the remote console features.

StuffOfInterest

sr. member

Activity: 401

Merit: 250

Quote from: Travis9x on November 13, 2014, 01:36:39 PM

Quote from: jjjordan on November 13, 2014, 10:32:50 AM

Are you aware if there is a specific sgminer build for nvidia, and is it only used for neoscrypt or all algorithms?

All versions of CG/SG miner were designed with AMD in mind. In fact, as StuffOfInterest pointed out, CGminer doesn't even work with NVIDIA GPUs at all. Fortunately, I believe someone is working on a ccMiner for NeoScrypt, and there is also a version being developed purely for the new generation of Maxwell GPUs (GTX 900-series) which does include info like what you're looking for (fans, temps, etc.). There is also a supplemental app, called SplitScreen, which works with existing versions of ccMiner and includes all that extra info, but sadly it isn't compatible with MinerControl.

Splitscreen is fine as long as you use the "usewindow" option.

jjjordan

sr. member

Activity: 271

Merit: 251

Quote from: Travis9x on November 13, 2014, 01:36:39 PM

Quote from: jjjordan on November 13, 2014, 10:32:50 AM

Are you aware if there is a specific sgminer build for nvidia, and is it only used for neoscrypt or all algorithms?

All versions of CG/SG miner were designed with AMD in mind. In fact, as StuffOfInterest pointed out, CGminer doesn't even work with NVIDIA GPUs at all. Fortunately, I believe someone is working on a ccMiner for NeoScrypt, and there is also a version being developed purely for the new generation of Maxwell GPUs (GTX 900-series) which does include info like what you're looking for (fans, temps, etc.). There is also a supplemental app, called SplitScreen, which works with existing versions of ccMiner and includes all that extra info, but sadly it isn't compatible with MinerControl.

Thank you Travis,
I hope there will be an interactive miner soon. (not just start it or kill it)

StuffOfInterest

sr. member

Activity: 401

Merit: 250

Just released version 1.5.4. This version introduces a "-m" command line option to minimize the application on startup. You can combine this with other options so "-m -a" will start minimized and auto-start mining. Also includes a fix for the slow exit if remote receive is active.

Travis9x

full member

Activity: 170

Merit: 100

Quote from: jjjordan on November 13, 2014, 10:32:50 AM

Are you aware if there is a specific sgminer build for nvidia, and is it only used for neoscrypt or all algorithms?

All versions of CG/SG miner were designed with AMD in mind. In fact, as StuffOfInterest pointed out, CGminer doesn't even work with NVIDIA GPUs at all. Fortunately, I believe someone is working on a ccMiner for NeoScrypt, and there is also a version being developed purely for the new generation of Maxwell GPUs (GTX 900-series) which does include info like what you're looking for (fans, temps, etc.). There is also a supplemental app, called SplitScreen, which works with existing versions of ccMiner and includes all that extra info, but sadly it isn't compatible with MinerControl.

StuffOfInterest

sr. member

Activity: 401

Merit: 250

Quote from: Joe9 on November 13, 2014, 11:44:31 AM

Quote from: StuffOfInterest on November 13, 2014, 06:34:31 AM

Quote from: Travis9x on November 13, 2014, 03:08:11 AM

Quote from: Joltheadq on November 12, 2014, 08:36:13 PM

Am I the only one having to close out MC with Task Manager? Huh

It won't close otherwise. Even after mining has been stopped.

I only had this issue a while back, with CudaMiner (not ccMiner), and that was several releases ago, shortly after console integration. Haven't had the issue since then.

Quote from: jjjordan on November 12, 2014, 09:00:07 PM

I haven't checked in a while and just saw manual configuration and failovers are now implemented.
Great job! Will start looking into it now.

I see some people are using cgminer/sgminer based nvidia miners.
Can you tell me how to find these? I've been looking for a while, but no luck.
I would really love the APIs that sgminer offers.

As far as I'm aware, the only reason anyone is using SGminer is either because they have AMD cards, or because they're mining neoScrypt (there is no ccMiner or any other NVIDIA-specific miner for neoScrypt yet).

For sgminer, you need to use the usewindow/true option on the config line. Otherwise, sgminer gets really confused with the console mode. There is a text only option in sgminer which should make it compatible but it doesn't seem to work right for me.

Have you tried cgminer 3.7.7b for neoscrypt on Nvidia gpu? I got it up and running but only 100% rejects.

cgminer doesn't work with nVIDIA. Tried it and had the same problem you are seeing. You need to use sgminer. The one I'm using I downloaded from cryptomining blog.

StuffOfInterest

sr. member

Activity: 401

Merit: 250

Quote from: jjjordan on November 13, 2014, 10:32:50 AM

Quote from: StuffOfInterest on November 13, 2014, 06:34:31 AM

Quote from: Travis9x on November 13, 2014, 03:08:11 AM

Quote from: Joltheadq on November 12, 2014, 08:36:13 PM

Am I the only one having to close out MC with Task Manager? Huh

It won't close otherwise. Even after mining has been stopped.

I only had this issue a while back, with CudaMiner (not ccMiner), and that was several releases ago, shortly after console integration. Haven't had the issue since then.

Quote from: jjjordan on November 12, 2014, 09:00:07 PM

I haven't checked in a while and just saw manual configuration and failovers are now implemented.
Great job! Will start looking into it now.

I see some people are using cgminer/sgminer based nvidia miners.
Can you tell me how to find these? I've been looking for a while, but no luck.
I would really love the APIs that sgminer offers.

As far as I'm aware, the only reason anyone is using SGminer is either because they have AMD cards, or because they're mining neoScrypt (there is no ccMiner or any other NVIDIA-specific miner for neoScrypt yet).

For sgminer, you need to use the usewindow/true option on the config line. Otherwise, sgminer gets really confused with the console mode. There is a text only option in sgminer which should make it compatible but it doesn't seem to work right for me.

Are you aware if there is a specific sgminer build for nvidia, and is it only used for neoscrypt or all algorithms?

About the failover - Is there a failover only mode (prioritized pool list) or is it only profit based mode?
I know for the failover mode workaround - using algo weights and so on, but it's very annoying if you have 10-15 pools or so.
So clean failover mode would be great - "disabling" profit switching and using pools based on a priority list.

There is a section for configuring manual pools. This works in conjunction with having the miners exit if unable to connect (which flags them as dead) to fall back to less and less profitable services. See the first post in the thread for how to configure.

Joe9

newbie

Activity: 24

Merit: 0

Quote from: StuffOfInterest on November 13, 2014, 06:34:31 AM

Quote from: Travis9x on November 13, 2014, 03:08:11 AM

Quote from: Joltheadq on November 12, 2014, 08:36:13 PM

Am I the only one having to close out MC with Task Manager? Huh

It won't close otherwise. Even after mining has been stopped.

I only had this issue a while back, with CudaMiner (not ccMiner), and that was several releases ago, shortly after console integration. Haven't had the issue since then.

Quote from: jjjordan on November 12, 2014, 09:00:07 PM

I haven't checked in a while and just saw manual configuration and failovers are now implemented.
Great job! Will start looking into it now.

I see some people are using cgminer/sgminer based nvidia miners.
Can you tell me how to find these? I've been looking for a while, but no luck.
I would really love the APIs that sgminer offers.

As far as I'm aware, the only reason anyone is using SGminer is either because they have AMD cards, or because they're mining neoScrypt (there is no ccMiner or any other NVIDIA-specific miner for neoScrypt yet).

For sgminer, you need to use the usewindow/true option on the config line. Otherwise, sgminer gets really confused with the console mode. There is a text only option in sgminer which should make it compatible but it doesn't seem to work right for me.

Have you tried cgminer 3.7.7b for neoscrypt on Nvidia gpu? I got it up and running but only 100% rejects.

jjjordan

sr. member

Activity: 271

Merit: 251

Quote from: StuffOfInterest on November 13, 2014, 06:34:31 AM

Quote from: Travis9x on November 13, 2014, 03:08:11 AM

Quote from: Joltheadq on November 12, 2014, 08:36:13 PM

Am I the only one having to close out MC with Task Manager? Huh

It won't close otherwise. Even after mining has been stopped.

I only had this issue a while back, with CudaMiner (not ccMiner), and that was several releases ago, shortly after console integration. Haven't had the issue since then.

Quote from: jjjordan on November 12, 2014, 09:00:07 PM

I haven't checked in a while and just saw manual configuration and failovers are now implemented.
Great job! Will start looking into it now.

I see some people are using cgminer/sgminer based nvidia miners.
Can you tell me how to find these? I've been looking for a while, but no luck.
I would really love the APIs that sgminer offers.

As far as I'm aware, the only reason anyone is using SGminer is either because they have AMD cards, or because they're mining neoScrypt (there is no ccMiner or any other NVIDIA-specific miner for neoScrypt yet).

For sgminer, you need to use the usewindow/true option on the config line. Otherwise, sgminer gets really confused with the console mode. There is a text only option in sgminer which should make it compatible but it doesn't seem to work right for me.

Are you aware if there is a specific sgminer build for nvidia, and is it only used for neoscrypt or all algorithms?

About the failover - Is there a failover only mode (prioritized pool list) or is it only profit based mode?
I know for the failover mode workaround - using algo weights and so on, but it's very annoying if you have 10-15 pools or so.
So clean failover mode would be great - "disabling" profit switching and using pools based on a priority list.

Topic: [ANN] Miner Control 1.6.1 - Auto profit switching miner controller - page 43. (Read 164300 times)