But I'm wondering if there is any connection between what you call the "experimental" nature of the pool and stability? And if there is a connection, what is it exactly? I'm not seeing any connection. It seems to me that the recent server crash and resulting down time could have happened to any pool operating from one server, regardless of how "experimental" or "traditional" the pool might be. In a way, I like the experimental nature of the pool, if this means you are still in the process of trying to improve the whole model. And the instability isn't a huge issue since I need backups anyway. Still, I'm wondering if the ongoing experimental nature of the pool means an ongoing higher probability of instability. I'm totally fine with the way the payment system works, and understand that this can at times mean a longer wait to get paid, so I'm just wondering about the stability connection, if in fact there is one.
I keep the "experimental" label because I am not completely satisfied with the status quo yet. Eligius-Su runs a mixture of the old codebase with a newer codebase designed for MPPS and hacked to do SMPPS. It needs to replay the entire pool history (at about 12 TH/s) whenever I restart it (though I can hot-patch it without a restart). The current codebase is not capable of payout except in generation, which is causing some annoying delays. So a rewrite is still needed. In addition, the Linux networking stack has been randomly choosing machines it doesn't allow to connect-- we get the SYN packet fine, but Linux silently discards it without passing it to pushpoold. Investigation of this problem is ongoing. Finally, I am not 100% certain SMPPS is the best road to the future, and think newer, possibly better, payout methods should be researched and considered. I am happy that my efforts in this area have sparked others into researching alternatives as well, and hope we will see much more variety of payout methods to experiment with in the near future.
