I can't get "minprofit" to change anything on Kbomba 1.6.4. I can input any number without effect on mining. Is it not supposed to stop mining if net price does not meet threshold?
i.e. I want my miners idle unless the pools net profit is .006 BTC and above.
Topic: [ANN] Miner Control 1.6.1 - Auto profit switching miner controller - page 32. (Read 164304 times)
April 06, 2015, 05:43:06 PM
March 25, 2015, 04:11:25 PM
Okay I was able to see the same error.
Here is the config I used.
This is the steps I followed to have it happen.
Steps to Recreate error
Wait the 30 minutes to see the restart stay at 0:00:00 or see it not change to a pending with Switch at 0:00:00
Here is the config I used.
Code:
{
"general": {
"power": 0.00001,
"exchange": 222,
"currencycode": "USD",
"minprice": "-1.0BTC",
"mintime": 2,
"maxtime": 30,
"switchtime": 5,
"delay": 1,
"exittime": 0,
"deadtime": 10,
"statwindow": 60,
"minprofit": 1.01,
"minebyaverage": false,
"dynamicswitching": true,
"dynamicswitchpower": 2,
"ignoreoutliers": true,
"iqrmultiplier": 2.2,
"logerrors": true,
"logactivity": true,
"gridsortmode": 1,
"minerkillmode": 1,
"traymode": 1,
"donationpercentage": 2,
"donationfrequency": 240,
"remotesend": true,
"remotereceive": false
},
"algorithms": [
{ "name": "x11", display: "X11", "hashrate": 18985, "power": 49, "aparam1": "ccminer.exe", "aparam2": "-a x11" },
{ "name": "x13", display: "X13", "hashrate": 14935, "power": 49, "aparam1": "ccminer.exe", "aparam2": "-a x13" },
{ "name": "x14", display: "X14", "hashrate": 14596, "power": 49, "aparam1": "ccminer.exe", "aparam2": "-a x14" },
{ "name": "x15", display: "X15", "hashrate": 12961, "power": 52, "aparam1": "ccminer.exe", "aparam2": "-a x15" },
{ "name": "nist5", display: "Nist5", "hashrate": 51660, "power": 54, "aparam1": "ccminer.exe", "aparam2": "-a nist5 -i 19" },
{ "name": "scrypt", display: "Scrypt", "hashrate": 1700, "power": 60, "aparam1": "cudaminer.exe", "aparam2": "-a scrypt -i 0 -l T15x12 -H 2" },
{ "name": "scryptn", display: "Scrypt-N", "hashrate": 300, "power": 60, "aparam1": "cudaminer.exe", "aparam2": "-a scrypt:2048 -i 0 -l T5x12 -H 2" },
{ "name": "keccak", display: "Keccak", "hashrate": 762090, "power": 50, "aparam1": "ccminer.exe", "aparam2": "-a keccak" },
{ "name": "sha256", display: "SHA256", "hashrate": 0, "power": 50, "aparam1": "cudaminer.exe", "aparam2": "-a sha256 -batch" },
{ "name": "neoscrypt", display: "NeoScrypt", "hashrate": 930, "power": 50, "aparam1": "cmd.exe", "aparam2": "/c ccminer.exe -a neoscrypt -batch" },
{ "name": "qubit", display: "Qubit", "hashrate": 29000, "power": 50, "aparam1": "", "aparam2": "-a qubit", "aparam3": "" },
{ "name": "quark", display: "Quark", "hashrate": 36555, "power": 54, "aparam1": "", "aparam2": "-a quark", "aparam3": "" },
{ "name": "whirlpoolx", "display": "WhirlpoolX", "hashrate": 455600, "power": 50, "aparam1": "", "aparam2": "ccminer.exe", "aparam3": "-a whirlpoolx" },
{ "name": "fresh", display: "Fresh", "hashrate": 21400, "power": 2, "aparam1": "", "aparam2": "sgminer.exe", "aparam3": "-a fresh" },
{ "name": "lyra2", display: "Lyra2RE", "hashrate": 4266, "power": 50, "aparam1": "C:\\cudaminer\\ccminer", "aparam2": "ccminer.exe", "aparam3": "-a lyra2" }
],
"nicehash": {
"account": "",
"worker": "2",
"sparam1": "-o stratum+tcp://stratum.nicehash.com",
"sparam2": "-p x",
"weight": 0.94,
"algos": [
{ "algo": "x11", "folder": "", "command": "ccminer.exe", "arguments": "_APARAM2_ _SPARAM1_:3336 -u _ACCOUNT_._WORKER_ _SPARAM2_ --cpu-priority 3" },
{ "algo": "x13", "folder": "", "command": "ccminer.exe", "arguments": "_APARAM2_ _SPARAM1_:3337 -u _ACCOUNT_._WORKER_ -p d=0.008 --cpu-priority 3" },
{ "algo": "x15", "folder": "", "command": "ccminer.exe", "arguments": "_APARAM2_ _SPARAM1_:3339 -u _ACCOUNT_._WORKER_ _SPARAM2_ --cpu-priority 3" },
{ "algo": "nist5", "folder": "", "command": "ccminer.exe", "arguments": "_APARAM2_ _SPARAM1_:3340 -u _ACCOUNT_._WORKER_ _SPARAM2_" },
{ "algo": "scrypt", "folder": "", "command": "_APARAM1_", "arguments": "_APARAM2_ _SPARAM1_:3333 -u -u _ACCOUNT_._WORKER_ -p d=256" },
{ "algo": "scryptn", "folder": "", "command": "_APARAM1_", "arguments": "_APARAM2_ _SPARAM1_:3335 -u _ACCOUNT_._WORKER_ -p d=32" },
{ "algo": "keccak", "folder": "", "command": "_APARAM1_", "arguments": "_APARAM2_ _SPARAM1_:3338 -u _ACCOUNT_._WORKER_ -p d=3713" },
{ "algo": "whirlpoolx", "priceid": "10", "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:3343 -u _ACCOUNT_._WORKER_ -p d=0.04" },
{ "algo": "neoscrypt", "folder": "C:\\cudaminer\\neoscrypt\\lyra3", "command": "ccminer.exe", "arguments": "-a neoscrypt _SPARAM1_:3341 -u _ACCOUNT_ _SPARAM2_ --throughput 1" },
{ "algo": "lyra2", "priceid": "9", "folder": "", "command": "ccminer.exe", "arguments": "_APARAM3_ _SPARAM1_:3342 -u _ACCOUNT_._WORKER_ _SPARAM2_" },
{ "algo": "qubit", "priceid": "11", "folder": "", "command": "ccminer.exe", "arguments": " _APARAM2_ _SPARAM1_:3344 -u _ACCOUNT_._WORKER_ _SPARAM2_" }
]
},
"westhash": {
"account": "",
"worker": "2",
"weight": 0.95,
"sparam1": "-o stratum+tcp://stratum.westhash.com",
"sparam2": "-p x",
"algos": [
{ "algo": "x11", "folder": "", "command": "ccminer.exe", "arguments": "_APARAM2_ _SPARAM1_:3336 -u _ACCOUNT_._WORKER_ _SPARAM2_ --cpu-priority 3" },
{ "algo": "x13", "folder": "", "command": "ccminer.exe", "arguments": "_APARAM2_ _SPARAM1_:3337 -u _ACCOUNT_._WORKER_ _SPARAM2_ --cpu-priority 3" },
{ "algo": "x15", "folder": "", "command": "ccminer.exe", "arguments": "_APARAM2_ _SPARAM1_:3339 -u _ACCOUNT_._WORKER_ _SPARAM2_ --cpu-priority 3" },
{ "algo": "nist5", "folder": "", "command": "ccminer.exe", "arguments": "_APARAM2_ _SPARAM1_:3340 -u _ACCOUNT_._WORKER_ _SPARAM2_" },
{ "algo": "scrypt", "folder": "C:\\cudaminer\\cudaminer-2014-02-28\\x86", "command": "_APARAM1_", "arguments": "_APARAM2_ _SPARAM1_:3333 -u -u _ACCOUNT_._WORKER_ -p d=256" },
{ "algo": "scryptn", "folder": "C:\\cudaminer\\vert", "command": "_APARAM1_", "arguments": "_APARAM2_ _SPARAM1_:3335 -u _ACCOUNT_._WORKER_ -p d=128" },
{ "algo": "keccak", "folder": "", "command": "_APARAM1_", "arguments": "_APARAM2_ _SPARAM1_:3338 -u _ACCOUNT_._WORKER_ -p d=8192" },
{ "algo": "neoscrypt", "folder": "C:\\cudaminer\\neoscrypt\\lyra3", "command": "ccminer.exe", "arguments": "-a neoscrypt _SPARAM1_:3341 -u _ACCOUNT_ _SPARAM2_ --throughput 1" },
{ "algo": "lyra2", "priceid": "9", "folder": "", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:3342 -u _ACCOUNT_._WORKER_ _SPARAM2_" },
{ "algo": "whirlpoolx", "priceid": "10", "folder": "_APARAM1_", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:3343 -u _ACCOUNT_._WORKER_ -p d=0.04" },
{ "algo": "qubit", "priceid": "11", "folder": "", "command": "ccminer.exe", "arguments": " _APARAM2_ _SPARAM1_:3344 -u _ACCOUNT_._WORKER_ -p d=0.01" }
]
},
"yaamp": {
"account": "",
"pricemode": 1,
"balancemode": 0,
"worker": "2",
"sparam1": "-o stratum+tcp://yaamp.com",
"sparam2": "-p 2",
"algos": [
{ "algo": "x11", "folder": "", "command": "ccminer.exe", "arguments": "_APARAM2_ _SPARAM1_:3533 -u _ACCOUNT_ _SPARAM2_ --cpu-priority 3" },
{ "algo": "x13", "folder": "", "command": "ccminer.exe", "arguments": "_APARAM2_ _SPARAM1_:3633 -u _ACCOUNT_ _SPARAM2_ --cpu-priority 3" },
{ "algo": "x14", "folder": "", "command": "ccminer.exe", "arguments": "_APARAM2_ _SPARAM1_:3933 -u _ACCOUNT_ _SPARAM2_ --cpu-priority 3" },
{ "algo": "x15", "folder": "", "command": "ccminer.exe", "arguments": "_APARAM2_ _SPARAM1_:3733 -u _ACCOUNT_ _SPARAM2_ --cpu-priority 3" },
{ "algo": "quark", "folder": "", "command": "ccminer.exe", "arguments": "_APARAM2_ _SPARAM1_:4033 -u _ACCOUNT_ _SPARAM2_ --cpu-priority 2" },
{ "algo": "fresh", "folder": "_APARAM1_", "command": "ccminer.exe", "arguments": "_APARAM3_ _SPARAM1_:4133 -u _ACCOUNT_ _SPARAM2_"},
{ "algo": "lyra2", "priceid": "lyra2", "folder": "", "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:4433 -u _ACCOUNT_._WORKER_ _SPARAM2_" },
{ "algo": "qubit", "priceid": "qubit", "folder": "", "command": "ccminer.exe", "arguments": "_APARAM2_ _SPARAM1_:4733 -u _ACCOUNT_._WORKER_ _SPARAM2_ --cpu-priority 3" },
{ "algo": "neoscrypt", "folder": "C:\\cudaminer\\neoscrypt\\lyra3", "command": "ccminer.exe", "arguments": "-a neoscrypt _SPARAM1_:4233 -u _ACCOUNT_ _SPARAM2_ --throughput 1"}
]
},
"ltcrabbit": {
"apikey": "",
"account": "frazier345",
"worker": "2",
"sparam2": "-p x --cpu-priority 3",
"algos": [
{ "algo": "x11", "folder": "", "command": "ccminer.exe", "arguments": "_APARAM2_ -o stratum+tcp://x11.ltcrabbit.com:3332 -u _ACCOUNT_._WORKER_ _SPARAM2_" }
]
}
}
This is the steps I followed to have it happen.
Steps to Recreate error
- Start MC
- Sort by Algo
- Open MC.conf file
- Start Manually start First Algo (One in each algo not each pool) and run for about a minute
- Adjust the speeds in the .conf file
- Stop algo
- repeat for all algos that are showing higher than 0.000000
- Save .conf and keep it open.
- click reload button
- click auto button
Wait the 30 minutes to see the restart stay at 0:00:00 or see it not change to a pending with Switch at 0:00:00
March 24, 2015, 12:40:03 PM
Is someone else noticing switching problems in latest Kbomba version? After a while the switching just stops and it gets reset when "maxtime" hit's. I've tried with and without dynamic switching.
It happens on all miners all running win 8.1. with original miner I didn't had this problems.
Example:
It happens on all miners all running win 8.1. with original miner I didn't had this problems.
Example:
I've been trying your conf and other combos, and only found (and fixed
) another bug 
Can't recreate yours. Can I get your complete .conf? March 23, 2015, 05:01:24 PM
Is someone else noticing switching problems in latest Kbomba version? After a while the switching just stops and it gets reset when "maxtime" hit's. I've tried with and without dynamic switching.
It happens on all miners all running win 8.1. with original miner I didn't had this problems.
My config:
It happens on all miners all running win 8.1. with original miner I didn't had this problems.
My config:
Code:
"power": 0.10,
I have not noticed that at all, I am running Windows 8.1 Professional.
March 23, 2015, 07:22:21 AM
Is someone else noticing switching problems in latest Kbomba version? After a while the switching just stops and it gets reset when "maxtime" hit's. I've tried with and without dynamic switching.
It happens on all miners all running win 8.1. with original miner I didn't had this problems.
My config:
Example:
It happens on all miners all running win 8.1. with original miner I didn't had this problems.
My config:
Code:
"power": 0.10,
"exchange": 500,
"mintime": 2,
"maxtime": 60,
"switchtime": 3,
"deadtime": 10,
"delay": 2,
"exittime": 0,
"statwindow": 30,
"minprice":"-35.0BTC",
"minebyaverage": false,
"dynamicswitching": false,
"dynamicswitchpower": 2,
"dynamicswitchpivot": 1.05,
"ignoreoutliers": false,
"iqrmultiplier": 2.2,
"logerrors": false,
"logactivity": false,
"gridsortmode": 2,
"minerkillmode": 1,
"traymode": 1,
"currencycode": "EUR",
"donationpercentage": 2,
"donationfrequency": 240,
"remotesend": true,
"remotereceive": true
Example:
March 19, 2015, 08:37:52 PM
anyone wants to share their full working config for 750ti?
They have a package for the 750ti here on Crypto Mining Blog
March 18, 2015, 05:57:31 AM
What should I code if I still want to mine when all algo has -ve Net(profit) ? TQ.
Cheaper power
Set your "power" to a lower number or just zero.
Otherwise, you could set "minprice" to a negative number if you want to keep on mining, but not if it gets too extreme.
Let say I want to mine until the lowest Net is -0.000100, how to set "minprice". TQ.
(I tried "minprice": -100000, but all still show Too low and not mining and lowest Net was -0.000054 when I tried to set from -1 to -10000).
Found and fix'd the bug
https://mega.co.nz/#!wBUy2LTb!0i2Q3KLoL1CbqOxIYFFqW8XAYFeMeyXPJQa_0uPoIbwBy using just a number there, MC will think you're inputting it as fiat and convert that minprice to BTC. Put quotation marks " " around the minprice and add BTC to set price in BTC, like this: "minprice":"-0.01BTC",
Don't look at that history tab! I tell you not to
J/k March 18, 2015, 04:00:24 AM
anyone wants to share their full working config for 750ti?
March 18, 2015, 01:15:37 AM
What should I code if I still want to mine when all algo has -ve Net(profit) ? TQ.
Cheaper power
Set your "power" to a lower number or just zero.
Otherwise, you could set "minprice" to a negative number if you want to keep on mining, but not if it gets too extreme.
Let say I want to mine until the lowest Net is -0.000100, how to set "minprice". TQ.
(I tried "minprice": -100000, but all still show Too low and not mining and lowest Net was -0.000054 when I tried to set from -1 to -10000).
Found and fix'd the bug
https://mega.co.nz/#!wBUy2LTb!0i2Q3KLoL1CbqOxIYFFqW8XAYFeMeyXPJQa_0uPoIbwBy using just a number there, MC will think you're inputting it as fiat and convert that minprice to BTC. Put quotation marks " " around the minprice and add BTC to set price in BTC, like this: "minprice":"-0.01BTC",
Don't look at that history tab! I tell you not to
J/k March 18, 2015, 12:34:27 AM
What should I code if I still want to mine when all algo has -ve Net(profit) ? TQ.
Cheaper power
Set your "power" to a lower number or just zero.
Otherwise, you could set "minprice" to a negative number if you want to keep on mining, but not if it gets too extreme.
Let say I want to mine until the lowest Net is -0.000100, how to set "minprice". TQ.
(I tried "minprice": -100000, but all still show Too low and not mining and lowest Net was -0.000054 when I tried to set from -1 to -10000).
March 18, 2015, 12:06:07 AM
What should I code if I still want to mine when all algo has -ve Net(profit) ? TQ.
Cheaper power
Set your "power" to a lower number or just zero.
Otherwise, you could set "minprice" to a negative number if you want to keep on mining, but not if it gets too extreme.
March 17, 2015, 11:47:45 PM
What should I code if I still want to mine when all algo has -ve Net(profit) ? TQ.
March 17, 2015, 10:29:18 PM
MRR doesn't have a concept of "list one rig with different algos".
To them you have separate rig for each algo. So no.
You have to monitor and turn your rig/rigs on/off accordingly.
Gotcha, thanks.
March 17, 2015, 10:18:29 PM
Bombadil, the most mysterious and possibly nefarious of all of Tolkien's characters...
I asked this question to StuffOfInterest earlier in this thread, and I ask you again now
Is it at all possible to develop this app further to tie into rental websites like MiningRigRentals.com to talk to their API, and be able to:
1. Move the MRR pool to the top when rented
2. On MRR's GUI, Deactivate non-rented rigs that are actually the same computer on MRR so as to disallow a conflict of miners.
i.e. I have 60 mhs rig for x11 but also list a 50 mhs rig for x13 on MRR. They are both actually the same computer. When one is rented, the other non-rented rig must be listed as "unavailable" in order to ensure there is no conflict of renters. This eventually could also be used on other rental websites
I understand this is not really what MRR was built to do, as StuffOfInterest has informed me, but this would give a lot of flexibility to miners by allowing a setup option that mines the most profitable option, while allowing for multiple rental options on various algorithms potentially on a number of rental platforms all with a quick setup and no (to little) maintenance.
I'm sure I'm not alone in donating to this development
I asked this question to StuffOfInterest earlier in this thread, and I ask you again now
Is it at all possible to develop this app further to tie into rental websites like MiningRigRentals.com to talk to their API, and be able to:
1. Move the MRR pool to the top when rented
2. On MRR's GUI, Deactivate non-rented rigs that are actually the same computer on MRR so as to disallow a conflict of miners.
i.e. I have 60 mhs rig for x11 but also list a 50 mhs rig for x13 on MRR. They are both actually the same computer. When one is rented, the other non-rented rig must be listed as "unavailable" in order to ensure there is no conflict of renters. This eventually could also be used on other rental websites
I understand this is not really what MRR was built to do, as StuffOfInterest has informed me, but this would give a lot of flexibility to miners by allowing a setup option that mines the most profitable option, while allowing for multiple rental options on various algorithms potentially on a number of rental platforms all with a quick setup and no (to little) maintenance.
I'm sure I'm not alone in donating to this development
Does MRR automatically handle the rig being listed as unavailable for x13 if it is rented out for x11?
Looks like we'll be able to add another multipool soon, Mintsy
https://bitcointalksearch.org/topic/m.10776865
MinerControl is not MRR compatible for the following reasons:
*)Not updating MRR status through API!
*)Not having failover mode - priority/availability based one
I know it's not, at least now. I was just wanting to know if MRR lists his rig as unavailable for x13 if it is rented out for x11. Or if he has to manually list his rig as offline for x13. I've never used MRR so just wondering.
MRR doesn't have a concept of "list one rig with different algos".
To them you have separate rig for each algo. So no.
You have to monitor and turn your rig/rigs on/off accordingly.
March 17, 2015, 10:10:28 PM
Bombadil, the most mysterious and possibly nefarious of all of Tolkien's characters...
I asked this question to StuffOfInterest earlier in this thread, and I ask you again now
Is it at all possible to develop this app further to tie into rental websites like MiningRigRentals.com to talk to their API, and be able to:
1. Move the MRR pool to the top when rented
2. On MRR's GUI, Deactivate non-rented rigs that are actually the same computer on MRR so as to disallow a conflict of miners.
i.e. I have 60 mhs rig for x11 but also list a 50 mhs rig for x13 on MRR. They are both actually the same computer. When one is rented, the other non-rented rig must be listed as "unavailable" in order to ensure there is no conflict of renters. This eventually could also be used on other rental websites
I understand this is not really what MRR was built to do, as StuffOfInterest has informed me, but this would give a lot of flexibility to miners by allowing a setup option that mines the most profitable option, while allowing for multiple rental options on various algorithms potentially on a number of rental platforms all with a quick setup and no (to little) maintenance.
I'm sure I'm not alone in donating to this development
I asked this question to StuffOfInterest earlier in this thread, and I ask you again now
Is it at all possible to develop this app further to tie into rental websites like MiningRigRentals.com to talk to their API, and be able to:
1. Move the MRR pool to the top when rented
2. On MRR's GUI, Deactivate non-rented rigs that are actually the same computer on MRR so as to disallow a conflict of miners.
i.e. I have 60 mhs rig for x11 but also list a 50 mhs rig for x13 on MRR. They are both actually the same computer. When one is rented, the other non-rented rig must be listed as "unavailable" in order to ensure there is no conflict of renters. This eventually could also be used on other rental websites
I understand this is not really what MRR was built to do, as StuffOfInterest has informed me, but this would give a lot of flexibility to miners by allowing a setup option that mines the most profitable option, while allowing for multiple rental options on various algorithms potentially on a number of rental platforms all with a quick setup and no (to little) maintenance.
I'm sure I'm not alone in donating to this development
Does MRR automatically handle the rig being listed as unavailable for x13 if it is rented out for x11?
Looks like we'll be able to add another multipool soon, Mintsy
https://bitcointalksearch.org/topic/m.10776865
MinerControl is not MRR compatible for the following reasons:
*)Not updating MRR status through API!
*)Not having failover mode - priority/availability based one
I know it's not, at least now. I was just wanting to know if MRR lists his rig as unavailable for x13 if it is rented out for x11. Or if he has to manually list his rig as offline for x13. I've never used MRR so just wondering.
March 17, 2015, 10:01:04 PM
Bombadil, the most mysterious and possibly nefarious of all of Tolkien's characters...
I asked this question to StuffOfInterest earlier in this thread, and I ask you again now
Is it at all possible to develop this app further to tie into rental websites like MiningRigRentals.com to talk to their API, and be able to:
1. Move the MRR pool to the top when rented
2. On MRR's GUI, Deactivate non-rented rigs that are actually the same computer on MRR so as to disallow a conflict of miners.
i.e. I have 60 mhs rig for x11 but also list a 50 mhs rig for x13 on MRR. They are both actually the same computer. When one is rented, the other non-rented rig must be listed as "unavailable" in order to ensure there is no conflict of renters. This eventually could also be used on other rental websites
I understand this is not really what MRR was built to do, as StuffOfInterest has informed me, but this would give a lot of flexibility to miners by allowing a setup option that mines the most profitable option, while allowing for multiple rental options on various algorithms potentially on a number of rental platforms all with a quick setup and no (to little) maintenance.
I'm sure I'm not alone in donating to this development
I asked this question to StuffOfInterest earlier in this thread, and I ask you again now
Is it at all possible to develop this app further to tie into rental websites like MiningRigRentals.com to talk to their API, and be able to:
1. Move the MRR pool to the top when rented
2. On MRR's GUI, Deactivate non-rented rigs that are actually the same computer on MRR so as to disallow a conflict of miners.
i.e. I have 60 mhs rig for x11 but also list a 50 mhs rig for x13 on MRR. They are both actually the same computer. When one is rented, the other non-rented rig must be listed as "unavailable" in order to ensure there is no conflict of renters. This eventually could also be used on other rental websites
I understand this is not really what MRR was built to do, as StuffOfInterest has informed me, but this would give a lot of flexibility to miners by allowing a setup option that mines the most profitable option, while allowing for multiple rental options on various algorithms potentially on a number of rental platforms all with a quick setup and no (to little) maintenance.
I'm sure I'm not alone in donating to this development
Does MRR automatically handle the rig being listed as unavailable for x13 if it is rented out for x11?
Looks like we'll be able to add another multipool soon, Mintsy
https://bitcointalksearch.org/topic/m.10776865
MinerControl is not MRR compatible for the following reasons:
*)Not updating MRR status through API!
*)Not having failover mode - priority/availability based one
March 17, 2015, 09:49:43 PM
Bombadil, the most mysterious and possibly nefarious of all of Tolkien's characters...
I asked this question to StuffOfInterest earlier in this thread, and I ask you again now
Is it at all possible to develop this app further to tie into rental websites like MiningRigRentals.com to talk to their API, and be able to:
1. Move the MRR pool to the top when rented
2. On MRR's GUI, Deactivate non-rented rigs that are actually the same computer on MRR so as to disallow a conflict of miners.
i.e. I have 60 mhs rig for x11 but also list a 50 mhs rig for x13 on MRR. They are both actually the same computer. When one is rented, the other non-rented rig must be listed as "unavailable" in order to ensure there is no conflict of renters. This eventually could also be used on other rental websites
I understand this is not really what MRR was built to do, as StuffOfInterest has informed me, but this would give a lot of flexibility to miners by allowing a setup option that mines the most profitable option, while allowing for multiple rental options on various algorithms potentially on a number of rental platforms all with a quick setup and no (to little) maintenance.
I'm sure I'm not alone in donating to this development
I asked this question to StuffOfInterest earlier in this thread, and I ask you again now
Is it at all possible to develop this app further to tie into rental websites like MiningRigRentals.com to talk to their API, and be able to:
1. Move the MRR pool to the top when rented
2. On MRR's GUI, Deactivate non-rented rigs that are actually the same computer on MRR so as to disallow a conflict of miners.
i.e. I have 60 mhs rig for x11 but also list a 50 mhs rig for x13 on MRR. They are both actually the same computer. When one is rented, the other non-rented rig must be listed as "unavailable" in order to ensure there is no conflict of renters. This eventually could also be used on other rental websites
I understand this is not really what MRR was built to do, as StuffOfInterest has informed me, but this would give a lot of flexibility to miners by allowing a setup option that mines the most profitable option, while allowing for multiple rental options on various algorithms potentially on a number of rental platforms all with a quick setup and no (to little) maintenance.
I'm sure I'm not alone in donating to this development
Does MRR automatically handle the rig being listed as unavailable for x13 if it is rented out for x11?
Looks like we'll be able to add another multipool soon, Mintsy
https://bitcointalksearch.org/topic/m.10776865
March 17, 2015, 01:07:51 PM
Seems like it is in demand ^^" Let me take a nap first, then I'll finish the basics of this history charting (don't like to leave something partially), afterwards I'll start on cracking MRR.
I'll probably need some testers, since I've never used MRR myself before. So get your ass on IRC, #MinerControl on freenode (Webirc for the lazy but beware that I'm probably asleep at this moment).
I'll probably need some testers, since I've never used MRR myself before. So get your ass on IRC, #MinerControl on freenode (Webirc for the lazy
but beware that I'm probably asleep at this moment).I'm in IRC now. it's usually open in the background while I'm at school/day job/etc.
I am not sure how much work is entailed tbh, I just know jjjordan and I and others have been looking for a solution like this for a while.
March 16, 2015, 11:25:39 PM
Seems like it is in demand ^^" Let me take a nap first, then I'll finish the basics of this history charting (don't like to leave something partially), afterwards I'll start on cracking MRR.
I'll probably need some testers, since I've never used MRR myself before. So get your ass on IRC, #MinerControl on freenode (Webirc for the lazy but beware that I'm probably asleep at this moment).
I'll probably need some testers, since I've never used MRR myself before. So get your ass on IRC, #MinerControl on freenode (Webirc for the lazy
but beware that I'm probably asleep at this moment). March 16, 2015, 09:47:27 PM
Hey Bombadil, I am interested too.
You can take a look what I've posted earlier here
(https://bitcointalksearch.org/topic/m.9548628)
As far as using the MRR APIs to enable/disable the rental rigs I currently have a php script that does this.
It's not very elegant, but I am not a coder. Not even for hobby. Just the occasional script tweaking when necessary.
One thing I've noticed though - If I had the script running for long time (every minute for days/weeks etc)
it doesn't start right away if stopped. I have to either change the key or wait for some time (idk if that even worked).
So to put it short: the switching app has to be able to switch between failover and profit based mining based on
if there is a rented rig or not (and that picture again):
You can take a look what I've posted earlier here
(https://bitcointalksearch.org/topic/m.9548628)
As far as using the MRR APIs to enable/disable the rental rigs I currently have a php script that does this.
It's not very elegant, but I am not a coder. Not even for hobby. Just the occasional script tweaking when necessary.
One thing I've noticed though - If I had the script running for long time (every minute for days/weeks etc)
it doesn't start right away if stopped. I have to either change the key or wait for some time (idk if that even worked).
So to put it short: the switching app has to be able to switch between failover and profit based mining based on
if there is a rented rig or not (and that picture again):
Jump to: