I am aware of the last share time display issue.  Right now the database is cleaning up old shares as newer blocks are found.  A similar problem is happening with the reset share/stale counter due to this database cleaning.  They will be fixed sometime this week.

The server is running a (mostly) standard pushpool, so open sourcing my pool would not accomplish too much .

Miner idles should have stopped yesterday for most users, however it is possible for them to start showing up as the hash rate of the pool has been increasing rapidly and is straining the hardware when a large number of shares + a block solve happen simultaneously.

I have a dedicated hosting provider lined up and they are going to be setting up a server with the specs I need this week.  This will be a significantly more powerful system than what the pool is currently running on, has a 100 mbps connection, and very strong DDoS protection.  The switch to the new server should happen on Thursday or Friday this week.

When transaction fees are required (due to the pool sending coins which are only recently created), I absorb the costs of the transaction fees.  Our transactions do not reach the 1 kB amount though (normally 200-300 bytes).

The pool did a very quick restart (< 1 second) to push the 0.4 pushpool updates live, and fix the Ufasoft CPU miner problems that people were having.  TCP Keepalive connections are part of this update, which may provide a marginal performance increase, as well as reduce the load on the router, which was recycling connections constantly (and led to a slowdown earlier today).

The problem has been identified.  The user running the pool service was hitting the open socket limits as we were above 100 gH/sec.  I have modified the limits on the user the pool service runs under, and restarted the pool.

Pool is back up.  I have an idea of what may have caused it.

I also added a watchdog monitor to the pool processes, and added the pool & bitcoind processes as startup scripts so the server should auto recover in less than 20 seconds if it does happen again.

I've contacted ufasoft for some assistance in getting the compatibility with his miner fixed.

In other news, we crossed 100 gH/sec a while ago, and are still seeing a steady rise.  The new hardware is having no issues handling this additional load based off the reports in the IRC channel.

Many updates will be going live in the next 48 hours now that my attention is allowed to move from scaling/hardware to software updates.

As is the standard, the server decided to wait until a few hours after I was asleep, but a few hours before I would wake up to die.  I did not have time before work to diagnose what happened, all I know is that the server was not responding to connections, even SSH from the internal network.  I did a hard boot and restarted the server processes.  I will attempt to diagnose the problem with what log files are available when I return home.

I'd also like to express my gratitude.  It was a chore setting my pool up due to the lack of documentation, but it certainly gives a great framework to build off of, rather than locking you into a very basic system.

Is that stale count from the beginning of time, or since the pool came back up from maintenance about 9 hours ago?  I'm running at a 0.1% stale rate, and a few people in the IRC channel have reported similar 0.1-0.4% stale rates, normally coming when a share is submitted immediately as a long poll is being received.

Send me a PM with your worker name, and which mining software you use.  I can take a look at your recent submissions to find out why they're being rejected.

Maintenance took quite a bit longer than expected due to MySQL being very unhappy about moving to a new drive, which interfered with time I had set aside for my day job.

Pool is back online now, and the new drive is screaming fast compared to the old one!  Some additional updates were run on the pool, so please keep an eye out for any display glitches in your stats.

Now that the hardware and software has been upgraded, I can return to working on the features I wanted to get done last weekend.

As a reminder since it is now a page or two back, the pool will have a 1-2 hour maintenance 2 hours from now.  This is to install new hardware for the server to be able to keep up with the demand of our increasing has rate.

Rename worker is disabled until the hardware switch.  The default pushpool method of storing workers in the share database is by username as a text field.  Meaning to accurately swap a worker's name, the entire share database needed updating.

With tomorrow's maintenance, I'm changing the pushpool software to use worker and user IDs rather than text names, and the ability to rename workers will be restored.

Pool will be down for approximately 5 minutes to prune all the confirmed block shares out of the DB.  This will hopefully allow the pool to keep up with the current hash rate until the new hardware arrives tomorrow.

There were some people experiencing disconnects or miner idles overnight, in short bursts.  As far as I have been able to tell from the logs, this is related to I/O wait and internal network latency between the web/pool server and the database server.  This is likely because the pool has doubled in size in the last few days, now over 50 gH/sec, which is far faster than I anticipated.

Because of this, I have moved the planned maintenance window from Thursday to Wednesday (4:30 PM PST - ~6:00 PM).  This maintenance will be installing a solid state drive for faster database access (which has been related to some of the miner idles/RPC errors).  I will also be installing a second NIC card into the web/pool server and connecting the database server directly to the web/pool server to avoid running this through the network router, which is likely the cause for some latency spikes and/or disconnects.

Right now I have no plans to make the payouts come directly out of the block, it would require a significant amount of changes to both the site and the pool code.

In other news:  You can now view detailed block statistics which breakdown shares by user, reward by user, and donation by user.  It is kept hidden by User ID#.  Your personal contribution to the block (if any) is highlighted in yellow.  You can access this information by clicking the 'View' link on the right side of the block in the statistics listing.

I think you meant 40-50 kWh per day is a "lot".  40-50 per month is NOTHING.  Although you'd have hated to see my usage last summer (before mining).


Can't wait to see my May electric bill.  Should be over 3,000 kWh and it isn't even 100F outside (yet).

There was a problem with the long polling monitor earlier this morning which has been corrected.  I was also making a few tweaks to prepare for what will probably be the final hardware upgrade (solid state drive for the database) this Thursday.  However, the slight backend tweaks should not have produced stale results like what you're referring to.

If you're running a slower miner (CPU/low end GPU), the stale % likely spiked due to the long polling monitor problem.

The updates done over the weekend seemed to have fixed the hangups from new blocks.  Pool has remained online and strong with 5 blocks found since yesterday's maintenance.

One bug was found in the new block code.  It used the old rounding (AKA: Cutting off decimals after 0.001).  I have manually updated everybody's rewards and increased them by 0.001 per block for blocks #18 - 22.  This guarantees that everybody got more than what they should have for the blocks, to make up for losing the extra decimals of accuracy which were missing on those 5 blocks.

Ah, I've added that to the front post now.  I forgot it was just nested in here in one of the posts rather than on the front.  Also adding it to the front page of the website.