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

[Sukrim]

The latter is actually a feature that is no longer in place, other than that payouts are rounded down at the 3rd decimal.

[eleuthria]

I just joined BTCguild this morning.  Everything looks good so far, with the caveat of the issues that have already been noticed and are being worked on (delay in assigning pieces after a new block has been discovered) or will hopefully be worked on (pool rounding down amounts less than .001 BTC).

The 0.001 is no more.  The pool now calculates rewards out to the 8th decimal point, the limit of the Bitcoin protocol.  Payouts are cutoff to 0.XX, but the remaining amounts roll forward into your next payout, exactly the way they are handled at slush or Deepbit.

[cschmitz]

i think i will bring my btcg total to 2gh/s next week, i like the network and how it works, despite 150ms ping from europe to cali, deepbit is only 30ms but i dont like 3% tax and the huge size of the pool

[bcpokey]

Very cool looking project, I was considering trying my luck at solo mining when I got up to a certain level of processing power, but this looks like a good balance between solo and pooled efforts, so if there is functionality added to warn when workers stall (an annoying problem I face fairly often) I'll probably switch all my workers over to this for a few days to see how things operate

I'm in CA too so latency should be sweet, and I read recently that deepbit got 50% of the processing power, which I think is a poor idea, so alternative pools just make good sense (if you can be patient enough to not have all blocks solved right away).

EDIT: No more superman 2 decimal profits for server? Aww heh.

[eleuthria]

Recent (< 30 minutes ago) RPC & Miner idle errors are part of moving the old shares from confirmed blocks to a new database, and taking them out of the current one.  They should have been very short durations (< 5 seconds).  This is a necessary delay in order to let the pool scale with higher workloads and not be bogged down with speed calculations and share calculations.

I've scaled back the aggression the server was using for how many rows it was accessing (copying + deleting) per cycle.

[Bitcoineruk]

Is this why i am seeing this?

Listener for "BTC GUILD": 13/05/2011 23:15:47, Problems communicating with bitcoin RPC
Listener for "BTCGUILD 2": 13/05/2011 23:15:49, warning: job finished, miner is idle
Listener for "BTCGUILD 2": 13/05/2011 23:17:23, warning: job finished, miner is idle
Listener for "BTC GUILD": 13/05/2011 23:17:31, warning: job finished, miner is idle
Listener for "BTC GUILD": 13/05/2011 23:17:32, Problems communicating with bitcoin RPC
Listener for "BTCGUILD 2": 13/05/2011 23:17:35, warning: job finished, miner is idle
Listener for "BTCGUILD 2": 13/05/2011 23:17:38, Problems communicating with bitcoin RPC
Listener for "BTC GUILD": 13/05/2011 23:17:38, Problems communicating with bitcoin RPC
Listener for "BTC GUILD": 13/05/2011 23:17:44, Problems communicating with bitcoin RPC
Listener for "BTCGUILD 2": 13/05/2011 23:18:30, warning: job finished, miner is idle
Listener for "BTC GUILD": 13/05/2011 23:18:40, warning: job finished, miner is idle
Listener for "BTC GUILD": 13/05/2011 23:18:41, Problems communicating with bitcoin RPC
Listener for "BTC GUILD": 13/05/2011 23:19:21, warning: job finished, miner is idle
Listener for "BTC GUILD": 13/05/2011 23:19:47, Problems communicating with bitcoin RPC
Listener for "BTC GUILD": 13/05/2011 23:19:48, warning: job finished, miner is idle
Listener for "BTC GUILD": 13/05/2011 23:20:25, warning: job finished, miner is idle
Listener for "BTCGUILD 2": 13/05/2011 23:20:31, warning: job finished, miner is idle
Listener for "BTCGUILD 2": 13/05/2011 23:21:22, warning: job finished, miner is idle
Listener for "BTC GUILD": 13/05/2011 23:22:08, Problems communicating with bitcoin RPC
Listener for "BTC GUILD": 13/05/2011 23:23:40, warning: job finished, miner is idle
Listener for "BTCGUILD 2": 13/05/2011 23:24:16, warning: job finished, miner is idle
Listener for "BTCGUILD 2": 13/05/2011 23:24:17, Problems communicating with bitcoin RPC
Listener for "BTC GUILD": 13/05/2011 23:24:26, Problems communicating with bitcoin RPC
Listener for "BTC GUILD": 13/05/2011 23:24:26, warning: job finished, miner is idle
Listener for "BTCGUILD 2": 13/05/2011 23:24:26, Problems communicating with bitcoin RPC
Listener for "BTC GUILD": 13/05/2011 23:24:35, Problems communicating with bitcoin RPC
Listener for "BTCGUILD 2": 13/05/2011 23:24:35, Problems communicating with bitcoin RPC
Listener for "BTC GUILD": 13/05/2011 23:24:41, Problems communicating with bitcoin RPC
Listener for "BTCGUILD 2": 13/05/2011 23:24:44, Problems communicating with bitcoin RPC
Listener for "BTC GUILD": 13/05/2011 23:25:01, warning: job finished, miner is idle
Listener for "BTC GUILD": 13/05/2011 23:25:01, Problems communicating with bitcoin RPC
Listener for "BTCGUILD 2": 13/05/2011 23:25:02, warning: job finished, miner is idle
Listener for "BTCGUILD 2": 13/05/2011 23:25:02, Problems communicating with bitcoin RPC
Listener for "BTCGUILD 2": 13/05/2011 23:25:07, Problems communicating with bitcoin RPC
Listener for "BTC GUILD": 13/05/2011 23:25:07, Problems communicating with bitcoin RPC
Listener for "BTCGUILD 2": 13/05/2011 23:25:13, Problems communicating with bitcoin RPC
Listener for "BTC GUILD": 13/05/2011 23:25:16, Problems communicating with bitcoin RPC
Listener for "BTCGUILD 2": 13/05/2011 23:25:18, Problems communicating with bitcoin RPC
Listener for "BTC GUILD": 13/05/2011 23:25:22, Problems communicating with bitcoin RPC
Listener for "BTCGUILD 2": 13/05/2011 23:25:28, Problems communicating with bitcoin RPC
Listener for "BTC GUILD": 13/05/2011 23:25:28, Problems communicating with bitcoin RPC
Listener for "BTCGUILD 2": 13/05/2011 23:25:34, Problems communicating with bitcoin RPC
Listener for "BTC GUILD": 13/05/2011 23:25:34, Problems communicating with bitcoin RPC
Listener for "BTC GUILD": 13/05/2011 23:26:00, warning: job finished, miner is idle
Listener for "BTC GUILD": 13/05/2011 23:26:00, Problems communicating with bitcoin RPC
Listener for "BTC GUILD": 13/05/2011 23:26:06, Problems communicating with bitcoin RPC
Listener for "BTCGUILD 2": 13/05/2011 23:26:07, warning: job finished, miner is idle
Listener for "BTCGUILD 2": 13/05/2011 23:26:07, Problems communicating with bitcoin RPC
Listener for "BTC GUILD": 13/05/2011 23:26:12, Problems communicating with bitcoin RPC
Listener for "BTCGUILD 2": 13/05/2011 23:26:13, Problems communicating with bitcoin RPC
Listener for "BTCGUILD 2": 13/05/2011 23:26:19, Problems communicating with bitcoin RPC
Listener for "BTC GUILD": 13/05/2011 23:26:22, Problems communicating with bitcoin RPC
Listener for "BTCGUILD 2": 13/05/2011 23:26:36, warning: job finished, miner is idle
Listener for "BTC GUILD": 13/05/2011 23:26:36, warning: job finished, miner is idle
Listener for "BTC GUILD": 13/05/2011 23:26:36, Problems communicating with bitcoin RPC
Listener for "BTCGUILD 2": 13/05/2011 23:26:36, Problems communicating with bitcoin RPC
Listener for "BTC GUILD": 13/05/2011 23:26:48, Problems communicating with bitcoin RPC
Listener for "BTCGUILD 2": 13/05/2011 23:26:48, Problems communicating with bitcoin RPC
Listener for "BTCGUILD 2": 13/05/2011 23:26:54, Problems communicating with bitcoin RPC
Listener for "BTC GUILD": 13/05/2011 23:26:57, Problems communicating with bitcoin RPC
Listener for "BTC GUILD": 13/05/2011 23:27:03, Problems communicating with bitcoin RPC
Listener for "BTCGUILD 2": 13/05/2011 23:27:03, Problems communicating with bitcoin RPC
Listener for "BTC GUILD": 13/05/2011 23:28:18, warning: job finished, miner is idle
Listener for "BTC GUILD": 13/05/2011 23:28:19, Problems communicating with bitcoin RPC
Listener for "BTCGUILD 2": 13/05/2011 23:28:24, warning: job finished, miner is idle
Listener for "BTCGUILD 2": 13/05/2011 23:28:25, Problems communicating with bitcoin RPC
Listener for "BTC GUILD": 13/05/2011 23:28:25, Problems communicating with bitcoin RPC
Listener for "BTCGUILD 2": 13/05/2011 23:28:30, Problems communicating with bitcoin RPC
Listener for "BTCGUILD 2": 13/05/2011 23:28:55, warning: job finished, miner is idle
Listener for "BTCGUILD 2": 13/05/2011 23:28:58, Problems communicating with bitcoin RPC
Listener for "BTCGUILD 2": 13/05/2011 23:29:03, Problems communicating with bitcoin RPC
Listener for "BTC GUILD": 13/05/2011 23:29:04, warning: job finished, miner is idle
Listener for "BTC GUILD": 13/05/2011 23:29:05, Problems communicating with bitcoin RPC
Listener for "BTC GUILD": 13/05/2011 23:29:13, Problems communicating with bitcoin RPC
Listener for "BTC GUILD": 13/05/2011 23:29:19, Problems communicating with bitcoin RPC
Listener for "BTCGUILD 2": 13/05/2011 23:29:23, warning: job finished, miner is idle
Listener for "BTC GUILD": 13/05/2011 23:29:25, Problems communicating with bitcoin RPC
Listener for "BTCGUILD 2": 13/05/2011 23:29:27, Problems communicating with bitcoin RPC
Listener for "BTC GUILD": 13/05/2011 23:29:31, Problems communicating with bitcoin RPC
Listener for "BTCGUILD 2": 13/05/2011 23:29:32, Problems communicating with bitcoin RPC

[eleuthria]

Yes.  Those errors should not be seen again, at least until we find another block.  I'm reworking the block calculation code right now so it won't lock up the database during calculations.  Depending on which happens first (completing the rewrite or a block being found), we may have another set of RPC/Miner idle errors for about 2 minutes when we find our next block.

[Muhahahahaz]

Yes.  Those errors should not be seen again, at least until we find another block.  I'm reworking the block calculation code right now so it won't lock up the database during calculations.  Depending on which happens first (completing the rewrite or a block being found), we may have another set of RPC/Miner idle errors for about 2 minutes when we find our next block.

Looks like you have plenty of time... this block is taking forever!

[eleuthria]

Yes.  Those errors should not be seen again, at least until we find another block.  I'm reworking the block calculation code right now so it won't lock up the database during calculations.  Depending on which happens first (completing the rewrite or a block being found), we may have another set of RPC/Miner idle errors for about 2 minutes when we find our next block.

Looks like you have plenty of time... this block is taking forever!

It was bound to happen, our lucky was way too good this week

[ape]

Color coding for workers has been added to the gadget.

[eleuthria]

Later today (12-14 hours from now), the pool will be going down for a server upgrade.  It will be down for approximately 45 minutes to 1 hour, as this will also be when the work done the past 24 hours for optimizing the DB for block calculations will be implemented.  I have decided to keep the pool down when implementing this to have a single chunk of downtime rather than intermittent RPC comm error/miner idle messages for 1-2 hours while attempting to implement the change while the system is live and running.

Once the hardware arrives, I will make a post on the forum and a red banner will appear on the website, giving 2 hours advance warning.

[MrGaSp]

Ty for the warning...all of them, that is really above and beyond.

[Sukrim]

As there were some questions here and Eligius doesn't have (a lot of) fees either, here's how to configure the poclbm-gui to mine in another pool with low priority (so you have a "fallback" mode).

Simply add another OpenCL miner tab, name it to something you like, select server "Other", Host: "pool.bitcoin.dashjr.org", Port: "8337", Username: "[your payout address]", Password: "[doesn't matter what, just type "xxx" or so - there is no PWD!]", Device: the same(!) GPU you use for mining here, Extra flags: the same flags, except that you increase the value at the parameter "-f" to something around 60 (by default it's 30).

Save config, run the miner and then you should see a few MH/s going to Eligius (for me 2 out of total ~280 MH/s are by default there with -f 60 @ Eligius and -f 30 @ BTCGuild).
Once one of the two servers fails, the full hashing power will switch to the other one.

I get quite a few more stales at Eligius that way though - however it means I will have in total more "uptime" meaning I on the one hand have to care less about service windows like the announced one and also don't have to monitor the pools constantly. Eligius has the advantage, that it pays out either after 1 week of inactivity or once >1 BTC is reached - meaning you don't have to care about getting your payouts from there at all. Your main hashing power will still be in this pool and at least in my case (ATI 6870) running a second miner with low priority on the same GPU did also not harm my total performance in any way.

[eleuthria]

Pool will be going offline in 2 hours and 10 minutes (2:30 PM PST).  Estimated downtime is 1-2 hours.  Once it is back up, the delays, rpc errors, and miner idles caused by the end of a round should no longer occur.  Additionally, the site should be even more responsive upon coming back up.  Part of the change that went live has already cut page generation times to < 20ms for most pages.

[Nythain]

As there were some questions here and Eligius doesn't have (a lot of) fees either, here's how to configure the poclbm-gui to mine in another pool with low priority (so you have a "fallback" mode).

Simply add another OpenCL miner tab, name it to something you like, select server "Other", Host: "pool.bitcoin.dashjr.org", Port: "8337", Username: "[your payout address]", Password: "[doesn't matter what, just type "xxx" or so - there is no PWD!]", Device: the same(!) GPU you use for mining here, Extra flags: the same flags, except that you increase the value at the parameter "-f" to something around 60 (by default it's 30).

Save config, run the miner and then you should see a few MH/s going to Eligius (for me 2 our of total ~280 MH/s are by default there with -f 60 @ Eligius and -f 30 @ BTCGuild).
Once one of the two servers fails, the full hashing power will switch to the other one.

I get quite a few more stales at Eligius that way though - however it means I will have in total more "uptime" meaning I on the one hand have to care less about service windows like the announced one and also don't have to monitor the pools constantly. Eligius has the advantage, that it pays out either after 1 week of inactivity or once >1 BTC is reached - meaning you don't have to care about getting your payouts from there at all. Your main hashing power will still be in this pool and at least in my case (ATI 6870) running a second miner with low priority on the same GPU did also not harm my total performance in any way.

Thanks for this mate. I had heard of people doing it, but no one really explaining the -f setting, like what to set it at so its higher than default and not stealing priority over the "main" miner connection. Will set this up and test it during the down time today.

[MrGaSp]

Maybe we will have good luck again when it comes back 

[CydeWeys]

Maybe we will have good luck again when it comes back 

Yup, here's hoping for some good luck when it comes back up!  I'll switch back from Eligius later tonight after it's restarted, and we'll see how we do.

[eleuthria]

Upgrade took a little longer than anticipated.  Some of the optimizations were ported from being part of the website (PHP) to being part of the pushpool service itself.  End of round calculations no longer modify any part of the shares database.

The once per minute pool stats update is also modified greatly, cutting the run time from 3-6 seconds (depending on how many transactions were hitting the DB during the stat update) to around 0.2 seconds.

Pool is back online.  No additional downtime is expected to occur, unless a problem is found when the current round ends.

[Miner-TE]

Jumping back in.  Is it warm? 

[Nythain]

El, I have to go to bed so I won't see you on the IRC and I'm not sure if you'll get it in the scrollback. At around 02:53 Central (give or take a minute) the pool stats all reset like a block was solved without a block being solved. Round time is still ticking up, but round shares and individual shares all got reset.