Bitcoin Forum
December 09, 2016, 01:54:37 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 [131] 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 »
  Print  
Author Topic: [~1000 GH/sec] BTC Guild - 0% Fee Pool, LP, SSL, Full Precision, and More  (Read 359139 times)
hugolp
Hero Member
*****
Offline Offline

Activity: 742



View Profile
July 27, 2011, 06:55:27 PM
 #2601


  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.
1481291677
Hero Member
*
Offline Offline

Posts: 1481291677

View Profile Personal Message (Offline)

Ignore
1481291677
Reply with quote  #2

1481291677
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481291677
Hero Member
*
Offline Offline

Posts: 1481291677

View Profile Personal Message (Offline)

Ignore
1481291677
Reply with quote  #2

1481291677
Report to moderator
1481291677
Hero Member
*
Offline Offline

Posts: 1481291677

View Profile Personal Message (Offline)

Ignore
1481291677
Reply with quote  #2

1481291677
Report to moderator
1481291677
Hero Member
*
Offline Offline

Posts: 1481291677

View Profile Personal Message (Offline)

Ignore
1481291677
Reply with quote  #2

1481291677
Report to moderator
foolofyork
Newbie
*
Offline Offline

Activity: 13


View Profile
July 27, 2011, 07:06:11 PM
 #2602

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
Legendary
*
Offline Offline

Activity: 1434



View Profile
July 27, 2011, 07:14:55 PM
 #2603


  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.

"We are just fools. We insanely believe that we can replace one politician with another and something will really change. The ONLY possible way to achieve change is to change the very system of how government functions. Until we are prepared to do that, suck it up for your future belongs to the madness and corruption of politicians."
Martin Armstrong
eleuthria
Legendary
*
Offline Offline

Activity: 1750


BTC Guild Owner


View Profile WWW
July 27, 2011, 07:15:24 PM
 #2604

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.

R.I.P. BTC Guild, 2011 - 2015.
BTC Guild Forum Thread
dyngnosis
Jr. Member
*
Offline Offline

Activity: 30


View Profile
July 27, 2011, 07:18:59 PM
 #2605

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

Thanks for the quick reply.
hugolp
Hero Member
*****
Offline Offline

Activity: 742



View Profile
July 27, 2011, 07:22:56 PM
 #2606

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
Newbie
*
Offline Offline

Activity: 8



View Profile
July 28, 2011, 12:40:16 AM
 #2607

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.

Send me free money at 12PdxVLB8T9c8BKz8B24gHdGHFVDHyXTaD
dyngnosis
Jr. Member
*
Offline Offline

Activity: 30


View Profile
July 28, 2011, 12:43:00 AM
 #2608

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
Member
**
Offline Offline

Activity: 87



View Profile WWW
July 28, 2011, 12:47:46 AM
 #2609

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.

http://www.btclog.com/uploads/FileUpload/e6/9cc97eb4c91db1ec5fb30ca35f0da8.png
Write an excellent post on btc::log and you just might win 1BTC in our daily giveaway.
btc::log is the professionally managed and community moderated Bitcoin Forum
farfiman
Legendary
*
Offline Offline

Activity: 1434



View Profile
July 28, 2011, 08:42:19 AM
 #2610

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...

"We are just fools. We insanely believe that we can replace one politician with another and something will really change. The ONLY possible way to achieve change is to change the very system of how government functions. Until we are prepared to do that, suck it up for your future belongs to the madness and corruption of politicians."
Martin Armstrong
hugolp
Hero Member
*****
Offline Offline

Activity: 742



View Profile
July 28, 2011, 10:33:48 AM
 #2611

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
Sr. Member
****
Offline Offline

Activity: 407



View Profile
July 28, 2011, 01:49:53 PM
 #2612

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
Jr. Member
*
Offline Offline

Activity: 42


View Profile
July 28, 2011, 02:12:27 PM
 #2613

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.

186q9YUW3x8TVHC5aYBEqgZZYMxft8Cw9f
kjj
Legendary
*
Offline Offline

Activity: 1302



View Profile
July 28, 2011, 02:46:37 PM
 #2614

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.


p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
Dargo
Legendary
*
Offline Offline

Activity: 1554



View Profile
July 28, 2011, 03:30:56 PM
 #2615

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
Legendary
*
Offline Offline

Activity: 1680


View Profile
July 28, 2011, 03:48:32 PM
 #2616


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!

1jimbitm6hAKTjKX4qurCNQubbnk2YsFw
Xephan
Jr. Member
*
Offline Offline

Activity: 42


View Profile
July 28, 2011, 03:48:56 PM
 #2617

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.

Quote
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 Cheesy

186q9YUW3x8TVHC5aYBEqgZZYMxft8Cw9f
dyngnosis
Jr. Member
*
Offline Offline

Activity: 30


View Profile
July 28, 2011, 03:51:22 PM
 #2618

<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
Sr. Member
****
Offline Offline

Activity: 407



View Profile
July 28, 2011, 03:52:11 PM
 #2619

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
Jr. Member
*
Offline Offline

Activity: 42


View Profile
July 28, 2011, 03:53:15 PM
 #2620


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.

186q9YUW3x8TVHC5aYBEqgZZYMxft8Cw9f
Pages: « 1 ... 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 [131] 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!