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

[heavyb]

seems to be fixed.

[smackdaddy]

My miners are also going idle often with BTCguild.

Fortunately, pheonix rising allows me to tell them to reconnect if idle for 10 seconds, and this keeps them chugging along pretty well even with the frequent issues.

[Serge]

Connection problems persisted through the night and it still drops out constantly today

I'm on the east coast

[heavyb]

says they are adding more servers today. had 800-900 ghs growth last week that they were not prepared for.

[Sebz4n]

My miners keep having connection problems, what's going on? Will this get fixed soon or what? I'm not gonna keep donating 2,5% if I can't mine -.-'

2011-06-13 15:42:15: Listener for "Guild Prim": 13/06/2011 15:42:15, warning: job finished, miner is idle
2011-06-13 15:42:28: Listener for "Guild Prim": 13/06/2011 15:42:28, Problems communicating with bitcoin RPC
2011-06-13 15:59:08: Listener for "Guild Prim": 13/06/2011 15:59:08, warning: job finished, miner is idle
2011-06-13 15:59:13: Listener for "Guild Sec": 13/06/2011 15:59:13, Problems communicating with bitcoin RPC
2011-06-13 15:59:13: Listener for "Guild Prim": 13/06/2011 15:59:13, Problems communicating with bitcoin RPC
2011-06-13 16:11:32: Listener for "Guild Sec": 13/06/2011 16:11:32, long poll exception:
2011-06-13 16:11:32: Listener for "Guild Prim": 13/06/2011 16:11:32, long poll exception:
2011-06-13 16:12:25: Listener for "Guild Prim": Verification failed, check hardware!
2011-06-13 16:12:25: Listener for "Guild Prim": Traceback (most recent call last):
2011-06-13 16:12:25: Listener for "Guild Prim": File "BitcoinMiner.pyo", line 261, in longPollThread
2011-06-13 16:12:25: Listener for "Guild Prim": File "BitcoinMiner.pyo", line 224, in request
2011-06-13 16:12:25: Listener for "Guild Prim": File "httplib.pyo", line 974, in getresponse
2011-06-13 16:12:25: Listener for "Guild Prim": File "httplib.pyo", line 391, in begin
2011-06-13 16:12:25: Listener for "Guild Prim": File "httplib.pyo", line 355, in _read_status
2011-06-13 16:12:25: Listener for "Guild Prim": BadStatusLine
2011-06-13 16:16:13: Listener for "Guild Sec": 13/06/2011 16:16:13, Problems communicating with bitcoin RPC

[heavyb]

yea, it is back to idleing for me as well. Any update from the systems manager on how long this will take to resolve? if it is going to take a few days im going to move to deepbit until it is fixed.

[fcmatt]

yea, it is back to idleing for me as well. Any update from the systems manager on how long this will take to resolve? if it is going to take a few days im going to move to deepbit until it is fixed.

well i had to completely close guiminer and restart it to resolve my issue. i just have to wonder if the problem will pop
back up in an hour. just does not seem logical to me because when i stop and then restart the miner it just runs a new
copy of pocblm (whatever)...

if one has too many people joining at the moment perhaps the admin should not allow new accounts until
the capacity issue is resolved? just a suggestion.

[warsmith]

perhaps the admin should not allow new accounts until
the capacity issue is resolved? just a suggestion.

Yeah,  but I'd prefer those new servers getting online quicker.
It's annoying to see miners idle 10s out of each minute.

[eleuthria]

perhaps the admin should not allow new accounts until
the capacity issue is resolved? just a suggestion.

Yeah,  but I'd prefer those new servers getting online quicker.
It's annoying to see miners idle 10s out of each minute.

Quicker?  I completely changed the design of pushpool to allow a multiple server system, and put 3 new servers online in one week.  There was absolutely no way to prepare for a following spike of a 900 GH/sec GROWTH in under a week.  This pool has been around for barely over one month, and has only recently started to produce enough money to actually pay for anything.  Unlike Tycho, this pool hasn't allowed me the privilege of quitting my day job.

US Central is expected to come up soon.  A new server is also being setup to handle the web traffic and get that load off of US West.

I am also looking into getting two cheaper servers specifically for load balancing US and EU, to get the speeds split more evenly between the 4, soon to be 5 or 6 servers.

[heavyb]

any idea how long until the issue is resolved?

[eleuthria]

any idea how long until the issue is resolved?

If the Chicago server is online by the time I get off work, it will be added to the available pool servers tonight.  The next step is getting US West (pool) separated from the web interface.  Then getting a load balancing server US side, and once that is proven to work properly, an additional load balancing server for the EU side.

[heavyb]

any idea how long until the issue is resolved?

If the Chicago server is online by the time I get off work, it will be added to the available pool servers tonight.  The next step is getting US West (pool) separated from the web interface.  Then getting a load balancing server US side, and once that is proven to work properly, an additional load balancing server for the EU side.

thanks for the hard work! I will continue to use BTC guild with 2.5% donation!

[TheMoneyStorm]

eleuthria, Man you just keep doing what your doing, Your doing a fantastic job. People have no concept of all that you've accomplished in the last week. Keep up the awesome work.

[Carnth]

First off, what exactly is the "stale" count? What is an average stale count for a round or per some period of time? How do I prevent them? Thank you for the help

This post will help people new to Bitcoins get up to speed. Everyone else can skip it (or read it for a refresher).

Bitcoins are created by "solving a block." A "Block" is just a collection of Bitcoin transactions that have been hashed and added to the official chain of Bitcoin blocks. The "confirmations" the you get when you send or receive a transaction is the result of your transaction being hashed and included in the block chain.
Since solving a block is so difficult, you get a reward for doing so... 50 Bitcoins.

How do I solve a block?
To complete a new block your computer running mining software tries to guess the hash of the new block based off the hash of the old block. You aren't really computing the answer to an equation per say. You are just making a guess.
In fact, it helps to look at this like buying lottery tickets. The chances of winning the lottery are low, but  you can increase you odds if you buy more tickets.
Your miners compute hashes against the current block and when it thinks it has a potential winner, it submits it as a share. Hashes are generally measured in number of Mhases/sec or Ghashes/sec. This would be millions of hashes per second or billions of hashes per second (respectively). For example an Average ATI 5770 video card can compute roughly 150 to 200 Mhash/sec dependly on how you configure it.
The share you submitted is sent across the entire peer-to-peer Bitcoin network. All peers must agree if a share is the winner.

It's a lottery.
The percent chance that a single hash will be the winner is currently: 0.0000000000000004104346 or about 410,000,000,000,000 to 1.
This changes about every two weeks and is expected to get even tougher.
Even though the odds are so high, there is a potential for two clients to submit a winning share at the same time. When this happens, the Bitcoin peer-to-peer network choses the definitive winner. The loser's block is then declared invalid. Invalid blocks are a rare occurrence, but it does happen.

Mining Pools
Since the probability of the average home computer to find the correct hash is so slim, people have started to "pool" their resources together--in much the same way an office might buy several lottery tickets together.
You along with all the others in the pool submit shares. When a block is solved among one of the pool members, the 50 Bitcoin reward is split among all those who submitted shares during that block. The more shares you submit, the larger your portion of the reward.
Pools are operated by groups, or individuals and are kept alive by taking a small cut of your profits (usually a fee of about 3%).

Bad Things - Stale Shares and Idles
When you belong to a pool, you are trying to solve a block that the pool has relayed to you:

• The Pool gets the current block from the Peer-to-peer Bitcoin network.
• It sends your miner that information.
• Your miner works on it.
• Your miner submits shares it thinks will be potential winners.

If a block is solved elsewhere on the Bitcoin network, the pool must tell you miner to stop what it is doing and start work on the new block.
If your miner does not get this new block information, it will continue to work on submitting shares for the previous block. When this happens, your shares are stale and do not count for anything.
If the pool does not send any block information to your miner, it will become idle and not do anything (not contributing).
The best way to fix any of these problems on the miner end is to stop--and restart the miner software. It will then submit a new request for new block information from the pool.

BTC Guild
To keep this on topic.....
The BTC Guild mining pool was created (founded?) by eleuthria. He has committed countless hours and many of his personal resources to bring the fastest growing Bitcoin mining pool in the world.
Of of this writing it is also the second largest pool in the world.
eleuthria has made numerous enhancements to the pool in the short months that it has been in existence. However, most of his time lately has been trying to keep up with the explosive growth of the pool. And when I say "explosive" I think one of his early servers has actually melted. (I may or may not be making up that last statement.)
The number one reason the pool is so popular is that this is the only pool that I know of where the fee is optional. You can choose how much or how little of a fee to pay.
That's right, you can join the pool for absolutely free if you want to. However, you get perks for paying a fee. And the more you pay, the more perks you get! 
Get all the perks for paying a fee of 2.5% or more. This is still a great value compared to other pools.

• At 0% fee (the default) you can join the pool and get paid based on the number of shares you submit. When the pool solves a block, you get paid your portion after 120 confirmations.
• At 2% you can setup Idle miner email warnings. If you miner(s) stop submitting shares for some reason, you can be notified by email.
• At 2.5% you get the above. AND you get paid immediately when a block is solved. You don't have to wait for 120 confirmations. AND you get paid even if the block later becomes invalid.

It's the best pool I have seen. The community is great and the maintainer, eleuthria, is extremely active. You can reach him right on this discussion in the forum, or on IRC chat (#btcguild on FreeNode).


If you found this helpful and feel generous, a gratuity would be appreciated at: 1JJjL5nxzBfjFjJWoviU9mzrY3fQKxJfvV

[IamFuzzles]

First off, what exactly is the "stale" count? What is an average stale count for a round or per some period of time? How do I prevent them? Thank you for the help

This post will help people new to Bitcoins get up to speed. Everyone else can skip it (or read it for a refresher).

Bitcoins are created by "solving a block." A "Block" is just a collection of Bitcoin transactions that have been hashed and added to the official chain of Bitcoin blocks. The "confirmations" the you get when you send or receive a transaction is the result of your transaction being hashed and included in the block chain.
Since solving a block is so difficult, you get a reward for doing so... 50 Bitcoins.

How do I solve a block?
To complete a new block your computer running mining software tries to guess the hash of the new block based off the hash of the old block. You aren't really computing the answer to an equation per say. You are just making a guess.
In fact, it helps to look at this like buying lottery tickets. The chances of winning the lottery are low, but  you can increase you odds if you buy more tickets.
Your miners compute hashes against the current block and when it thinks it has a potential winner, it submits it as a share. Hashes are generally measured in number of Mhases/sec or Ghashes/sec. This would be millions of hashes per second or billions of hashes per second (respectively). For example an Average ATI 5770 video card can compute roughly 150 to 200 Mhash/sec dependly on how you configure it.
The share you submitted is sent across the entire peer-to-peer Bitcoin network. All peers must agree if a share is the winner.

It's a lottery.
The percent chance that a single hash will be the winner is currently: 0.0000000000000004104346 or about 410,000,000,000,000 to 1.
This changes about every two weeks and is expected to get even tougher.
Even though the odds are so high, there is a potential for two clients to submit a winning share at the same time. When this happens, the Bitcoin peer-to-peer network choses the definitive winner. The loser's block is then declared invalid. Invalid blocks are a rare occurrence, but it does happen.

Mining Pools
Since the probability of the average home computer to find the correct hash is so slim, people have started to "pool" their resources together--in much the same way an office might buy several lottery tickets together.
You along with all the others in the pool submit shares. When a block is solved among one of the pool members, the 50 Bitcoin reward is split among all those who submitted shares during that block. The more shares you submit, the larger your portion of the reward.
Pools are operated by groups, or individuals and are kept alive by taking a small cut of your profits (usually a fee of about 3%).

Bad Things - Stale Shares and Idles
When you belong to a pool, you are trying to solve a block that the pool has relayed to you:

• The Pool gets the current block from the Peer-to-peer Bitcoin network.
• It sends your miner that information.
• Your miner works on it.
• Your miner submits shares it thinks will be potential winners.

If a block is solved elsewhere on the Bitcoin network, the pool must tell you miner to stop what it is doing and start work on the new block.
If your miner does not get this new block information, it will continue to work on submitting shares for the previous block. When this happens, your shares are stale and do not count for anything.
If the pool does not send any block information to your miner, it will become idle and not do anything (not contributing).
The best way to fix any of these problems on the miner end is to stop--and restart the miner software. It will then submit a new request for new block information from the pool.

BTC Guild
To keep this on topic.....
The BTC Guild mining pool was created (founded?) by eleuthria. He has committed countless hours and many of his personal resources to bring the fastest growing Bitcoin mining pool in the world.
Of of this writing it is also the second largest pool in the world.
eleuthria has made numerous enhancements to the pool in the short months that it has been in existence. However, most of his time lately has been trying to keep up with the explosive growth of the pool. And when I say "explosive" I think one of his early servers has actually melted. (I may or may not be making up that last statement.)
The number one reason the pool is so popular is that this is the only pool that I know of where the fee is optional. You can choose how much or how little of a fee to pay.
That's right, you can join the pool for absolutely free if you want to. However, you get perks for paying a fee. And the more you pay, the more perks you get! 
Get all the perks for paying a fee of 2.5% or more. This is still a great value compared to other pools.

• At 0% fee (the default) you can join the pool and get paid based on the number of shares you submit. When the pool solves a block, you get paid your portion after 120 confirmations.
• At 2% you can setup Idle miner email warnings. If you miner(s) stop submitting shares for some reason, you can be notified by email.
• At 2.5% you get the above. AND you get paid immediately when a block is solved. You don't have to wait for 120 confirmations. AND you get paid even if the block later becomes invalid.

It's the best pool I have seen. The community is great and the maintainer, eleuthria, is extremely active. You can reach him right on this discussion in the forum, or on IRC chat (#btcguild on FreeNode).


If you found this helpful and feel generous, a gratuity would be appreciated at: 1JJjL5nxzBfjFjJWoviU9mzrY3fQKxJfvV

That was extremely helpful, thanks a lot. Most of it I understood, but could not figure out what the stale shares meant. Once I get some btc, I'll be sending you a small tip for your trouble.

[Carnth]

Quicker?  

eleuthria, you are doing a fantastic job. We know this is not your primary job and are working on the pool every chance you get.
We, the mining public, can be patient while you work on setting up your fifth server in less than a month.

To all BTC Guild miners:
You will experience some problems when the new server is put online. There is no way to avoid it. All the servers must be in sync and there is no way to do that without some service interruptions.

While BTC Guild is growing, consider setting up a "back-up" pool.

You can configure your miner to mine at a backup pool especially if you use poclbm.exe.
Run two instances of poclbm per GPU. Use the "f" command to give one pool priority over another. The lower the "f" value, the higher the priority.
-f30 to one pool will have priority over -f60 on a second pool.
This will split your GPU processing power to about 92% | 8% between the two pools. If one pool is idle, poclbm will automatically shift your mining power to the backup. This is even easier to setup and monitor using guiminer.
This has worked flawlessly for me and has always kept my GPUs at 100% through BTC Guild's growing pains.

[IamFuzzles]

Quicker?  

eleuthria, you are doing a fantastic job. We know this is not your primary job and are working on the pool every chance you get.
We, the mining public, can be patient while you work on setting up your fifth server in less than a month.

To all BTC Guild miners:
You will experience some problems when the new server is put online. There is no way to avoid it. All the servers must be in sync and there is no way to do that without some service interruptions.

While BTC Guild is growing, consider setting up a "back-up" pool.

You can configure your miner to mine at a backup pool especially if you use poclbm.exe.
Run two instances of poclbm per GPU. Use the "f" command to give one pool priority over another. The lower the "f" value, the higher the priority.
-f30 to one pool will have priority over -f60 on a second pool.
This will split your GPU processing power to about 92% | 8% between the two pools. If one pool is idle, poclbm will automatically shift your mining power to the backup. This is even easier to setup and monitor using guiminer.
This has worked flawlessly for me and has always kept my GPUs at 100% through BTC Guild's growing pains.

How exactly do you do this? I've been trying to figure it out with no luck so far.

[Carnth]

You can configure your miner to mine at a backup pool especially if you use poclbm.exe.
Run two instances of poclbm per GPU. Use the "f" command to give one pool priority over another. The lower the "f" value, the higher the priority.
-f30 to one pool will have priority over -f60 on a second pool.
This will split your GPU processing power to about 92% | 8% between the two pools. If one pool is idle, poclbm will automatically shift your mining power to the backup. This is even easier to setup and monitor using guiminer.
This has worked flawlessly for me and has always kept my GPUs at 100% through BTC Guild's growing pains.

How exactly do you do this? I've been trying to figure it out with no luck so far.

If you are using command line poclbm.exe (and an ATI/AMD based video card) try this:

Code:

poclbm.exe --user=username_workername --pass=password -o btcguild.com -p 8332 -d0 --verbose -v -w128 -f30

And then run poclbm.exe again with you other pool worker sign-on info.

Code:

poclbm.exe --user=username --pass=password -o other.pool.address -p 8332 -d0 --verbose -v -w128 -f60

If you are using GUIminer (adn ATI/AMD video cards) do this:

• Go to "File" menu and choose "New OpenCL miner"
• A pop-up windows will appear to name the miner. You can name it what even you want. I named it "Guild."
• This will create a new tab in the GUIminer window. Click on it so we can start configuring.
• In the "Server dropdown box, choose "BTC Guild."
• In the Username box, type in your username_workername. Fill in your password in the password box.
• In the Device name, choose your GPU. If you have multiple GPUs, they will be listed in there. They are numbered starting with 0. You will also see your CPU as a usable device. (This is a hint that you can use your CPU to mine, but it will slow your system to a crawl.)
• In the "Extra Flags" box you can type in:
  

Code:

-v -w128 -f30

• You can tweak these numbers to try to get as many Mhash/sec as you can.
• Remember to go back to the "File" menu and "Save Settings"

Now, repeat these steps again. This time using a different pool. When you get to "Device" just use the same device again.
In the "extra flags" box, just use -f60  or any higher number.


The main point is to use two miner per GPU. If you have 2 video cards, setup 4 miners.

If you found this helpful and feel generous, a gratuity would be appreciated at: 1JJjL5nxzBfjFjJWoviU9mzrY3fQKxJfvV

[IamFuzzles]

You can configure your miner to mine at a backup pool especially if you use poclbm.exe.
Run two instances of poclbm per GPU. Use the "f" command to give one pool priority over another. The lower the "f" value, the higher the priority.
-f30 to one pool will have priority over -f60 on a second pool.
This will split your GPU processing power to about 92% | 8% between the two pools. If one pool is idle, poclbm will automatically shift your mining power to the backup. This is even easier to setup and monitor using guiminer.
This has worked flawlessly for me and has always kept my GPUs at 100% through BTC Guild's growing pains.

How exactly do you do this? I've been trying to figure it out with no luck so far.

If you are using command line poclbm.exe (and an ATI/AMD based video card) try this:

Code:

poclbm.exe --user=username_workername --pass=password -o btcguild.com -p 8332 -d0 --verbose -v -w128 -f30

And then run poclbm.exe again with you other pool worker sign-on info.

Code:

poclbm.exe --user=username --pass=password -o other.pool.address -p 8332 -d0 --verbose -v -w128 -f60

If you are using GUIminer (adn ATI/AMD video cards) do this:

• Go to "File" menu and choose "New OpenCL miner"
• A pop-up windows will appear to name the miner. You can name it what even you want. I named it "Guild."
• This will create a new tab in the GUIminer window. Click on it so we can start configuring.
• In the "Server dropdown box, choose "BTC Guild."
• In the Username box, type in your username_workername. Fill in your password in the password box.
• In the Device name, choose your GPU. If you have multiple GPUs, they will be listed in there. They are numbered starting with 0. You will also see your CPU as a usable device. (This is a hint that you can use your CPU to mine, but it will slow your system to a crawl.)
• In the "Extra Flags" box you can type in:
  

Code:

-v -w128 -f30

• You can tweak these numbers to try to get as many Mhash/sec as you can.
• Remember to go back to the "File" menu and "Save Settings"

Now, repeat these steps again. This time using a different pool. When you get to "Device" just use the same device again.
In the "extra flags" box, just use -f60  or any higher number.


The main point is to use two miner per GPU. If you have 2 video cards, setup 4 miners.

If you found this helpful and feel generous, a gratuity would be appreciated at: 1JJjL5nxzBfjFjJWoviU9mzrY3fQKxJfvV

Again, thank you for the help, it will be rewarded. Is there anywhere I can find what these flags mean exactly? I mean, I can put all this in, but I'd like to know what the -v -w and -f are for. Also, I assume the higher number -f takes precedent correct? So I'd set the btc guild hire, but if I wanted to fall back to solo mining it'd be set lower?

[Carnth]

The lower the "f" value, the higher the priority.

Is there anywhere I can find what these flags mean exactly? I mean, I can put all this in, but I'd like to know what the -v -w and -f are for. Also, I assume the higher number -f takes precedent correct? So I'd set the btc guild hire, but if I wanted to fall back to solo mining it'd be set lower?

This web page has the poclbm.py source code. poclbm.exe uses this as well.

https://github.com/m0mchil/poclbm/blob/master/poclbm.py

On that page you can see there are a number of different "Extra Flags" to use.

• The -v flag tells the miner to use vectors. Works great on ATI cards.
  
• The -w flag tells the miner what worksize to use. This is sorta/kinda like how much of the block to work on(?). But bigger is not always faster. You can freely tweak this number up or down. The limit would be your GPU Ram.
• The -f flag tells the the miner how many frames per seconds to use. For me, this has always dedicated more GPU power to whatever is lower. Remember, your video display is also a GPU process (which I think equates to about -f30). Again, you can freely tweak this number to get your system|Mhash/sec to work best for you.

poclbm.exe flags

Code:

parser.add_option('-u', '--user',     dest='user',     default='bitcoin',   help='user name')
parser.add_option('--pass',	          dest='password', default='password',  help='password')
parser.add_option('-o', '--host',     dest='host',     default='127.0.0.1', help='RPC host (without \'http://\')')
parser.add_option('-p', '--port',     dest='port',     default='8332',      help='RPC port', type='int')
parser.add_option('-r', '--rate',     dest='rate',     default=1,           help='hash rate display interval in seconds, default=1', type='float')
parser.add_option('-f', '--frames',   dest='frames',   default=30,          help='will try to bring single kernel execution to 1/frames seconds, default=30, increase this for less desktop lag', type='int')
parser.add_option('-d', '--device',   dest='device',   default=-1,          help='use device by id, by default asks for device', type='int')
parser.add_option('-a', '--askrate',  dest='askrate',  default=5,           help='how many seconds between getwork requests, default 5, max 10', type='int')
parser.add_option('-w', '--worksize', dest='worksize', default=-1,          help='work group size, default is maximum returned by opencl', type='int')
parser.add_option('-v', '--vectors',  dest='vectors',  action='store_true', help='use vectors')
parser.add_option('--verbose',        dest='verbose',  action='store_true', help='verbose output, suitable for redirection to log file')
parser.add_option('--platform',       dest='platform', default=-1,          help='use platform by id', type='int')