Thanks! I'm glad the pools is working out for you.  Blades look nice!

I do see a bunch of 0 confirmation payments mixed in with some with 6 confirmations. That's is unusual. Other nodes don't seem to have seen them either. Looks like the transaction propogation had an error. I'll see if they can be resubmitted.

Payments should still be instant. Possibly just a network glitch at the time.

This is just a visual thing. User balances are still updated immediately. I manually approve the data containing the block number, reward and whether it was orphaned while I'm testing how how that data propogates to make sure it's correct.

Miners tend to prefer PPS as it's a guaranteed constant income. Pool operators prefer not to have PPS. DGM, PPLNS and CPPSRB seem popular and non-hoppable. DGM has lots of knobs to turn to adjust from high to low variance on the miner or pool side at a cost of being more difficult to understand. I like it though. Miners seem to find it hard to get a handle on so it can scare people off.

With regards to transaction fees, the feedback I've had from miners in my pool is they overwhelmingly want them. My pool pays orphans but keeps fees to cover it but it seems miners prefer it the other way. I'll probably be switching. Donation based pools are fine as long you don't expect any donations. You probably won't get many. You'll want to be able to pay the server costs out of pocket for a while as most funds will be used to keep the pool solvent in the beginning. Even tiny errors can end up costing big and it's hard to recover from an error when pool fees are so low.

Stratum-only seems reasonable. GBT is also a fine choice. GetWork is probably on the way out.

I've addnoded a bunch of connected servers and send out to a couple of my own nodes that are relatively unconnected from each other (to encourage dispersion of the blocks). Of the four orphans two are actually the result of failure rather than bad block propogation. One due to the slowdown of nodes as the result of spam and another due to a pool bug losing the block before it even got submitted. Both have been fixed or worked around now.

Yes, did some minor updates to improve performance in areas and preparing for transaction fee payments. Unfortunately on the restart it failed to send a clean block out so got lots of rejects for 20 seconds or so. Haven't done the update to v0.8.x on the merge mining server yet as it's still in testing. Seems to be working ok though. It's a bit suspicious since the first go at doing the merge of the code changes worked straight away. Something must be wrong!

The pool is over 50% devcoin and ixcoin occasionally. There seems to be a couple of other big miners that hop on now and then. Most of the time it's over 50% though for those two coins.

What I'm doing is porting the merge mining modifications to the 0.8.2 bitcoin branch. That'll help with the orphans. And I'm also looking at migrating to paying transaction fees but not paying orphans. Most miners seem to prefer that approach that the way I've got it at the moment. Part of the move to the stats, where the full block reward is shown, is the move towards being able to pay transaction fees.

I've added to http://mmpool.bitparking.com/blockstats to show the block number, block reward and whether the block was orphaned for the blocks the pool has found. The pool reserves section also now takes into account the transaction fees the pool received whereas before it just assumed 25btc per block.

Merge mining is now active again.

Yes, doing the switch. I'm running some tests and will enable in the next 20 minutes or so all going well.

I am not seeing this myself. Is anyone else seeing this? What cgminer version are you using?

The block download is up to 230,000 so it has not long to go now. Once complete I'll re-enable merge mining. It's taking longer because I disabled the download while on my 14 hour flight back home just in case it impacted the rest of the pool. Not long now until everything is operational again.

To prevent this happening again I'm commissioning a second server to operate as a 'hotswap' server. It'll have a mirror of the normal server and enable switching over too it if something goes wrong with the main server with minimal downtime.

Not that I'm aware of. What are you seeing?

getwork server is back in operation. Still no merge mining while the blockchain is being indexed.

Stratum is up again, merge mining is disabled. Currently only bitcoin with DGM is operational. The getwork server is also not up. I'm monitoring stratum for the next few hours to check stales don't happen. I'll enable merge mining again as soon as the blockchain download is complete on the merge mining server.

Last night the pool starting having issues due to what I assume was blockchain spam. I had a patch applied to prevent this but the bitcoind was still getting slower and slower. I was on a plane at the time but as soon as I landed and found out what was happening I shut things down then brought it up in non-merge mining mode while I tracked down the issues.

While shutting down the main bitcoind process the block index got corrupted. I don't know how or why. This meant having to reload the block index. This operation is still going on. I assume this impacted server load and caused problems with the temporary non-merging mode I setup and it started serving stales overnight.

I've now shut the pool down completely while I load the block index and verify everything is ok. I apologise for the inconvenience and hope to have it up as soon as possible. The timing is unfortunate as I'm traveling back home after a work related trip and have been doing this while hopping between airports, hotels and airport lounges. My next flight is 12 hours so I'm hoping this load finishes before then so I can  bring things up before I go offline for that time.

Pool is down while I investigate the issues.

Pool went down, but it's up now. It's not currently merge mining but is paying the merge mined coins out of reserves while I investigate the issue.