Well I never thought I'd say this but even I'm feeling the new diff and it's only going to get worse from here on 

I was hoping for this pool to make more blocks to justify upgrading the server capabilities and performance but that's never going to happen at this rate.

I'll think about it. Actually it's a little known fact that I run 4 servers for this pool, 1 main one that runs the pool and primary bitcoind, 1 backup bitcoind, and 2 equidistant spaced bitcoind servers across the globe (German and Hong Kong) in order to relay blocks to and from the server on the west coast of USA. Even if Matt's relaynetwork went down, I'd still be well placed for quick block changes/propagation.

For sure, like willi9974's 51.8G share today would have been a block just a few adjustments ago.

Is it known what percentage of solo blocks solved are solved at cksolo vs. the rest of the network?

I'm not surprised, 10% or whatever it was is a huge increase .

Raise your fee's buddy, it's a great service you offer and people will still use it.

Now with blocks being less frequent you must cover yourself.

In germany is one, good to know!
That was the reason for asking you earlyer in this thread on what requirements the server has to meet to
run the ckpool and bitcoind relay, and the link to the provider. I was not aware off it.
Now I just learn on how to setup the pool sw for my bunch of miners (all small ones) for
connecting to the local bitcoind relay for backup.
I will do it because you explained that the bitcoind did not like more instances of cgminer connected to it.


Edit: I run the bitcoind on a 4 core AMD@2.4Ghz with 8GB Ram and 1 TB HD. During reindexing all 4 cores are running nearly @ 80 - 100 %, I was "shocked". 

  the waiting has an end:

Congrats to

1G9Y29V8zQ1i62c2ugg4xM566NLTmEabJn for Block 386226 solved @ cksolo.pool.

And a BIG block tooo

Another LIVE view... hope it will not last weeks to see the next

Wow. See the hash rate though?

http://solo.ckpool.org/users/1G9Y29V8zQ1i62c2ugg4xM566NLTmEabJn
{"hashrate1m": "2.31P", "hashrate5m": "2.25P", "hashrate1hr": "1.88P", "hashrate1d": "945T", "hashrate7d": "691T", "lastupdate": 1448980094, "workers": 13, "shares": 198613649837, "bestshare": 19199145111.253162, "bestever": 185448442708}

yep, not bad :p

Yes that's right. It was only 4 minutes after the previous block so some lucky very low priority transactions got into it since my preference is to always clear as many transactions as possible, provided they've paid their due fee. Other operators don't feel the same way but it helped clear quite a bit of the backlog of transactions that have been bouncing around using bandwidth and filling mempools for a while.