[~1000 GH/sec] BTC Guild - 0% Fee Pool, LP, SSL, Full Precision, and More

[foolofyork]

Getting this error when trying to request payout:

"An error occurred while processing your payout, please try again."

Seems to be an issue on your side, eleuthria.

[farfiman]

  Like I said in my last post, everybody "questions" the bad, and ignores the good.  Anybody making the claim that our -14% this difficulty is unusual and not raising the same questions about DeepBit's positive 13.6% during this difficulty is a hypocrite.  If you want to believe that pool speed will eliminate the chance of variance "that high", then it's more than twice as unlikely for DeepBit to be pushing that luck as it is for us.

If the guild has -14%  someone has the +14...   just so happens most is at deepbit

Not true. The network as a whole can have good or bad luck.

I wasnt giving EXACT numbers.. but the variance on the total network should keep it closer to 0% luck  most of the time.

[eleuthria]

Getting this error when trying to request payout:

"An error occurred while processing your payout, please try again."

Seems to be an issue on your side, eleuthria.

Payouts fixed, I've been having to restart the webserver quickly about once a day until the weekend when I can setup a new VM for the webserver, bitcoind didn't launch when it rebooted.

[dyngnosis]

I can confirm its fixed now.  Payout wan'tworking for me.. is now.

Thanks for the quick reply.

[hugolp]

I wasnt giving EXACT numbers.. but the variance on the total network should keep it closer to 0% luck  most of the time.

While some of the changes on this graph could be due to people starting and stopping their miners, a lot of it is due to variance of the whole network:

[dosboss]

So many people here could benefit from a class on statistics.

Did something change with API/JSON setup? My Android Miner widget stopped working for BTC guild several days ago.

[dyngnosis]

So many people here could benefit from a class on statistics.

Did something change with API/JSON setup? My Android Miner widget stopped working for BTC guild several days ago.

The stats have been delayed by an hour... output has changed.

[btcbaby]

Perhaps it's on my end, but Im not sure.

My miners have been getting a lot of idles over 8 secs in duration and my setting makes them restart, after it occurs 2 times within 2 minutes they go to backup pool for 8 minutes. Is there anything wrong with the servers? Im using win7 32bit, AOCLBF with Phoenix 1.5, and the 7-17-11 PhatK Kernel, my gfx's seem to run stable, but yeah a lot of restarts and idles.. and I think 8 secs idle before restarting is a long time already, am I wrong? Should I use other settings?
Thanks in advance for any advice.

It looks like US Central had a few minutes of connectivity issues for some people.  Nothing hardware/software related, and seems to have already ended.

Only 8% of the pool is above 2Gh/s.  That can't be good for solving blocks at this difficulty.

[farfiman]

I wasnt giving EXACT numbers.. but the variance on the total network should keep it closer to 0% luck  most of the time.

While some of the changes on this graph could be due to people starting and stopping their miners, a lot of it is due to variance of the whole network:

This graph is about network speed...  weren't we talking about network luck? or am i just ignorant...

[hugolp]

This graph is about network speed...  weren't we talking about network luck? or am i just ignorant...

As far as I know (and please someone correct me if wrong), that graph aproximates the speed of the network from time it takes to the network to find the blocks. So it is influenced by people adding and removing workers, but the temporal swings are also influenced by the luck of the network.

Its imposible for anyone to know the real speed of each miner, not even the pools can know the real speed of the miners connected to them and approximate by the number of shares that each miner contributes. Same with that page and the blocks the whole network produces.

[sirky]

Perhaps it's on my end, but Im not sure.

My miners have been getting a lot of idles over 8 secs in duration and my setting makes them restart, after it occurs 2 times within 2 minutes they go to backup pool for 8 minutes. Is there anything wrong with the servers? Im using win7 32bit, AOCLBF with Phoenix 1.5, and the 7-17-11 PhatK Kernel, my gfx's seem to run stable, but yeah a lot of restarts and idles.. and I think 8 secs idle before restarting is a long time already, am I wrong? Should I use other settings?
Thanks in advance for any advice.

It looks like US Central had a few minutes of connectivity issues for some people.  Nothing hardware/software related, and seems to have already ended.

Only 8% of the pool is above 2Gh/s.  That can't be good for solving blocks at this difficulty.

IT DOESN'T MATTER!!!!!!

5000 1 Mh/s miners == 1 5 Gh/s miner in likelihood of finding a block

[Xephan]

IT DOESN'T MATTER!!!!!!

5000 1 Mh/s miners == 1 5 Gh/s miner in likelihood of finding a block

I'm going to say that it matters because of latencies.

A worker requests for a few pieces of work per getwork by default, let's say 6. If it takes a 100MH/s miner 10 seconds on the average to finish 1 share and the winning work was number 6, it would be 1 minute before the worker sends back a what should be the winning share.

If the 1 GH/s miner got the same set of work, it would be 6 seconds before it finds the winning block.

So although on pure hash rate alone, a network with 100x 0.1GH/s workers should have the same chance as 10x 1GH/s user, the latencies gives the pool with faster average workers a slight edge.

I'm testing this hypothesis by checking the blocks found since the past 85 hours or so. The top few pools has about 81% of the network hash rate but account for 91% of found blocks. If probability of finding a block is equal per MHash holds true, then we should see 81% of hashrate finding around 81% of blocks. But as it is, it's a significant 10% gap.

[kjj]

I'm going to say that it matters because of latencies.

A worker requests for a few pieces of work per getwork by default, let's say 6. If it takes a 100MH/s miner 10 seconds on the average to finish 1 share and the winning work was number 6, it would be 1 minute before the worker sends back a what should be the winning share.

If the 1 GH/s miner got the same set of work, it would be 6 seconds before it finds the winning block.

So although on pure hash rate alone, a network with 100x 0.1GH/s workers should have the same chance as 10x 1GH/s user, the latencies gives the pool with faster average workers a slight edge.

I'm testing this hypothesis by checking the blocks found since the past 85 hours or so. The top few pools has about 81% of the network hash rate but account for 91% of found blocks. If probability of finding a block is equal per MHash holds true, then we should see 81% of hashrate finding around 81% of blocks. But as it is, it's a significant 10% gap.

You don't see any flaws in your analysis?  Here are two that are instantly obvious to me.

1) You are double counting.  There is no measurement of hashing speed, just an estimate.  Stale shares (the end result of latency) are already not factored into the speed estimates.

2) Your argument is circular.  You have no knowledge about the distribution of hashing rates within the pools, but you assume that bigger pools have higher average speeds, and then you count that assumption as a confirmation.

[Dargo]

I don't see why it's going to matter. Suppose you have one individual with a 40 Ghps cluster (say 100 5870s) mining at pool x. At pool y, you have 100 individuals minining at 400 Mhps (1 5870 each). Either way, each 5870 is an individual worker, and will be communicating with the pool individually. Either way, the pool is communicating with 100 5870s, and the only difference is that at pool x all 100 are tied to the same account while at pool y there are 100 accounts, but I don't see why this would make any difference. Am I overlooking/not understanding something?

[jjiimm_64]

On top of the everything you guys are discussing,  I have noticed that  I get up to 10% difference in accepted shares with the same hashrate


cardx  400Mh  get 1000 accepted shares
cardy  400Mh  gets 910 accepted shares


my point is that it is not just hash rate that counts.


cma:  I am way behind you guys in understanding all this!

[Xephan]

1) You are double counting.  There is no measurement of hashing speed, just an estimate.  Stale shares (the end result of latency) are already not factored into the speed estimates.

I don't see the relevance here. It's not like I'm scoring the pools based on their estimated hash rate and deducting points for stales.
If anything, stales are just an indication of what I mean, just that I'm talking about a particular stale -> the winning share that became stale/invalid.

2) Your argument is circular.  You have no knowledge about the distribution of hashing rates within the pools, but you assume that bigger pools have higher average speeds, and then you count that assumption as a confirmation.

Claiming every MHash is equal is also making assumptions, assumptions about each individual miner's network speed, each pool's network speed being equal. When working with large enough numbers, things tend to follow a similar distribution so usually assumptions are made. As long as the assumptions are reasonable and applied equally, then it's a valid basis until proven wrong.

Since this is a hypothesis, I wouldn't be surprised to be wrong in either the hypothesis or assumptions leading to it but you've got to at least put some data on the table to convince me otherwise you know

[dyngnosis]

<sarcasm>

It appears that E is scamming us... he is clearly adding solving blocks on his own and giving them to us...

24 Hour Luck       +9.2%

</sarcasm>

woohoo!

[sirky]

I don't see why it's going to matter. Suppose you have one individual with a 40 Ghps cluster (say 100 5870s) mining at pool x. At pool y, you have 100 individuals minining at 400 Mhps (1 5870 each). Either way, each 5870 is an individual worker, and will be communicating with the pool individually. Either way, the pool is communicating with 100 5870s, and the only difference is that at pool x all 100 are tied to the same account while at pool y there are 100 accounts, but I don't see why this would make any difference. Am I overlooking/not understanding something?

It still shouldn't matter. If there was one account with an uber video card at 4 Gh/s and another account with 4000 celeron cpu miners at 1 Mh/s, assuming the pool can push work to all of them in the same amount of time (honestly probably not realistic), they should each have an equal shot of finding a block. Shares don't really matter, it is the hashing the matters. Shares are just when you happen to solve a block of difficulty 1.

Saying something like 'well assume that the block will be found on share 6' isn't really a good argument, because we can never assume something like that.

[Xephan]

On top of the everything you guys are discussing,  I have noticed that  I get up to 10% difference in accepted shares with the same hashrate


cardx  400Mh  get 1000 accepted shares
cardy  400Mh  gets 910 accepted shares


my point is that it is not just hash rate that counts.


cma:  I am way behind you guys in understanding all this!

For me, I get higher stales on my slower card, that's why I'm thinking along the lines that the latencies count for something. Not a direct 1 to 1 correlation since that would make a huge difference but just enough cases to cause a divergent in the expected blocks found per pool per GH/s vs reality.

After all, if every MHash is equal, why is there a consistent difference? It's been a 10% gap since day 1 and 3 days later, it's still 10%.

I would write a script to crawl through further blocks to get a better basis but without historical data on pool hash rate, it's not useful just to know which pool found what.

[Xephan]

Saying something like 'well assume that the block will be found on share 6' isn't really a good argument, because we can never assume something like that.

6 can be substituted with any number and the result will still be the same for two pools with equal total hash rate but one has faster average workers than the other.