Feature/Update:  Worker stats and API are now pulled live, rather than on a one minute cache.  They should never be behind by more than 10 seconds (due to work being logged to the DB in batches).
Bugfix:  Line breaks are now properly being added on plain-text versions of emails.

Sorry for the downtime.  A script that has been running seemingly flawlessly for the past few months had an unforeseen side effect on the database server.  The script that was backing up the DB and uploading it to a remote server was not properly deleting the backup after they were successfully transferred.  Last night the hard drive on the DB server became completely full, and it ended up killing the database.

I've fixed the script, and I am sorry for the downtime that happened while I was asleep. 

An update:  BTC Guild is running PoolServerJ for the entire pool.  We were able to push out 10 pushpool/10 bitcoind nodes with load balancing and replace them with a single PoolServerJ and 2 bitcoind nodes. 

Ah, missed that one.  Guess now it's time to explain what happened (it has been corrected):

As I mentioned in other threads/earlier in this one, BTC Guild has been moving from pushpool to PoolServerJ, putting lots of stress on it by redirecting some loadbalance nodes.  As of Sunday evening, the entire pool was shifted to PoolServerJ.  We've gone from 10 pushpool+bitcoind instances to 1 PoolServerJ with 3 bitcoind instances.  We update confirmations by polling a list of recent transactions from bitcoind and updating the confirmations based on the bitcoind output. 

Since we're now only using 3 bitcoind instances, its possible that the list of recent transactions is pushing out blocks that aren't yet at 120 confirms.  I've increased how many transactions get pulled, so it shouldn't happen again!

I need more information.  I just made a worker and everything worked just fine.


Fixed, didn't have the script added to cron ever since the previous server move.

Is this recent (we did move servers over the weekend).  The emails are sent with both plaintext and HTML versions.  It looks to me like your email client is displaying the HTML version, but stripping HTML tags for "security".  Every email I've received to date has properly displayed the line breaks.

After hammering out the last few bugs we found at BTC Guild with PoolServerJ, I'm almost ready to completely remove pushpool from my servers.

While the CPU load of PoolServerJ is higher than pushpool, I would not call it inefficient since PoolServerJ is doing far more work than pushpool.  PoolServerJ is doing full difficulty checks internally, prioritizing getwork responses to known good clients [QoS filtering], organizing work from multiple bitcoind nodes [faster LP delivery], running a cache of work so miner requests are responded to from the server rather than the server proxying the request to bitcoind [faster getwork delivery].  In the end, as long as the servers have enough extra RAM, the performance is outstanding.

PoolServerJ's work caching means if bitcoind stutters for a second, you have work ready and available to send to your miners, whereas pushpool becomes useless until bitcoind can respond, and cause miners to complain.

The tradeoff is simple:  pushpool will run on minimal specs, but becomes slow to respond after a certain level of load, even though CPU & RAM are sitting idle.  PoolServerJ will use significantly more RAM, but as long as its there, it won't choke until either your bitcoind can't provide the work as fast as its being requested, or your CPU is at full utilization.  A small pool would probably stick with pushpool, due to its low footprint and reasonable performance.  Any pool that is starting to have growing pains (they start around 250 GH/sec but they aren't "a problem" til ~450 GH/sec) would benefit greatly from taking a look at PoolServerJ.

For the last few hours, 40% of the pool has been running on PoolServerJ.  I've been comparing the share acceptance rate/reject reasons between PSJ and Pushpool for these last few hours, and have found significantly better performance on the PoolServerJ side.

The number of stale share submissions on the PSJ side are ~80% lower than the pushpool side.  This afternoon I will be rolling out a second PSJ server, and move the pool over to 80% PSJ and 20% pushpool, monitoring the stats closely before completely phasing out pushpool from the servers.

Long story short, I was trying to change our cert so it would work on PPS as well as Proportional, but I'm not using a self-signed cert, and it costs more to add a wildcard subdomain to our cert.  Botched my explanation of why I revoked/rekeyed the cert (its been a long day).  The old server did not have the re-issued SSL cert, since we were moving to a different server.  I didn't expect the move to take as long as it did, ideally nobody would have received any messages about an invalid/revoked certificate.

Server is being moved if you're seeing the security certificate revoked message.  Revoked our old SSL cert trying to setup a wildcard subdomain so PPS pool could use the same cert.  Should be back up and running shortly.

Just woke up and noticed the issue.  The shares table was setup to use a MEDIUMINT, autoincrementing for counting share IDs.  It overflowed last night, and stopped logging new shares in that table.  However, the shares get logged in two places, once in the shares table which is only used for determining speed and debugging share rejects.  The other table is what gets used to determine payouts (it counts your share submissions per difficulty).  That other table was still functioning perfectly.

Everything is back to normal now, and your miner speeds should be counting back up .

The PPS pool will absolutely be the first testing server I use for merged mining since I don't have to do any special accounting for NMC rounds vs BTC rounds.  I'll have to talk to shadders about it.

Has anybody tried applying the JoelKatz 4diff patch or integrating it into the merged mining bitcoind?  If they aren't compatible, it's going to be a major handicap getting a reasonably sized pool on board.

This weekend I will be moving the website to a different server again, changing it from a 2 gig VPS to a dedicated server.  I do not know when it will happen exactly (most likely Saturday evening, PDT).  Similar to the last move, the pools still be working as usual.  The only part going down is the website frontend, meaning you wont be able to access your stats / payouts until the move is complete (1~2 hours).

The move is for two main purposes:  1) Speeding up the website in general, especially when a long round is calculated/sync'd.  2) Making some DB schema changes to eventually allow merging the PPS option into the main pool, rather than running it as a separate pool.

I've been looking into merged mining, but right now I don't see it integrating itself into the main BTC Guild pool anytime soon.  It will be a bookkeeping nightmare unless I hide the NMC part and do it as a side calculation whenever a round ends.  It's difficulty to implement in a production environment, especially one where the database is not easy to make modifications to without slowing/halting the live servers.

I may put it onto the PPS pool for BTC Guild, since the code and DB schema is much more flexible on the PPS pool [no need to keep track of 'rounds'].

The API key itself will be the same if your username is the same.  However, you won't see the stats from one pool on the other pool's API URL, which is what you described ("however, the app seems to be picking up my workers in my proportional account, which are all zero now as I've moved them to the PPS account.").

I have not inspected or used any of the API apps, but I would suspect they don't work the same with PPS Guild since the API has added/removed a lot of information related to the workers and account.  PPS Guild has a bit more detail in the API for workers, and the user section is also quite a bit different due to the lack of confirmed/unconfirmed rewards.

I'll see if I can make a secondary API that follows the format I used on BTC Guild, but it won't have the same detail as the full API.

As for picking up your proportional account's workers, there is absolutely no way that can happen unless your API tools are screwing up.  They are completely different databases and have no link between each other.  The URL is different than the BTC Guild API (http://pps.btcguild.com/api.php instead of http://www.btcguild.com/api.php).

API is now up for PPS Guild, you can find your key and a link to the API on your My Account page.  Last share time is being returned as the number of seconds, rather than the HH:MM:SS format BTC Guild's API used, since its easier to manipulate.

If there's any other stats you want, just ask and I'll see what I can do.

API should be sometime today.  I've been too busy at my regular job to get any work done on the pool during the day, and I took my first weekend off after a few months of constantly working .

BTC Guild's testing has found 15 blocks with PoolServerJ so far, all of them were detected as proper difficulty by PSJ's internal test prior to sending to bitcoind.  No false positives, and no false negatives.

SMPPS is not the same as PPS.  If an SMPPS pool experiences a string of bad luck, you end up up waiting for backpay.  If a straight PPS pool has bad luck, I have to cover the payouts out of my pocket.  PPS is truly zero variance aside from your individual miners luck with diff-1 shares.  SMPPS is only zero variance as long as the pool has had enough good luck streaks to offset a bad luck streak.