Topic: [4+ EH] Slush Pool (slushpool.com); Overt AsicBoost; World First Mining Pool - page 1079. (Read 4382648 times)
April 01, 2011, 09:46:30 AM
After changing my worker password to a new one (that includes symbols), the /accounts/profile page is giving me a 404. My account name is ehird; is there any way to rectify this? Thanks in advance.
March 31, 2011, 02:16:35 PM
Moreover i don't see the 10% fee in pps method that you have said. i calculate exaclty the shares x share_value and the outcome was exactly the BTCs that i got!
That's because price per share is already set with 10% subtracted from average expectation. March 31, 2011, 02:08:29 PM
last 2 days i am checking the pps and propotional method. pps gave more BTCs!
thus i wonder if propotioanl is better or not, because pps is a constant payment method regardless the blocks found by the pool or anything else.
Moreover i don't see the 10% fee in pps method that you have said. i calculate exaclty the shares x share_value and the outcome was exactly the BTCs that i got!
thus i wonder if propotioanl is better or not, because pps is a constant payment method regardless the blocks found by the pool or anything else.
Moreover i don't see the 10% fee in pps method that you have said. i calculate exaclty the shares x share_value and the outcome was exactly the BTCs that i got!
March 31, 2011, 06:45:36 AM
The problem I'm having is that lately in slush's pool a lot more shares seem to be needed per hour. It's very consistent.
Well, the pool luck in previous 3 days was pretty bad, as you can see in daily graphs (system and user's). As far as I can tell, system is working well and there is no reason for losing shares or miss blocks.
Quote
I was getting a lot less than I should have working 24 hours a day with a 5870.
Even in those unlucky days, my miner is getting only 1-2 BTC less than expected _teoretic_ daily income (from 35 BTC total) in 7day moving average, so I cannot confirm that.
Quote
Compared with depbit for ex., for the samples I checked, about twice as many shares per block (with similar times to solve) seem to be needed.
Probability is bitch
. How long history did you checked?You're right. Things got worse in these last days. But with bitpenny or deepbit's pay per share i would have got somewhere around 4.38 bitcoins per day even after the 10% fee, while on your pool I got 3.6 - 3.7. Rather appalling. If it was a ratio of 1 less coin out of 35 as you say you got, I wouldn't be alarmed at all.
March 31, 2011, 03:52:23 AM
Any progress on long polling?
It's in progress and will be ready soon. LP was ready after 10 hours of coding, but there are other related problems (multiple bitcoind instances synchronization), which I'm currently solving. Unfortunately I'm busy in my daily job, so it is taking some time...
March 31, 2011, 03:47:29 AM
Any progress on long polling? If not having it causes 1% more stale shares, it's 250 BTC lost for the pool in the last 13 days.
March 30, 2011, 08:12:31 PM
Block 115804 sure was a bitch. Took 3:28:20.
Love your pool by the way slush!
Love your pool by the way slush!
March 30, 2011, 06:21:00 PM
Probability is bitch
. March 30, 2011, 05:39:06 PM
I just calculated the average shares/block for deepbit and my pool. deepbit is 68400, which perfectly fit current difficulty, my pool is 83100 (both calculated from 27.3. 21:00, it's latest known history on deepbit stats). So you're right, current pool luck is worse than deepbit. But few days ago deepbit was above 90k . This is nothing about deepbit, just don't panic, everything around mining is about luck.
EDIT: Pool luck is displayed as CFD graph on pool stats page. From this graph you can see that there is absolutely no reason for panic, the teoretic and measured curves almost perfectly fit.
. This is nothing about deepbit, just don't panic, everything around mining is about luck.EDIT: Pool luck is displayed as CFD graph on pool stats page. From this graph you can see that there is absolutely no reason for panic, the teoretic and measured curves almost perfectly fit.
March 30, 2011, 05:30:12 PM
The problem I'm having is that lately in slush's pool a lot more shares seem to be needed per hour. It's very consistent.
Well, the pool luck in previous 3 days was pretty bad, as you can see in daily graphs (system and user's). As far as I can tell, system is working well and there is no reason for losing shares or miss blocks.
Quote
I was getting a lot less than I should have working 24 hours a day with a 5870.
Even in those unlucky days, my miner is getting only 1-2 BTC less than expected _teoretic_ daily income (from 35 BTC total) in 7day moving average, so I cannot confirm that.
Quote
Compared with depbit for ex., for the samples I checked, about twice as many shares per block (with similar times to solve) seem to be needed.
Probability is bitch
. How long history did you checked? March 30, 2011, 05:29:31 PM
Unless I'm wrong, the more Ghash/s, the smaller your share of that block would be. You put in same amount of shares per second, but get smaller payout because you are a smaller percentage. Because blocks are solved more frequently, your total payout remains constant, but the per block payout is smaller.
You may see fewer shares/block found because less shares were needed. If it took 50 shares to find a block, and slush found 3 in a row, there would only be 50 shares to pay out each block. But if the pool missed the first two and found the 3rd, there would be 150 shares in that one block. People would see more shares for that block, but that's only because we missed finding 2 blocks.
You may see fewer shares/block found because less shares were needed. If it took 50 shares to find a block, and slush found 3 in a row, there would only be 50 shares to pay out each block. But if the pool missed the first two and found the 3rd, there would be 150 shares in that one block. People would see more shares for that block, but that's only because we missed finding 2 blocks.
Yeah I understand- what you're saying is basically that if it takes more time to find a block more shares are needed and the prize is then divided among the higher number of shares and so you get less: bad luck. But I accounted for that. I looked comparatively at slush's pool and deepbit and blocks found in roughly the same amount of time were divided in slush's case to a lot more shares than deepbit's blocks. That doesn't make any sense if they're operating on the same difficulty level. I think I can safely assume slush did not fork bitcoin right ?
March 30, 2011, 05:06:13 PM
Unless I'm wrong, the more Ghash/s, the smaller your share of that block would be. You put in same amount of shares per second, but get smaller payout because you are a smaller percentage. Because blocks are solved more frequently, your total payout remains constant, but the per block payout is smaller.
You may see fewer shares/block found because less shares were needed. If it took 50 shares to find a block, and slush found 3 in a row, there would only be 50 shares to pay out each block. But if the pool missed the first two and found the 3rd, there would be 150 shares in that one block. People would see more shares for that block, but that's only because we missed finding 2 blocks.
You may see fewer shares/block found because less shares were needed. If it took 50 shares to find a block, and slush found 3 in a row, there would only be 50 shares to pay out each block. But if the pool missed the first two and found the 3rd, there would be 150 shares in that one block. People would see more shares for that block, but that's only because we missed finding 2 blocks.
March 30, 2011, 05:00:48 PM
i think that shares are fewer in a pool with a vast Gh/s, but at the same time that pool has more possibilities to catch a block! please correct me if i am wrong
Number of shares per block doesn't linked to pool's speed. It only depends on the current difficulty.Unless there is some dilution of shares happening.
March 30, 2011, 04:57:36 PM
i think that shares are fewer in a pool with a vast Gh/s, but at the same time that pool has more possibilities to catch a block! please correct me if i am wrong :)
Number of shares per block doesn't linked to pool's speed. It only depends on the current difficulty. March 30, 2011, 04:39:06 PM
i think that shares are fewer in a pool with a vast Gh/s, but at the same time that pool has more possibilities to catch a block! please correct me if i am wrong
March 30, 2011, 04:29:45 PM
put a bounty like 25% on late enters ... if you not in the pool for the long haul you get penalized
don't penalize early shares
don't penalize early shares
And who should pay that bounty ? If you give late enters 25% more you're gonna have to take that from the early ones no ? Which is exactly what is happening now. Or are you suggesting slash should pay the bounty out of his own pocket ? I'm all for it btw.
The problem I'm having is that lately in slush's pool a lot more shares seem to be needed per hour. It's very consistent. I was getting a lot less than I should have working 24 hours a day with a 5870. Compared with depbit for ex., for the samples I checked, about twice as many shares per block (with similar times to solve) seem to be needed. Nobody noticed this besides me ? It's like slush is working with a much higher difficulty level than deepbit...
ok i did not mean 25% bonus I ment take away %25 of their earnings ...add that to the pool
March 30, 2011, 04:15:42 PM
put a bounty like 25% on late enters ... if you not in the pool for the long haul you get penalized
don't penalize early shares
don't penalize early shares
And who should pay that bounty ? If you give late enters 25% more you're gonna have to take that from the early ones no ? Which is exactly what is happening now. Or are you suggesting slash should pay the bounty out of his own pocket ? I'm all for it btw.
The problem I'm having is that lately in slush's pool a lot more shares seem to be needed per hour. It's very consistent. I was getting a lot less than I should have working 24 hours a day with a 5870. Compared with depbit for ex., for the samples I checked, about twice as many shares per block (with similar times to solve) seem to be needed. Nobody noticed this besides me ? It's like slush is working with a much higher difficulty level than deepbit...
March 30, 2011, 04:01:58 PM
put a bounty like 25% on late enters ... if you not in the pool for the long haul you get penalized
don't penalize early shares
don't penalize early shares
March 30, 2011, 03:24:36 PM
CPU miners will never find a single share before the total share count is near 5k shares or so.
Why? This is not correct - everybody has the same chance to hit first share, of course proportionally to his hashrate. Just for curiosity, 7/8 shares was submitted by normal users with decent GPUs (I know some of the users so I can tell), not by users with strong rigs. Of course probability that CPU user with 1mhash/s hit one of first 8 shares is very low, but don't forget that he has 200-300x slower worker.
Quote
In these cases, you could use the share ratio of the last round the did have time to actually find some shares for.
Sorry, I still don't see why. And why the limit should be 5k shares and not 3k or 10k shares. Don't confuse fairness and luck; this artifical limit is definitely less _fair_, because it favors unlucky workers.
Fair points, maybe the idea I threw wasn't quite up to the task. However, since I have endless supply of them ideas, here's another one:
What if the rewards would be calculated only once per day. Every user would get a reward of
total_btc_for_given_day * their_shares_for_given_day / total_shares_for_given_day
Would that make more sense? What other downsides would this have except slightly slower feed back on rewards for users? (altho you could still show a daily estimate).
March 29, 2011, 03:29:01 PM
What happened? Network down or some thing?
No, everything is OK. The hashmeter is calculated from current round (is calculated from submitted shares/round duration). This means that after refresh instantly after block is found, you'll see "Cluster performance: 0Ghash/s", because there isn't any share yet. As the round is going, the hashmeter goes up to real cluster performance.
I have also implemented hashmeter with sliding 5min average (submitted shares in last 5min / 300 sec), which is currently not enabled. This hashmeter is not affected by round ends, but the hashrate variance is much bigger - 5min is not long enough window and speed is changing in +/- 20ghash/s.
EDIT: I just changed hashmeter from round-based to continuous and rised statistics window from 5min to 20min avg, so number should be much more steady/exact now.
Jump to: