Or maybe nicehash would affects? I mean that... nicehash's total rental hash is about 40G now. It's not that big from 5T net hash, but quite big for our pool (100G).
So, when one of miner bought 20G rental hash for an hour and didn't find any block (it can happen. 20G is not that big), then it would harm the rest of miner's reward. Of course it can happen opposite. Rental user would find more blocks than usual and other miners will get more than usual.
I don't mean that nicehash makes inefficient pool block finding, but maybe it would introduce more fluctuation of block finding. Because this rental hash hop in and out frequently, lucky time will be more lucky and unlucky times will be more unlucky.
Just guess.
That is a possible explanation, but couldn't this be seen in the change of pools luck (avg block time)? As the luck proximation time would decrease significantly if there was ~20% increase in hashingrate?
That is a possible explanation, but couldn't this be seen in the change of pools luck (avg block time)? As the luck proximation time would decrease significantly if there was ~20% increase in hashingrate?
Or maybe nicehash would affects? I mean that... nicehash's total rental hash is about 40G now. It's not that big from 5T net hash, but quite big for our pool (100G).
So, when one of miner bought 20G rental hash for an hour and didn't find any block (it can happen. 20G is not that big), then it would harm the rest of miner's reward. Of course it can happen opposite. Rental user would find more blocks than usual and other miners will get more than usual.
I don't mean that nicehash makes inefficient pool block finding, but maybe it would introduce more fluctuation of block finding. Because this rental hash hop in and out frequently, lucky time will be more lucky and unlucky times will be more unlucky.
Just guess.
I don't understand this at all. Bringing more hash on to the pool can only help us find more blocks. The 20G is just extra 100 + 20. It never goes to 100 - 20 = 80. There is always a minimum of 100G on the pool. It would be stupid for someone from niceshash to point his hash at a pplns pool for a short period of time.
You said you have 3 other wallets, is each wallet for a unique server? Us-East, Asia1, Europe1 and a non-advertised server? If that's the case this wallet still didn't get a block for 8 hours. If the hash is spread evenly over 4 wallets, this wallet didn't get a block for 8 hours, something was wrong with it because it gets block regularly. Did the other 3 wallets see an influx of more blocks while this one was down? I would be very grateful if you could clear up what happened for us. Thanks.
I don't understand this at all. Bringing more hash on to the pool can only help us find more blocks. The 20G is just extra 100 + 20. It never goes to 100 - 20 = 80. There is always a minimum of 100G on the pool. It would be stupid for someone from niceshash to point his hash at a pplns pool for a short period of time.
You said you have 3 other wallets, is each wallet for a unique server? Us-East, Asia1, Europe1 and a non-advertised server? If that's the case this wallet still didn't get a block for 8 hours. If the hash is spread evenly over 4 wallets, this wallet didn't get a block for 8 hours, something was wrong with it because it gets block regularly. Did the other 3 wallets see an influx of more blocks while this one was down? I would be very grateful if you could clear up what happened for us. Thanks.
There are some nicehash's rental users hop in and out because of their bid price. When higher bid order is made at nicehash, previous renting order hash can be closed or decreased. It is nature of rental service from nicehash. Rental user, and pool both need to prepare hop in and out.
Pool doesn't route shares to several wallets. Just make new block from their local server. So it's not spread evenly. There's no need to spread shares because only block candidate shares are submitted to wallet. If europe server's miner count decreased or failover occurred and connected to other server, then europe server's wallet would make less new blocks at that time. As genoil-ethminer's fail over doesn't automatically recover to first server until the second server disconnected, this can make some server to not find block for few hours. It's unlikely, but can happen.
I'm a little bit confused now. It seems that my failover switches from europe1 to us-east1 seemly often. Does that mean that I earn less because my default-server is europe1?
I'm a little bit confused now. It seems that my failover switches from europe1 to us-east1 seemly often. Does that mean that I earn less because my default-server is europe1?
I restarted europe pool about 2 times yesterday for mining optimization. (I had to tweak some configurations) Sorry for that. I think it caused you to failover to US server.
All servers are equal on pool side. Earnings may be affected by network latency between you and pool server. Actually, it doesn't affect much if you are using stratum mining. It's quite efficient and stable.
Did your miner not get back to europe server automatically? As far as I know, genoil-ethminer doesn't support returning from failover server currently. Maybe it would be fixed later.
It doesn't happen frequently but pool need to restart time to time. (I try to minimize disconnection) There's no way to encourage miner to connect other server from pool.
Maybe automatically restarting ethminer from client every 1 hour would be a workaround for this issue.
I hope genoil-ethminer to have pool watchdog thread like sgminer and switch to main pool from failover pool.
@miningpoolhub, can you give me the exact commandline for using claymore on your pool?
Ive been mining on it fine for awhile, but now that I have multiple rigs on it, i'm running into issues since claymore doesnt support pool login via "username.workername" format. I think i've been mining for the last 3 days on an account that doesnt exist with my smaller rig (only 45mh/s, so not a big deal).
Basically I have 2 rigs, one 140 mh/s, and one 45 mh/s. I can use the same command to start claymore on both using "-eworker shutfu", but then it could combine them right? so I couldn't separate them as different workers for tracking or to take advantage of vardiff (if this even matters).
Also, does the "-ewal walletaddress" even matter in the start commandline since mph doesnt use wallet for login?
miningpoolhub: EthDcrMiner64.exe -epool us-east1.ethereum.miningpoolhub.com:20536 -ewal 0xD69af2A796A737A103F12d2f0BCC563a13900E6F -eworker YourLogin.YourWorkerName -epsw x -allpools 1 you must also create worker "YourWorkerName" on pool and specify your wallet address there. -- I would presume MPH handles wallet addresses the same was as it does with eth-proxy - that is, you have to set wallet address at pool's Wallet page, then MPH can find your username by wallet address. The wallet matters.
Vardiff is per-connection, not per-worker, if I recall correctly, so using multiple miners on the same worker name shouldn't impact vardiff. (I might be wrong here tho - this is just what I recall reading earlier in this thread somewhere).
miningpoolhub: EthDcrMiner64.exe -epool us-east1.ethereum.miningpoolhub.com:20536 -ewal 0xD69af2A796A737A103F12d2f0BCC563a13900E6F -eworker YourLogin.YourWorkerName -epsw x -allpools 1 you must also create worker "YourWorkerName" on pool and specify your wallet address there. -- I would presume MPH handles wallet addresses the same was as it does with eth-proxy - that is, you have to set wallet address at pool's Wallet page, then MPH can find your username by wallet address. The wallet matters.
Vardiff is per-connection, not per-worker, if I recall correctly, so using multiple miners on the same worker name shouldn't impact vardiff. (I might be wrong here tho - this is just what I recall reading earlier in this thread somewhere).
Thank you for your helpful comment. You are right. Vardiff works per connection.
But setting different workername for each rig is better because pool remembers each worker's last difficulty value. So each worker can start from optimized difficulty value from the start of mining.
thanks @work and @miningpoolhub . I tried what you said, however, and it doesnt appear to be working. The worker showed up, but as you can see in this screenshot, it isnt detecting anything that it mines. it has been mining since I left for work 8 hours ago. The main rig (140mh/s actual speed) is being detected just fine though.
anyone who was on ethermine before, i used this pool for half a day ,and looks profit is less then mining half a day on ethermine.. even when paying uncles and so..
Other people who have other expierience can answer here..
@sennevb half a day isn't anywhere near long enough for variance to even out. MPH is quite a bit smaller then ethermine (100 vs 500GH/s), so variance will take ~5x longer to even out on MPH. A workable comparison might be mining for a full week, half on one pool and half on another.
Also, ethermine pays all rewards like uncle inclusions and fees just like MPH, so there wouldn't be a difference there.
@sennevb dwarfpool is the only pool I know of that does not pay all the rewards (uncle inclusions, transaction fees, etc.). I know ethermine and ethpool do, for sure, and MPH,of course.
MiningPoolHub is running PPLNS, so new miners would get less than their contribution at start.
I hope you to mine concurrently on both pools. Half here, half there. MiningPoolHub can't guarantee the result but you would get nearly same or more from our pool as fee is lower here. Actually pool seems quite lucky these days.
Hey guys, I have a question if you don't mind I tried to mine using ethpool, and little bit confused... how to count how many ether I will get with this ethpool? all I see is just Credits:17t and then next block 3days, can someone please explain it to me? thank you guys!!
Comments
Statistics numbers go up and down actually.
Well it is not updated in realtime, and it's just expected value using rough math.
Pool deactivated softfork vote due to security alert from Ethereum's official blog.
https://blog.ethereum.org/2016/06/28/security-alert-dos-vulnerability-in-the-soft-fork/
Happy mining.
You said you have 3 other wallets, is each wallet for a unique server? Us-East, Asia1, Europe1 and a non-advertised server? If that's the case this wallet still didn't get a block for 8 hours. If the hash is spread evenly over 4 wallets, this wallet didn't get a block for 8 hours, something was wrong with it because it gets block regularly. Did the other 3 wallets see an influx of more blocks while this one was down? I would be very grateful if you could clear up what happened for us. Thanks.
There are some nicehash's rental users hop in and out because of their bid price. When higher bid order is made at nicehash, previous renting order hash can be closed or decreased. It is nature of rental service from nicehash. Rental user, and pool both need to prepare hop in and out.
We run each wallet for each region server.
- asia1. ethereum dedicated server.
http://etherscan.io/address/0x1a060b0604883a99809eb3f798df71bef6c358f1#mine
- us-east1. ethereum dedicated server.
http://etherscan.io/address/0x7a1458f33122080819a2483f2a16034cd8cb0b95#mine
- europe1. ethereum dedicated server.
http://etherscan.io/address/0x6cafe7473925998db07a497ac3fd10405637a46d#mine
- hub.miningpoolhub.com. backup server.
http://etherscan.io/address/0xb2930b35844a230f00e51431acae96fe543a0347#mine
Pool doesn't route shares to several wallets. Just make new block from their local server.
So it's not spread evenly. There's no need to spread shares because only block candidate shares are submitted to wallet.
If europe server's miner count decreased or failover occurred and connected to other server, then europe server's wallet would make less new blocks at that time. As genoil-ethminer's fail over doesn't automatically recover to first server until the second server disconnected, this can make some server to not find block for few hours. It's unlikely, but can happen.
I restarted europe pool about 2 times yesterday for mining optimization.
(I had to tweak some configurations)
Sorry for that. I think it caused you to failover to US server.
All servers are equal on pool side. Earnings may be affected by network latency between you and pool server. Actually, it doesn't affect much if you are using stratum mining. It's quite efficient and stable.
Did your miner not get back to europe server automatically? As far as I know, genoil-ethminer doesn't support returning from failover server currently. Maybe it would be fixed later.
It doesn't happen frequently but pool need to restart time to time. (I try to minimize disconnection)
There's no way to encourage miner to connect other server from pool.
Maybe automatically restarting ethminer from client every 1 hour would be a workaround for this issue.
I hope genoil-ethminer to have pool watchdog thread like sgminer and switch to main pool from failover pool.
Ive been mining on it fine for awhile, but now that I have multiple rigs on it, i'm running into issues since claymore doesnt support pool login via "username.workername" format. I think i've been mining for the last 3 days on an account that doesnt exist with my smaller rig (only 45mh/s, so not a big deal).
Basically I have 2 rigs, one 140 mh/s, and one 45 mh/s. I can use the same command to start claymore on both using "-eworker shutfu", but then it could combine them right? so I couldn't separate them as different workers for tracking or to take advantage of vardiff (if this even matters).
Also, does the "-ewal walletaddress" even matter in the start commandline since mph doesnt use wallet for login?
miningpoolhub:
EthDcrMiner64.exe -epool us-east1.ethereum.miningpoolhub.com:20536 -ewal 0xD69af2A796A737A103F12d2f0BCC563a13900E6F -eworker YourLogin.YourWorkerName -epsw x -allpools 1
you must also create worker "YourWorkerName" on pool and specify your wallet address there.
--
I would presume MPH handles wallet addresses the same was as it does with eth-proxy - that is, you have to set wallet address at pool's Wallet page, then MPH can find your username by wallet address. The wallet matters.
Vardiff is per-connection, not per-worker, if I recall correctly, so using multiple miners on the same worker name shouldn't impact vardiff. (I might be wrong here tho - this is just what I recall reading earlier in this thread somewhere).
Thank you for your helpful comment.
You are right. Vardiff works per connection.
But setting different workername for each rig is better because pool remembers each worker's last difficulty value. So each worker can start from optimized difficulty value from the start of mining.
I tried what you said, however, and it doesnt appear to be working. The worker showed up, but as you can see in this screenshot, it isnt detecting anything that it mines. it has been mining since I left for work 8 hours ago. The main rig (140mh/s actual speed) is being detected just fine though.
commandline for shutfu.dt rig:
EthDcrMiner64.exe -etha "1,0" -mode 1 -ethi "16,4" -epool us-east1.ethereum.miningpoolhub.com:20536 -ewal walletaddress -eworker "shutfu.dt" -epsw x -allpools 1
EthDcrMiner64.exe -wd 1 -r 0 -allpools 1 -estale 1 -ftime 5 -mport 3333 -tstop 100 -epool us-east1.ethereum.miningpoolhub.com:20535 -esm 2 -ewal Login.Worker -epsw Password -eworker Login.Worker -etha 0 -ethi 16 [decred stuff]
also now it appears to be working out of nowhere on its own ??????
Other people who have other expierience can answer here..
Also, ethermine pays all rewards like uncle inclusions and fees just like MPH, so there wouldn't be a difference there.
MiningPoolHub is running PPLNS, so new miners would get less than their contribution at start.
I hope you to mine concurrently on both pools. Half here, half there.
MiningPoolHub can't guarantee the result but you would get nearly same or more from our pool as fee is lower here. Actually pool seems quite lucky these days.
Yeah, I will add that coin.
Sia, DCR, EXP will be added one by one.
You can view vote result at http://carbonvote.com/