@zorvalth You exactly describe the definition of luck. If a miner with 100MH/s gets unlucky 3 days in a row there is an equal chance he will get lucky 3 days in a row. Pools can reduce variance only to a certain degree as even the Ethereum network as a whole is heavily subjected to luck (given a 17 second block time, we regularly see 2 minute blocks as well as 1 second blocks).
@dr_pra The network is a very good approximation of life. Although, for me, luck is just statistical probability, with a dollop of superstition on top.
We have upgraded our effective hashrate calculation. The frequent jumps in the displayed hashrate should be gone now. Please note, as the hashrate is calculated using a 60 minute window, it will take up to two hours till the displayed hashrate is correct when you start mining on the pool!
ethpool.org shows the effective hashrate that is calculated based on your submitted valid shares. If one of your workers produces invalid shares your displayed hashrate will be less. Fluctuations are normal as the share difficulty is quite high to keep your miners busy. We could lower the difficulty to increase the accuracy of the displayed hashrate but this will decrease your miners efficiency (each start/stop causes some lost hashrate). After several hours the displayed average hashrate should match your local one. Also the payouts should match to what you would get when solo mining. Please note that nearly every mining calculator available does not take uncles into account which will cause it to underestimate the overall network hashrate and to overestimate your expected mining revenue.
Thanks. The question that comes into my mind is how do I determine if I submit invalid shares. 20-25% invalid shares compared to soloing seems huge to me.
And another question which puts me off a bit: I've mined for about 18 hours averaging 100Mh/s and had to restart and do some work on my rig. Now I do not even see my address in credits meaning I've lost 18 hours of work? Thanks
The pool provides feedback to the mining clients if it submits an invalid share (and why the share was invalid). You can check in your mining logs for such messages.
Accounts time out after 2 hours of inactivity but credits are saved. Once you start mining again your credits will be back as well.
The pool provides feedback to the mining clients if it submits an invalid share (and why the share was invalid). You can check in your mining logs for such messages.
Accounts time out after 2 hours of inactivity but credits are saved. Once you start mining again your credits will be back as well.
Really like that your credits are being saved, so my workers can be offline for a week.. and when i return it continue's where i left off.. are credits then synced with the wallet you provide for mining i guess?
The pool provides feedback to the mining clients if it submits an invalid share (and why the share was invalid). You can check in your mining logs for such messages.
Accounts time out after 2 hours of inactivity but credits are saved. Once you start mining again your credits will be back as well.
I am also interested in seeing my stats regarding valid/invalid shares. I have a couple of miners that are submitting less than shown in the miner.
I am starting to like this pool. Smaller chance of getting a lucky streak and profiting bigtime as with solo mining, but it seems better than other pools by comparison. After setting up the stratum proxy they recommend (one for each rig) my hash rate is slowly creeping up closer to the actual reported hash rates and there is much, MUCH less hash rate spread than before..
Something wrong with the new hashrate calculation. Before the current hashrate meant nothing but the average(24h) was pretty accurate(5-6 hours after the miner starts) to the hashrate in the console. Now the current is way higher and average is way lower...
yes i made some changes, but before the average (24h) despite the 24h it was getting accurate in a few hours. and the rigs are online for several hours now and teh current is higher, it dropped a little since my last post. will see tomorrow...
We updated our hashrate calculation today, it should be a lot smoother compared to before.
Also we have added an experimental support to display invalid shares on a per worker basis. Bad workers will show up as soon as they submit more than 5 invalid shares. The invalid share counter is reset only when a worker reconnects to the pool. The occasional invalid share is normal but if the number of invalids is rapidly increasing you should check your worker.
@dr_pra, do you have or can you implement any statistic based on what the worker already completed by an hour/12h/24/h? for example last 1h/12h/24h hours worker mined 0.65% of block ≈ 3.22 Eth? I think this is the best statistic which you can see how efficient is your worker. Not some average speed which means nothing...
@zorvalth Go to the Web site and click on credits. Find your account in the list. It tells you exactly how man hashes your been credited for since your last block and an estimate of how long you have to the next block. I know that's not exactly what you're asking, but the difference between your current credits (hashes) and the network difficulty is your percentage toward your next full block award. Also, on your account status page, the "Blocks" Tab gives you the time for each block award you've received since you started mining on the pool. This will give you the data you need to figure out your block mining rate, which can easily be converted to ETH.
@dr_pra congrats on the pool, it's great. Really has grown in the last few days. If the metrics (# of miners, eth price, etc) were to stay as just they are for the next 12 months, you could be looking at a $50K USD/year gross.
A few suggestions:
1. The credits page freezes my browser every 5 seconds. I believe the culprit is this block of js:
function updateCredits() {
$.getJSON("/api/credits", function(data) {
myViewModel.credits.removeAll();
var i = 1;
for(var d in data) {
data[d].rank = i++;
myViewModel.credits.push(data[d]);
}
myViewModel.topMinerCredit(data[0].credit);
});
}
Take a look at this knockout performance tip so that the DOM doesn't end up getting updated 400+ times on each polling update.
2. Might be nice to tag which blocks were uncles on the miner's "blocks" page, and additionally show the how the block reward was calculated for each miner's block (block reward formula - fee - tx fee) so noobs start don't questioning the pool and submit all sorts of support tickets like "WHEREZZ MY ETHZZZ??"
3. On the credits page (again), might be cool to see which miners who have surpassed the current difficulty and will be getting a payout for upcoming found block(s). Maybe just highlight the rows or something basic. Some noob miners might freak when they see their credits at 17.461t and the current difficulty is at 14.890TH. I guess you'd have to poll to keep the difficulty updated.
If it's like SHA256 pools, a # higher than 100 means the pool is having good luck (Blocks solved faster than 'expected'). Bad luck (Below 100%) = the opposite.
@happytreefriends That's what I was guessing, just based on what the number is, now, and what the pool is doing. You can see it in the credits, because the top miner is mining way past the network difficulty before getting a block. Well, it will swing the other way at some point. Thanks!
I'm getting a little skeptical about the pool luck. For the past 3 days i've never seen a moment when the top miner gets the block with credits less than the current difficulty. About the pool luck % I'm guessing is something like if the pool is supposed to get 20 blocks per hour(with the current hashrate) and in the last hour it got 15 = 75% pool luck.
@zorvalth With a pool luck under 100 you would naturally see the top miner not getting the block until he's mined above the current difficulty. So, your observation supports the current pool luck, it doesn't undermine it.
@zorvalth the pool was extremely lucky from last week up to yesterday where it continuously earned more than it should have. Right now the top miner on the credits list is at 14.812t and the block difficulty is at 14.857 so the pool is currently doing fine. The pool luck compares historical data so it lags a bit behind the current situation.
Interestingly there are only complaints about such issues during periods of bad luck but never during periods where the pool earns more than expected
@ethead Thanks for your performance suggestion, already implemented it and hope things are now faster. We will also add a differentiation between blocks & uncles soon.
I'm not saying its not lucky, I'm mining form 2 and a half days. Thats what I'm seeing. I really like the pool and hope the things will turn around. More or less luck as long as is even in time i dont mind. For now I only have issues with the reported average speed, did you just fix the calculations on the "current hashrate" or you made some changes on the average too?
I am in Europe and started to use the EU server. But there is a lot of waiting for work display. The GPU usage drops some times. There is no such (or less) problem if I connect to the US server.
Comments
The question that comes into my mind is how do I determine if I submit invalid shares.
20-25% invalid shares compared to soloing seems huge to me.
And another question which puts me off a bit:
I've mined for about 18 hours averaging 100Mh/s and had to restart and do some work on my rig.
Now I do not even see my address in credits meaning I've lost 18 hours of work?
Thanks
Accounts time out after 2 hours of inactivity but credits are saved. Once you start mining again your credits will be back as well.
Where can we check the mining logs?
I might just move my other rigs to this too.
Right now:
Console: 435
Current: 475
Average: 330
Also we have added an experimental support to display invalid shares on a per worker basis. Bad workers will show up as soon as they submit more than 5 invalid shares. The invalid share counter is reset only when a worker reconnects to the pool. The occasional invalid share is normal but if the number of invalids is rapidly increasing you should check your worker.
-Best Care
David
A few suggestions:
1. The credits page freezes my browser every 5 seconds. I believe the culprit is this block of js:
function updateCredits() { $.getJSON("/api/credits", function(data) { myViewModel.credits.removeAll(); var i = 1; for(var d in data) { data[d].rank = i++; myViewModel.credits.push(data[d]); } myViewModel.topMinerCredit(data[0].credit); }); }Take a look at this knockout performance tip so that the DOM doesn't end up getting updated 400+ times on each polling update.2. Might be nice to tag which blocks were uncles on the miner's "blocks" page, and additionally show the how the block reward was calculated for each miner's block (block reward formula - fee - tx fee) so noobs start don't questioning the pool and submit all sorts of support tickets like "WHEREZZ MY ETHZZZ??"
3. On the credits page (again), might be cool to see which miners who have surpassed the current difficulty and will be getting a payout for upcoming found block(s). Maybe just highlight the rows or something basic. Some noob miners might freak when they see their credits at 17.461t and the current difficulty is at 14.890TH. I guess you'd have to poll to keep the difficulty updated.
About the pool luck % I'm guessing is something like if the pool is supposed to get 20 blocks per hour(with the current hashrate) and in the last hour it got 15 = 75% pool luck.
Interestingly there are only complaints about such issues during periods of bad luck but never during periods where the pool earns more than expected
@ethead Thanks for your performance suggestion, already implemented it and hope things are now faster. We will also add a differentiation between blocks & uncles soon.
@zorvalth Thanks for reporting the issue with the mining notification service. We will try to fix it as soon as possible.