I just released email confirmations for wallet changes on profile page.
Thumps up
Topic: [4+ EH] Slush Pool (slushpool.com); Overt AsicBoost; World First Mining Pool - page 1002. (Read 4382675 times)
June 22, 2011, 01:19:58 PM
Thumps up
June 22, 2011, 12:39:56 PM
I just released email confirmations for wallet changes on profile page.
June 22, 2011, 08:16:25 AM
About blocks #5898 and #5896; They were very short, but both are invalid. Probability of finding two solutions by two pool backends at same time (and twice in the row) is extremely small, but as you see, it may happen.
Pool backends are independent machines, which synchronize data as soon as possible, but broadcasting bitcoin block information is pretty complex stuff, so it may take one or two seconds. In those two blocks, two miners found solution too fast in a row and backends didn't notice that there is already valid solution for this block, so they decide to accept this solution, too. This leads to two 'invalid' blocks, but no (or only very small fraction) of mining power was wasted. I know that two 'invalid blocks' in a row looks weird, but there's not a simple solution to fix this issue and reject invalid block solution when another machine just found valid one.
Pool backends are independent machines, which synchronize data as soon as possible, but broadcasting bitcoin block information is pretty complex stuff, so it may take one or two seconds. In those two blocks, two miners found solution too fast in a row and backends didn't notice that there is already valid solution for this block, so they decide to accept this solution, too. This leads to two 'invalid' blocks, but no (or only very small fraction) of mining power was wasted. I know that two 'invalid blocks' in a row looks weird, but there's not a simple solution to fix this issue and reject invalid block solution when another machine just found valid one.
Thanks for your reply. I see now that the blocks turned out to be invalid, but that if they were OK? The reward would be shared only by the lucky people who submitted shared to those blocks and in one of those cases, a maximum of 60 people would share 50 BTC that really belong to the whole pool. This is what I am trying to fix by suggesting that the rewards of extremely short block runs are shared according to the results of the previous block.
Yes, of course my reward was very high for those blocks. Now invalid. Bummer.
June 22, 2011, 08:13:12 AM
About blocks #5898 and #5896; They were very short, but both are invalid. Probability of finding two solutions by two pool backends at same time (and twice in the row) is extremely small, but as you see, it may happen.
Pool backends are independent machines, which synchronize data as soon as possible, but broadcasting bitcoin block information is pretty complex stuff, so it may take one or two seconds. In those two blocks, two miners found solution too fast in a row and backends didn't notice that there is already valid solution for this block, so they decide to accept this solution, too. This leads to two 'invalid' blocks, but no (or only very small fraction) of mining power was wasted. I know that two 'invalid blocks' in a row looks weird, but there's not a simple solution to fix this issue and reject invalid block solution when another machine just found valid one.
Pool backends are independent machines, which synchronize data as soon as possible, but broadcasting bitcoin block information is pretty complex stuff, so it may take one or two seconds. In those two blocks, two miners found solution too fast in a row and backends didn't notice that there is already valid solution for this block, so they decide to accept this solution, too. This leads to two 'invalid' blocks, but no (or only very small fraction) of mining power was wasted. I know that two 'invalid blocks' in a row looks weird, but there's not a simple solution to fix this issue and reject invalid block solution when another machine just found valid one.
Thanks for your reply. I see now that the blocks turned out to be invalid, but that if they were OK? The reward would be shared only by the lucky people who submitted shared to those blocks and in one of those cases, a maximum of 60 people would share 50 BTC that really belong to the whole pool. This is what I am trying to fix by suggesting that the rewards of extremely short block runs are shared according to the results of the previous block.
June 22, 2011, 07:32:42 AM
check hardware ....!!!! 
if you get "check hardware" errors, it means that solutions found by your GPU do not pass a short & simple verification by CPU. This means that your GPU is doing mistakes in calculation. You need to:1) check temperature of your GPU, if it's above 85 C, you need to downclock it
2) if you overclocked your card, you need to downclock it
3) if none of above, you need to RMA your card, because it's broken.
Thanks for reply ...
temp is 75 deg. (5830)
gpu is 1000 and mem 600
this was ok until now ...(280 Mh)
will check again later ... thanks
June 22, 2011, 07:25:38 AM
check hardware ....!!!!
if you get "check hardware" errors, it means that solutions found by your GPU do not pass a short & simple verification by CPU. This means that your GPU is doing mistakes in calculation. You need to:1) check temperature of your GPU, if it's above 85 C, you need to downclock it
2) if you overclocked your card, you need to downclock it
3) if none of above, you need to RMA your card, because it's broken.
June 22, 2011, 07:15:57 AM
check hardware ....!!!!
pool brocken again
pool brocken again
June 22, 2011, 05:26:28 AM
About blocks #5898 and #5896; They were very short, but both are invalid. Probability of finding two solutions by two pool backends at same time (and twice in the row) is extremely small, but as you see, it may happen.
Pool backends are independent machines, which synchronize data as soon as possible, but broadcasting bitcoin block information is pretty complex stuff, so it may take one or two seconds. In those two blocks, two miners found solution too fast in a row and backends didn't notice that there is already valid solution for this block, so they decide to accept this solution, too. This leads to two 'invalid' blocks, but no (or only very small fraction) of mining power was wasted. I know that two 'invalid blocks' in a row looks weird, but there's not a simple solution to fix this issue and reject invalid block solution when another machine just found valid one.
Pool backends are independent machines, which synchronize data as soon as possible, but broadcasting bitcoin block information is pretty complex stuff, so it may take one or two seconds. In those two blocks, two miners found solution too fast in a row and backends didn't notice that there is already valid solution for this block, so they decide to accept this solution, too. This leads to two 'invalid' blocks, but no (or only very small fraction) of mining power was wasted. I know that two 'invalid blocks' in a row looks weird, but there's not a simple solution to fix this issue and reject invalid block solution when another machine just found valid one.
June 22, 2011, 05:12:40 AM
How come there are two entries for block 132473???
This looks fishy...
This looks fishy...
It's well known bug, but only cosmetic one. Link to blockexplorer is correct.
June 22, 2011, 05:11:37 AM
I have no reward from the last 6 blocks.
Granted I only mine at 200 M/hash but usually I get something...
Granted I only mine at 200 M/hash but usually I get something...
7 blocks with no reward now.. any idea what is going on?
It takes some time to calculate everything, reward of last found block can change few times.
June 22, 2011, 03:31:50 AM
Sometimes, when blocks are found in a few seconds, most pool miners end up not getting anything at all for that block and a few lucky ones get to keep all the loot (rewards as high as a full bitcoin or more). It's just a matter of pure luck who manages to send in a share or two in such a short time.
See entries 5896 and 5898 in this screenshot for an example.
Since the idea of pooling is to eliminate luck and distribute the rewards of mining as fairly as possible, I'm proposing that in these cases, when a block is found sooner than say 30 seconds (admins can better determine the best time to use from their logs) the reward is shared out according to the share proportions of the previous + current blocks, so that everybody gets something.
The only possible 'downside' to this is that if someone happens to leave the pool in the few seconds it takes to find the last block they still get a share. However that is surely fairer than not rewarding all those who have been mining for the previous blocks and denying them the lucky strike that balances out the longer mining times on other blocks.
What do you guys think?
See entries 5896 and 5898 in this screenshot for an example.
Since the idea of pooling is to eliminate luck and distribute the rewards of mining as fairly as possible, I'm proposing that in these cases, when a block is found sooner than say 30 seconds (admins can better determine the best time to use from their logs) the reward is shared out according to the share proportions of the previous + current blocks, so that everybody gets something.
The only possible 'downside' to this is that if someone happens to leave the pool in the few seconds it takes to find the last block they still get a share. However that is surely fairer than not rewarding all those who have been mining for the previous blocks and denying them the lucky strike that balances out the longer mining times on other blocks.
What do you guys think?
June 22, 2011, 01:56:08 AM
I have no reward from the last 6 blocks.
Granted I only mine at 200 M/hash but usually I get something...
Granted I only mine at 200 M/hash but usually I get something...
7 blocks with no reward now.. any idea what is going on?
Ok finally getting rewards
June 22, 2011, 01:23:11 AM
I have no reward from the last 6 blocks.
Granted I only mine at 200 M/hash but usually I get something...
Granted I only mine at 200 M/hash but usually I get something...
7 blocks with no reward now.. any idea what is going on?
June 22, 2011, 12:54:59 AM
I have no reward from the last 6 blocks.
Granted I only mine at 200 M/hash but usually I get something...
Granted I only mine at 200 M/hash but usually I get something...
June 22, 2011, 12:31:14 AM
weird, I see this too.
But they point to different blockexplorer addresses, and one shows no such block.
Something else:
Is there still ddos attacks going on? because sometimes my miners stop for a moment
with workque empty. I am not sure if this is maybe my internet connection.
But they point to different blockexplorer addresses, and one shows no such block.
Something else:
Is there still ddos attacks going on? because sometimes my miners stop for a moment
with workque empty. I am not sure if this is maybe my internet connection.
June 21, 2011, 11:42:16 PM
And for block 132468 also?
What's going on here?
What's going on here?
June 21, 2011, 11:25:27 PM
How come there are two entries for block 132473???
This looks fishy...
This looks fishy...
June 21, 2011, 05:18:53 PM
Phoenix miners working, both GPUs.... must be GUIMiner. Gonna delete, then re-extract.
[edit] Fixed. had to create new openCL miners and re-extract. Seems some settings got jumbled up
[edit] Fixed. had to create new openCL miners and re-extract. Seems some settings got jumbled up
Hm, really crazy. Great that you fixed it.
June 21, 2011, 04:22:18 PM
Phoenix miners working, both GPUs.... must be GUIMiner. Gonna delete, then re-extract.
[edit] Fixed. had to create new openCL miners and re-extract. Seems some settings got jumbled up
[edit] Fixed. had to create new openCL miners and re-extract. Seems some settings got jumbled up
June 21, 2011, 04:08:12 PM
Just got back....
Yes I can ping. Yes ends in .32. Its still doing it... Noooo idea why. Tried updating GUI miner, still does it.
Im gonna see if phoenix miner does it to after im done a few things.
And I have only one machine running mining so far, its 2 GPUs on a single card: a 5970.
If I switch both to deepbit, it looks fine. Just cypress[0] does not want to connect to slush.
still running cypress[0] on deepbit and cypress[1] on slush - no problems w/ that.
Yes I can ping. Yes ends in .32. Its still doing it... Noooo idea why. Tried updating GUI miner, still does it.
Im gonna see if phoenix miner does it to after im done a few things.
And I have only one machine running mining so far, its 2 GPUs on a single card: a 5970.
If I switch both to deepbit, it looks fine. Just cypress[0] does not want to connect to slush.
still running cypress[0] on deepbit and cypress[1] on slush - no problems w/ that.
Jump to: