Status as of Saturday, July 22, 2017

Hi! Here's a few important notes:

• Thanks to everyone who is offering to help with the system! We're always glad to work with customers and love to talk to people, but I just wanted to point out a few things here so that we can save everyone time from duplicate requests.
• First, I want to concentrate on improving the pool's performance this weekend, so I will not reply to private messages until Monday. I apologize for the delays. If you have an urgent support issue, please submit a ticket.
• Chris is notified automatically when the system is offline. Submitting support tickets about pool downtime significantly increases the time until we can get a fix out, because Chris has to spend his time replying to the tickets. Feel free to request support on other issues, but if the system is completely offline, you can trust that Chris knows about it and is working on it.
• Chris will make sure to get share corrections done so that balances are right before payouts tomorrow.
• The pool is not hardware limited, so buying servers will not solve this problem, and moving to a new hosting location will significantly set back software solutions. Much thanks for the kind suggestions, but the only assistance that could solve these problems are software optimizations.

Again, we apologize for focusing on the performance optimizations and taking away time from communicating here. If you require support for anything other than pool downtime, feel free to submit a ticket to Chris and he'll get on it right away! Otherwise, the best help we could use is simply the ability to focus on making the system as fast as possible until the end of the weekend!

Quotethe best help we could use is simply the ability to focus on making the system as fast as possible until the end of the weekend!

Makes sense - good luck guys!

Steve Sokolowski wrote:The pool is not hardware limited, so buying servers will not solve this problem [...]

Steve, we all appreciate the work you guys are doing, but you're missing the point about more hardware -- it's not just about total raw computing power... It's about availability, and for that there is literally no other choice than to have multiple machines (you already know this to some extent, given you already spread the load somewhat between the pool, forums, and main website).

If the problem is that one algorithm is crashing the whole damned pool, then it would help greatly if you move all services related to that algorithm to their own machine(s). If someone causes X11 to spike and crash, for example, that takes out Scrypt as well.

So even if you had two machines that, taken together, have the same total amount of computing power as is currently dedicated to pool operations, would still be better, because then at least some services continue to run if something breaks in another part of the site.

This will hold true no matter how much optimization you do in software, and no matter how many services, algorithms, or coin daemons you run (well, up to a reasonable point, of course).

Same reason people often put /, /home, /usr, and sometimes /var on separate partitions.

VanessaEzekowitz wrote:

Steve Sokolowski wrote:The pool is not hardware limited, so buying servers will not solve this problem [...]

Steve, we all appreciate the work you guys are doing, but you're missing the point about more hardware -- it's not just about total raw computing power... It's about availability, and for that there is literally no other choice than to have multiple machines (you already know this to some extent, given you already spread the load somewhat between the pool, forums, and main website).

If the problem is that one algorithm is crashing the whole damned pool, then it would help greatly if you move all services related to that algorithm to their own machine(s). If someone causes X11 to spike and crash, for example, that takes out Scrypt as well.

So even if you had two machines that, taken together, have the same total amount of computing power as is currently dedicated to pool operations, would still be better, because then at least some services continue to run if something breaks in another part of the site.

This will hold true no matter how much optimization you do in software, and no matter how many services, algorithms, or coin daemons you run (well, up to a reasonable point, of course).

Same reason people often put /, /home, /usr, and sometimes /var on separate partitions.

Thanks for the suggestion, but again, the problem is software, not hardware.

At some point, we will get to the point where we can have duplicate servers that communicate with each other - that's the new architecture we're working towards now. However, given that we haven't reached that stage yet, it isn't possible to parallelize the system to have multiple mining servers at this time.