Topic: [~1000 GH/sec] BTC Guild - 0% Fee Pool, LP, SSL, Full Precision, and More - page 29. (Read 379076 times)
July 28, 2011, 10:30:56 AM
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?
July 28, 2011, 09:46:37 AM
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.
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.
July 28, 2011, 09:12:27 AM
IT DOESN'T MATTER!!!!!!
5000 1 Mh/s miners == 1 5 Gh/s miner in likelihood of finding a block
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.
July 28, 2011, 08:49:53 AM
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.
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
July 28, 2011, 05:33:48 AM
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.
July 28, 2011, 03:42:19 AM
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...
July 27, 2011, 07:47:46 PM
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.
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.
July 27, 2011, 07:43:00 PM
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.
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.
July 27, 2011, 07:40:16 PM
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.
Did something change with API/JSON setup? My Android Miner widget stopped working for BTC guild several days ago.
July 27, 2011, 02:22:56 PM
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:
July 27, 2011, 02:18:59 PM
I can confirm its fixed now. Payout wan'tworking for me.. is now.
Thanks for the quick reply.
Thanks for the quick reply.
July 27, 2011, 02:15:24 PM
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.
"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.
July 27, 2011, 02:14:55 PM
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.
July 27, 2011, 02:06:11 PM
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.
"An error occurred while processing your payout, please try again."
Seems to be an issue on your side, eleuthria.
July 27, 2011, 01:55:27 PM
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.
July 27, 2011, 01:51:15 PM
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
That isn't true at all.
July 27, 2011, 01:48:27 PM
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
July 27, 2011, 01:33:04 PM
uswest.btcguild.com:8332 27/07/2011 14:31:29, long poll: new block 0000062ecebd55d7
uswest.btcguild.com:8332 27/07/2011 14:31:35, long poll: IO error
I started seeing IO errors for the first time today... me or you?
uswest.btcguild.com:8332 27/07/2011 14:31:35, long poll: IO error
I started seeing IO errors for the first time today... me or you?
July 27, 2011, 01:10:59 PM
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.
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.
July 27, 2011, 01:02:13 PM
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.
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.
Jump to: