On europe1 I had no problems at that specific time. Early this morning, europe1 seemed to shut down and ethminer-genoil 1.0.6 didn't seem to reconnect. That was about 05:00 and I noticed it about 5 hours later. My single GPU earns about 0.23 ETH per day.
@leotau12 mph supports both dwarf and coinmine stratum modes, but only the coinmine mode works well. With genoil's ethminer I get returns in line with the calculators, but on the same machine using the official ethminer + dwarf-proxy I was getting about 15% less.
Thanks for clarifying. I guess MPH still needs adjustments. Going back ethermine.org to continue my mining and hopefully able to chase up lost hours.
(1) Pool luck fluctuate very much for short period of time. - Ethereum Mining Pool Hub is quite small pool still. - Some day, pool luck percentage decreases under 75% (lower the better), but sometimes it increases more than 110%. This 30% like variation is becasue of small pool limitation, and it's not about the bug or error of pool.
(2) Your credits may be delayed a bit. - Pool distribute coins about average 15~40 minutes interval. Your credits shown on dashboard may delayed. - Pool uses 200 confirmations for confirmed blocks.
Internally, eth-proxy + ethminer works quite similar as other proxy or standalone miner from pool side.
We will release all-in-one miner soon, we hope you try our pool again then.
@leotau12 mph supports both dwarf and coinmine stratum modes, but only the coinmine mode works well. With genoil's ethminer I get returns in line with the calculators, but on the same machine using the official ethminer + dwarf-proxy I was getting about 15% less.
Seems like you are comparing standalone "genoil's ethminer stratum mode" vs "proxy + ethminer"
This is difference between "stratum mode" vs "proxy", not "coinmine mode" vs "dwarf mode"
Actually dwarf mode and coinmine mode is internally similar. They are based on same slush's bitcoin mining proxy and only some lines of code are changed. Pool side is also similar too. Thanks.
(1) Pool luck fluctuate very much for short period of time. - Ethereum Mining Pool Hub is quite small pool still. - Some day, pool luck percentage decreases under 75% (lower the better), but sometimes it increases more than 110%. This 30% like variation is becasue of small pool limitation, and it's not about the bug or error of pool.
(2) Your credits may be delayed a bit. - Pool distribute coins about average 15~40 minutes interval. Your credits shown on dashboard may delayed. - Pool uses 200 confirmations for confirmed blocks.
Internally, eth-proxy + ethminer works quite similar as other proxy or standalone miner from pool side.
We will release all-in-one miner soon, we hope you try our pool again then.
@miningpoolhub Forgive me but I have nothing against your pool and all. Just that I need to earn what I am supposed to earn.
Dwarf's stratum protocol can be used without a proxy, as is done with Claymore's miner. And coinmine's stratum protocol can be used with their proxy to a get-work client. The two protocols are not at all compatible. Connecting genoil's ethminer to a dwarfpool's stratum server can even cause it to crash. Anyone looking at the json (ASCII) data can see the difference for themselves. Dwarf's stratum protocol starts with a jsonrpc 2.0 "eth_submitLogin" method, while coinmine starts with a json "mining.subscribe" method.
Yeah, I already know their protocol differences as I implemented pool to make them compatible. But internally, their protocol method name like 'eth_submitLogin', 'mining.subscribe' is just a bit of difference, mainly just method name change or parameter changes.
One of the most difference is that dwarf's proxy receive push messages and additionally poll ethwork every 2 seconds, but coinotron's proxy does not poll, just receive push messages only. dwarf's proxy creator seems like don't trust push data, but it is unnecessary works when pool server side is well implemented. Dwarf's proxy doesn't follow stratum protocol at all, and it is just some idea inserted from dwarf creator. Maybe it's inserted to detect server failover. (Dwarf's proxy program switches server when new data is not received for few minutes) Anyway it's really unnecessary traffic, and it harms proxy program itself and server. I don't know how Claymore's miner implemented this part but it doesn't matter because miner will work even ethWork polling is not implemented.
These proxy program's inner logic is almost same without this difference, You would find it if you diff two proxy source codes. This is why I'm saying that there would be very little difference on optimization.
I am not so experienced and need a little help. Do you have a sample bat-file for failover? THX in advance.
I figured it out and genoil-1.0.7 seems to be working with failover, since the miner didn't stop this morning as it did in the last few days at 5:00 am.
Inner circle shows your invalid shares, and pool's total invalid shares. Outer circle is your valid shares, pool's total valid shares. Invalid shares includes "low difficulty share", "stale share", "duplicate share".
This circles didn't reflect actual share status correctly as we just skipped invalid shares before. But we tweaked this related code yesterday and found that most of the invalid shares are low difficulty shares. They may be tried to send fake shares or some proxy + miner configuration was wrong. Maybe DAG corruption problem. Miners who have high invalid shares would be blocked, banned for few minutes from pool.
Anyway, it seems quite unclear graph for users, we just deleted this part. We will renew whole dashboard design after we launch all-in-one miner.
(2) eth-proxy Developed by dwarfpool. This proxy supports failover. Stratum, vardiff supported on our pool.
Port : 20536 Usage : There are two types of mining with eth-proxy. Wallet address based authorization, and username based authorization. If you want to set failover with wallet based pools like dwarfpool (wallet based pool), you have to follow this guideline to make things compatible.
* When mining at miningpoolhub, and failover to username based authorization pools only. You have to configure eth-proxy.conf before launch. set like below. (Dummy data filled at WALLET to pass proxy's wallet address check)
(2) eth-proxy Developed by dwarfpool. This proxy supports failover. Stratum, vardiff supported on our pool.
Port : 20536 Usage : There are two types of mining with eth-proxy. Wallet address based authorization, and username based authorization. If you want to set failover with wallet based pools like dwarfpool (wallet based pool), you have to follow this guideline to make things compatible.
* When mining at miningpoolhub, and failover to username based authorization pools only. You have to configure eth-proxy.conf before launch. set like below. (Dummy data filled at WALLET to pass proxy's wallet address check)
We will add decred soon. Decred is the major coin we are considering for next update. Like Ethereum, Decred is not compatible with previous stratum pool implementations, we have to dig deep to make things work.
I think you are referring about all-in-one-miner which is about to release soon. All-in-one-miner includes sgminer (or ccminer) and ethminer together to make auto switching work across different miners.
Actually, new sgminer that supports skein algo, with "--no-retry" option (for auto switching) is already done and published yesterday. https://github.com/miningpoolhub/sgminer
But, I found that genoil-ethminer crashes when pool disconnects time to time, so auto switching with current release is broken. I will post an announcement of auto switching when ethminer is ready. Maybe I would debug and fix ethminer too.
GUI based mining manager program like what nicehash has released is also on our plan. I don't think it would take much time, but it is not on high priority at this time.
But, I found that genoil-ethminer crashes when pool disconnects time to time, so auto switching with current release is broken. I will post an announcement of auto switching when ethminer is ready. Maybe I would debug and fix ethminer too.
GUI based mining manager program like what nicehash has released is also on our plan. I don't think it would take much time, but it is not on high priority at this time.
Cool, nice to see it coming along. You could always just clone and modify nicehash's program, it's very easy to modify.
I'm pleased to see valid/invalid share stats on the dashboard. I suspect that you are not counting any shares that don't match a solution to the current block (work). If that is the case, you are doing it wrong. "stale" shares are worthless in btc, but in eth they are potentially uncle blocks. You should validate the shares against the current and previous blocks, which would capture the vast majority of the potential uncle blocks. My invalid rate was ~1% when I looked earlier today. If that is typical for the pool, then the pool is missing out on 7/8ths of that 1% (since a 1st-generation uncle gets a 7/8ths reward).
Actually I already tested similar things about uncle, and tested in reality but went out not that effective. But, now I see there's something I missed at that time. I'll implement what you stated and run it today.
I think we should not count stale shares, but try to submit new block. When stale share's block has higher difficulty than main block, then blockchain will fork and uncle candidate share would be main block and get 5 ETH.
Comments
Mined from ethermine.org and estimated earnings "never missed" per day.
per hour - .05
With your pool I am already behind .2+++
I might go back to ethermine.org if after 24hrs I do not get my earnings what I am supposed to get.
Any logic explanation/s???
Thanks
BTW: your pool is like WEIPOOL that gives no where near the estimated earnings (MY OPINION ONLY).
Please correct me if I'm wrong.
@leotau12
Here's explanations.
(1) Pool luck fluctuate very much for short period of time.
- Ethereum Mining Pool Hub is quite small pool still.
- Some day, pool luck percentage decreases under 75% (lower the better), but sometimes it increases more than 110%. This 30% like variation is becasue of small pool limitation, and it's not about the bug or error of pool.
(2) Your credits may be delayed a bit.
- Pool distribute coins about average 15~40 minutes interval. Your credits shown on dashboard may delayed.
- Pool uses 200 confirmations for confirmed blocks.
Internally, eth-proxy + ethminer works quite similar as other proxy or standalone miner from pool side.
We will release all-in-one miner soon, we hope you try our pool again then.
Seems like you are comparing standalone "genoil's ethminer stratum mode" vs "proxy + ethminer"
This is difference between
"stratum mode" vs "proxy",
not "coinmine mode" vs "dwarf mode"
Actually dwarf mode and coinmine mode is internally similar. They are based on same slush's bitcoin mining proxy and only some lines of code are changed. Pool side is also similar too.
Thanks.
Yeah, I already know their protocol differences as I implemented pool to make them compatible.
But internally, their protocol method name like 'eth_submitLogin', 'mining.subscribe' is just a bit of difference, mainly just method name change or parameter changes.
One of the most difference is that dwarf's proxy receive push messages and additionally poll ethwork every 2 seconds, but coinotron's proxy does not poll, just receive push messages only. dwarf's proxy creator seems like don't trust push data, but it is unnecessary works when pool server side is well implemented. Dwarf's proxy doesn't follow stratum protocol at all, and it is just some idea inserted from dwarf creator. Maybe it's inserted to detect server failover. (Dwarf's proxy program switches server when new data is not received for few minutes)
Anyway it's really unnecessary traffic, and it harms proxy program itself and server. I don't know how Claymore's miner implemented this part but it doesn't matter because miner will work even ethWork polling is not implemented.
These proxy program's inner logic is almost same without this difference, You would find it if you diff two proxy source codes. This is why I'm saying that there would be very little difference on optimization.
I too have nothing against you. Just wanted to explain as you requested any logic explanation.
Have a nice day
With 180Mh it says i make good 2eth a day, seems a bit less.
Pool was quite unlucky lately.
I won´t switch, the pool seems nice, i observe this a view days.
cd \ cd programs\ethereum 0.9.41\release setx GPU_MAX_ALLOC_PERCENT 100 setx GPU_USE_SYNC_OBJECTS 1 setx GPU_MAX_HEAP_SIZE 100 ethminer.exe -G -S europe1.ethereum.miningpoolhub.com:20535 -O Delle54.R9280x:Password -FS us-east.ethereum.miningpoolhub.com:20535 -FO Delle54.R9280x:PasswordInner circle shows your invalid shares, and pool's total invalid shares.
Outer circle is your valid shares, pool's total valid shares.
Invalid shares includes "low difficulty share", "stale share", "duplicate share".
This circles didn't reflect actual share status correctly as we just skipped invalid shares before.
But we tweaked this related code yesterday and found that most of the invalid shares are low difficulty shares. They may be tried to send fake shares or some proxy + miner configuration was wrong. Maybe DAG corruption problem.
Miners who have high invalid shares would be blocked, banned for few minutes from pool.
Anyway, it seems quite unclear graph for users, we just deleted this part.
We will renew whole dashboard design after we launch all-in-one miner.
Thanks.
Hi
I'm not familiar with ethOS yet. Can you clarify about proxypool? Any link or info would be appreciated.
(2) eth-proxy
Developed by dwarfpool. This proxy supports failover. Stratum, vardiff supported on our pool.
Port : 20536
Usage : There are two types of mining with eth-proxy.
Wallet address based authorization, and username based authorization. If you want to set failover with wallet based pools like dwarfpool (wallet based pool), you have to follow this guideline to make things compatible.
* When mining at miningpoolhub, and failover to username based authorization pools only.
You have to configure eth-proxy.conf before launch. set like below.
(Dummy data filled at WALLET to pass proxy's wallet address check)
WALLET = "0x0000000000000000000000000000000000000000"
ENABLE_WORKER_ID = True
POOL_HOST = "us-east1.ethereum.miningpoolhub.com"
POOL_PORT = 20536
POOL_FAILOVER_ENABLE = True
POOL_HOST_FAILOVER1 = "europe1.ethereum.miningpoolhub.com"
POOL_PORT_FAILOVER1 = 20536
POOL_HOST_FAILOVER2 = "asia1.ethereum.miningpoolhub.com"
POOL_PORT_FAILOVER2 = 20536
Set us-east1, europe1, asia1 server order from nearest to farthest from your location.
Run (3) or (5) ethminer
ethminer --farm-recheck 200 -G -F http://127.0.0.1:8080/username.workername
Also, what's happening with the multi-miner? NiceHash's implementation is pretty easy to replicate.
@kotarius
Thank you for precious setting info.
We will add decred soon. Decred is the major coin we are considering for next update.
Like Ethereum, Decred is not compatible with previous stratum pool implementations, we have to dig deep to make things work.
Thank you for suggestion.
I think you are referring about all-in-one-miner which is about to release soon.
All-in-one-miner includes sgminer (or ccminer) and ethminer together to make auto switching work across different miners.
Actually, new sgminer that supports skein algo, with "--no-retry" option (for auto switching) is already done and published yesterday.
https://github.com/miningpoolhub/sgminer
All in one miner windows binary repository is here.
https://github.com/miningpoolhub/all-in-one-miner
But, I found that genoil-ethminer crashes when pool disconnects time to time, so auto switching with current release is broken. I will post an announcement of auto switching when ethminer is ready. Maybe I would debug and fix ethminer too.
GUI based mining manager program like what nicehash has released is also on our plan. I don't think it would take much time, but it is not on high priority at this time.
I'm curious that, do you use that program?
I thought it was for hobby miner who runs it on office computer, not experts like you.
Good compensation policy
Actually I already tested similar things about uncle, and tested in reality but went out not that effective.
But, now I see there's something I missed at that time. I'll implement what you stated and run it today.
I think we should not count stale shares, but try to submit new block.
When stale share's block has higher difficulty than main block, then blockchain will fork and uncle candidate share would be main block and get 5 ETH.
Thank you for your idea.
Hi~