bullshit, neither yiimp or zpool are configured to work like that, they are simply prop, so was original yaamp pool!
|
|
|
claymore implementation of a backup pool is retarded, so you are better w/o it... my observation on zec is that you don't need backup, I guess it's same for etherium for FTC, DGB, AUR check http://yiimp.ccminer.org/site/mining
|
|
|
well, use web interface to monitor or see api if it provides per worker status.
|
|
|
monero pool is junk, just scrap it if you allow only a single connection!
|
|
|
MC got caught on nicehash spike, then price went 0 and it never switched back
2017-05-03T11:57:25, Start, Automatic, NiceHash, keccak, , , hashrt:156375.00, tpavgsp:0.00, plfee:3.0 %, price:0.009900, earn:0.001548, fees:0.000046, power:50.0000, netearn:0.001502, avgearn:0.001505, balBTC:0.000000, servbal:0.003278, runtime:00:05:22
03.05.2017 г. 12:01:40 ч. ---------------------------------------------- Type: DivideByZeroException Message: Attempted to divide by zero. Stack trace: at System.Decimal.FCallDivide(Decimal& d1, Decimal& d2) at System.Decimal.op_Division(Decimal d1, Decimal d2) at MinerControl.MiningEngine.RunBestAlgo(Boolean isMinimizedToTray)
above repeated every second until I stopped it.
|
|
|
{ "name": "Equihash", "display": "Equihash", "hashrate": 74.8, "power": 0 }, . . . "manual": { "account": "myaccount", "algos": [ { "algo": "x11", "price": 0.00949, "fee": 0.0, "folder": "", "command": "", "arguments": "" }, { "algo": "Equihash", "price": 0.006039, "fee": 0.0, "folder": "folder": "D:\\data\\MinerControl165cuda\\eqm_v1.0.3b_Win64", "command": "eqm.exe", "arguments": "-l eu -t 0 -cd 0 -u 1BTC.. -w 750ti", "usewindow": true }, } ] }
from my previous config
|
|
|
use WTM format, so you get a price, old manual mode is by inputting your price in config.
edit: price would be zero if you haven't set hashrate for equihash as 0*8888=0
found a bug seems "maxtime": 120, will stop working at some point and restart is stuck @ 00:00:00.0 and no autoswitch, mining is stuck for 8 hours on same coin, same for beta 9+1 and 8+5
|
|
|
seems I was wrong for PlFee, adding those fees was a good approximation when fees are low, but exact formula is
PlFee=1-(1-coinfee/100)*(1-btcfee)
so for MPH it is 1,0982% that was close to the initial 1,1% and for zpool it is 3,96%
|
|
|
PlFee = coin fee * btc exchange fee, its not PlFee = coin fee + btc exchange fee, seen @ MPH config 1,8 <> 1,1, I guess same for yaamp/zpool as 2+2=2*2
why pascal@NH does not show anything besides zeroes on MC, api is fine {"paying":"0.00144741","port":3358,"name":"pascal","algo":25},
is it possible MC to launch miners with high priority and for those who use cpu mining to select affinity to which core(s).
|
|
|
Item 2 with disabling a coin. For the moment there is an options in config to set it enabled or permanently disabled via "active" key. If set to "false", coin will be skipped in MC. {"active": true, "algo": "x15", "folder": "_APARAM1_", "cweight": 1, "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:3733 -u _ACCOUNT_ _SPARAM2_" }, {"active": false, "algo": "quark", "folder": "_APARAM1_", "cweight": 1, "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:4033 -u _ACCOUNT_ _SPARAM2_" }, From your experience, this banning of the whole pool by double-clicking, is it practically usefull? I can rewrite it so, that it will ban only the current line with particular coin, because check-boxes will add more complexity to the code. I want to see the data(price, net, average, etc) and MC to exclude that coin from mining, setting "active" to false removes data and the coin from the list as it was deleted.
|
|
|
Item 2 with disabling a coin. For the moment there is an options in config to set it enabled or permanently disabled via "active" key. If set to "false", coin will be skipped in MC. {"active": true, "algo": "x15", "folder": "_APARAM1_", "cweight": 1, "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:3733 -u _ACCOUNT_ _SPARAM2_" }, {"active": false, "algo": "quark", "folder": "_APARAM1_", "cweight": 1, "command": "_APARAM2_", "arguments": "_APARAM3_ _SPARAM1_:4033 -u _ACCOUNT_ _SPARAM2_" }, From your experience, this banning of the whole pool by double-clicking, is it practically usefull? I can rewrite it so, that it will ban only the current line with particular coin, because check-boxes will add more complexity to the code. on certain situation it's useful - connection problems, lots of rejects, monitoring a coin/pool, changing one pool for another. is it possible, one instance of MC to pull api and send that info on the local network to feed another instances on MC, seems that with just 2 instances of MC some pools started to feed me with blank responses.
|
|
|
I'm trying to sort by clicking on top of columns but it quickly restores default sorting by net (profit) gridsortmode is 2, also towards bottom of coins all lines(mostly where there 0 khs in config or with blank api) move arround too quickly and cannot be read, can you delay that way of sorting like at least 60 seconds apart
can you add in front of each coin a checkbox where you can temp suspend switching to it for some reason, MC can disable a pool by double clicking on its name but suspending a coin can be useful in certain sutuation where either pool or exchanges feed you with false expectations also it's useful to evaluate a certain coin/pool before you add it to your config.
can you add minebyaverage on certain coin like that "multi" stuff for yiimp, it would add more options mining coins where difficulty changes faster than you can jump in and jump out and won't harm you when using current estimate for the rest of coins.
can we have a global config option: "usewindow": true, where miner window is not hidden in console tab.
whirlpool and whirlpoolx are different, 1st is on yiimp the other is on nicehash, wrong part is miners option for first "-a whirlpool", while displayname for 2nd should be "WhirlpoolX"
|
|
|
why yiimp pool is on 4% fee even with btcfee = 0, there are no extra fees except those from api, most are 2%
|
|
|
how to mine skein as two coins are on same port, if I give DGB address and AUR block is found will I get something from it or I am submitting shares only to DGB daemon and my rewards will be DGB only?
|
|
|
I have problem with monero, worker.2 works fine, for worker.1 pool gives me difficulty 200 000 and if I start worker.3, for some reason all workers start to lose connection
|
|
|
There is a door with lower difficulty for xmr? Type with 2500 down or up depending on the power of mining? Starts with WFT 200008 This is a lot to have a door with values up to 1000
you can start mining with difficulty hint from your side. Input "d=difficulty value" at your worker password and pool will set that difficulty value to your miner. e.g. ) d=2000 This is only suggestion from miner for starting difficulty. Not static. And it will be adjusted to appropriate difficulty value as time passes automatically. Currently pool supports minimum 2000 diff. As diff value criteria may different from miner programs each other, I am not sure we are talking with same diff level. Let me know your hashrate and desired diff after you try d=2000 diff. Actually diff value does not matter much in reality. Earnings are really similar if your miner is inserting shares regularly. example ./minerd -a cryptonight -o stratum+tcp://us-east.monero.miningpoolhub.com:20580 -u youlogin.workname -p x d=2000 ? on workers page - replace "x" with "d=2000" and use "-p d=2000"
|
|
|
just change multiports to proportional reward type and it will save you cpu cycles. single coin may stay pplns.
well, actually multiport pool redirects to single coin internally. They are not separate pool. I fixed and optimized some codes to speed up. I'll continually monitor them. And.. miningpoolhub was using PROP about 2 years ago. It's faster but little miners would have penalty at short block time coins. Thank you. it's not true, little miners can miss one round but they could score double on next "short" round, so it is even at the end. Well, it's proven from reality and theory some years ago. And miningpoolhub also found that PROP is not good. Block reward distribution at PROP is separated for each block round. For example, if a block is found within 1 second with one share, then he gets all 5 ETH. Is it fair that he gets all? Maybe, if his reward is lowered at next round. But he will get proportionally at next round too. The problem is that coin distribution is not calculated not only by the time and hashrate of miners, but random block round time also gets in. Block finding time separates each round, and it sometimes can make things unfair situation. PPLNS tries to remove block finding criteria thing and only concentrate to miner's hashrate and time period. Also, there's pool hopping strategy which maximizes/cheats PROP pool. It is proven cheating method for PROP pools. you are wrong, easiest check is to split your hashrate into two groups - one with multiple users(or workers if pool uses vardiff per worker and not per account) and second with a single(BADASSTHATROBUSALL) user for the pool and compare the outcome. multipool is using coinhopping and you do not force all to coinhop by closing single port mining, all hoppers are being penalized by PPLNS, smart miner would do anti-hopping here by mining one coin straight and get that penalty as his bonus.
|
|
|
just change multiports to proportional reward type and it will save you cpu cycles. single coin may stay pplns.
well, actually multiport pool redirects to single coin internally. They are not separate pool. I fixed and optimized some codes to speed up. I'll continually monitor them. And.. miningpoolhub was using PROP about 2 years ago. It's faster but little miners would have penalty at short block time coins. Thank you. it's not true, little miners can miss one round but they could score double on next "short" round, so it is even at the end.
|
|
|
just change multiports to proportional reward type and it will save you cpu cycles. single coin may stay pplns.
|
|
|
|