Status as of Saturday, July 29, 2017

• Chris completed the move of the shares database tables to the PRO 960 disks, and that seems to have increased capacity even more. As before, more hashrate came online almost immediately and now the system is maxed out again.
• Someone pointed out to me that just three weeks ago, the system had a theoretical maximum of about 700 GH/s, and now it's able to handle about 2.2 TH/s of hashrate. While it's never good to be at capacity and I understand the frustration, I would offer to those who are disappointed in capacity issues that being able to achieve sustained gains of 30% per week in computer science is unusual. Imagine if Intel were able to release chips that were 30% faster every week!
• The work on the new share insertion code is ahead of schedule. We plan to use the extra time to write automated tests. When released, I expect we can probably get another 50%. I suspect the next bottleneck will be database contention, because once CPU load in calculating the share data is distributed, there will then become a point where queries like "UPDATE balance set coins=coins+just_mined where person=whoever" will be waiting for the other share calculator's UPDATE statement to finish.
• There are some miners who have been talking about L3 miners having difficulty connecting or disconnecting. I haven't heard this from other types of miners, so I wonder if there is some issue with these miners in particular. If you have a case where L3 miners are disconnecting but your other miners are working fine from the same connection, then submit a support ticket so Chris can look into it. But if they're on different connections or are rented, then a ticket won't be helpful because there are too many other possibilities.
• Bitcoin Cash is coming and we plan to offer it on day one. We will also credit users for Bitcoin Cash they are owed for outstanding balances, so there is no need to worry. Some companies like Coinbase and Poloniex will not be providing Bitcoin Cash to customers. I think this is a grave mistake and we will not be trading with them over the next few days.
• Chris has contacted exchanges to find out more about which will support Bitcoin Cash. Since Poloniex replied in the negative, we will cease trading with Poloniex tomorrow and all money will be withdrawln. If there are coins that are only offered on Poloniex, they will go into error and your payout proportions will go to 100% Litecoin. Please make note of this and we will post more in a separate thread.

FRISKIE wrote:@ Steve - all good news EXCEPT for one point - -

- everyone has been terrifically patient, but if the next capacity gains are immediately filled with additional hashpower it will be Unacceptable!

You guys need to have a plan ready to limit excessive system use by a small handful of overly keen miners and/or too many new users. - you have said it yourself, such gains are not normal, and while it reflects well on you guy's abilities to raise capacity so quickly, if this will become a never-ending story, then what good is it to anyone except you guys who rake in ever greater fees and profits?

PLEASE have a plan ready to implement should the August 6th upgrades be quickly filled by additional capacity - lock registration for a while, or limit concurrent workers, or cap worker hashrate or any number of things that you guys should have already done long ago, once you realized that the capacity race is too fast for you guys to win.

And make no mistake about it - you guys ARE NOT Winning the Race!
The system is perpetually on the brink of disaster, Stale/Rejects are HIGH, front end constantly crashes/freezes, stratum re-boots several times daily etc. . .

No Steve, you guys are NOT winning the capacity race and we are all very tired of suffering for it - the August 6th upgrades must return the system to Profitable Usability or I for one am going to feel like a real jackass for the losses I've overlooked these past weeks while trusting you guys to get it right.

Best regards.
FRISKIE

FRISKIE wrote:I do appreciate the response Steve, though the essential message is unchanged - -

Until you guys find a strategy to set max performance thresholds - with viable mitigation that kicks in and prevents the system from becoming overloaded . . nothing will improve for us miners, i.e. the system is not profitable for most of us for weeks now.

We are all focused on August 6th now - please have max thresholds for critical system parameters already set (OS first!), and some kind of limits that kick in when these thresholds are exceeded - this MUST be in place BEFORE you perform the upgrades or its useless . . not the temporary fixes and workarounds like now, but serious measures that effectively defend system performance. And Always >> Protect the lowest layers first, then add layer after stable layer on top!

If these thresholds and mitigation strategy are not in place prior to implementing the next upgrades, the capacity again fills up quickly and the pool remains useless to most of us.

And, I really don't mean this next comment to sound cynical, but it is important that you and Chris both understand that it is only the 2 of you who have really benefited from the tripled capacity - the fees are pouring in faster and faster now . .

. . but it's all meaningless to us until we can mine again profitably

Please get this one right Steve - god knows you have a loyal community who deserve it - FRISKIE

Steve Sokolowski wrote: I understand that you are disappointed, and there are a few complaints from others, but I haven't heard from most customers that the pool is unusable as you are describing. Is it possible that your experience differs from that of others because of a configuration issue?

QuoteIs it possible that your experience differs from that of others because of a configuration issue?

GregoryGHarding wrote:i still believe we should be limiting workers past a specific number, that way accounts don't gain value by locking out registration and we have a round robin style of availability, this will allow miners to failback to another pool after the set number of workers are reached and will reconnect once the set amount of workers drops below threshold. as it stands now, miners will connect to the pool even under performance issues and just sit there. this solves two problems... miners won't sit idle, holding open a connection, and maintains pool stability by limiting workers to a set number.. everyone gets their turn to mine profitably. i believe this is a great strategy and i would appreciate it if you guys took a serious look at this option. these issues are issues we as the community have been discussing as a solution via slack, everyone has had their input and we believe this one is the most viable.

steve, chris, we know you don't want to lose your user base. this is in no means a threat to leave, because god knows you've heard that time and time again. but even with these temporary changes, we've seen people pack up and leave, not only PH, but the unofficial community on slack. the hatred for downtime and pool issues is beginning to hit home for these guys, and patience can only go so far before people pop their top, or give up believing in promises.

if you need assistance or weight taken off your shoulders via support, i've offered to help you guys there both formally in chris's email, and informally here on the forums. i have 3 years experience in customer support and operating technical user base applications, again the offer is open to take some weight off chris.

we all hope you can seriously mull these opinions over and come to some sort of agreement with what the community put on the table in regards to some failsafe as mentioned limiting workers above, or something your technical minds can draft up. the lower diff cap is causing smaller miners to jump ship, leaving renters and large miners to rule the roost, and when it comes down to that, the profitability is just not there right now, both for renters to ROI and big miners to also hit their expected ROI goals.

thanks for reading, best regards.