@jonnybravo0311,
Thanks for the info. Your input made this thread worthwhile.
It's sad to hear the report though. I, as many, kept hoping that p2pool would be a much more viable option for miners. What do you think the probability of something coming out of the p2pool development that would actually be viable option? I would hate to see the idea just die.
There have been a number of people trying to do something about it. If you look at the thread I linked to the test I'm running, you can see how OgNasty approached it. Quick summary: he put a traditional pool on top of p2pool's backbone. It's an innovative approach, but the solution reduces variance by centralization. You're forced to stay on his node if you want the variance reduction offered.
Bitmain came out guns blazing a number of months back with their antpool claiming they were going to revolutionize p2pool. Yeah, that went nowhere.
A few of us suggested using side chains or some other method of managing variance. That hasn't been implemented yet, either.
So, all in all, things are kind of at a standstill. Nobody's produced a solution that has been incorporated to p2pool base code. Bitmain forked the code, but hasn't done a thing with it in months. OgNasty (well, actually it's Nonnakip who's written it) front end is completely proprietary and written in C.
Wish I had better news for you, but p2pool pretty much exists as it has. If you don't mind the variance, or have enough hashing power to counteract it a bit, then go for it. I'd say minimum entry at this point is 1TH/s. I've got S3s and 440GH/s will miss the occasional block or 2.
EDIT: one other thing I forgot to mention... p2pool is written in Python and is single-threaded. Can't scale very well on a single thread.