Downtime this morning

I wanted to post a quick reply before going back offline to continue work on the performance improvements just to aggregate some of the points I've made elsewhere. Hopefully this will help people better understand our current issues.

1. The system is software limited. There are no faster singlethreaded processors available on the market. Hardware improvements will not resolve the issues.
2. 80% of support tickets regard crashes and issues that are best resolved by fixing the issues. Hiring a support representative doesn't make sense because there are no tickets when the system is working better.
3. Banning customers from sites is difficult to implement and would take just as much time as fixing the problem.
4. Hiring a developer will not solve this issue because it would take 2-3 months before the developer was trained, and the training would take away our time from fixing the problem.
5. We are spending 100% of our time on improving system performance and I've decided not to be active on the forums for the next two weeks.

I sincerely apologize to everyone here. I know that it's frustrating to many, and we want to provide quality service. That said, I think there are a lot of posts that tend to simplify the problems the system faces. Everyone is entitled to his or her opinion, but we'll just have to settle for a disagreement with users over the level of training required for anyone else to make any immediate progress on these issues, and over the extent to which hardware can resolve the particular problems the system is facing. Of course, we do want to get help after the immediate issues are resolved, when there is time for that training.

Thanks for your understanding. I know that some customers will disagree and may decide to depart, and I acknowledge that. However, I hope that people can see that we've increased capacity from 600 GH/s to 1.5TH/s in just two months, and agree with me that the rate of performance improvements that we are making is higher than any other project I, at least, have ever worked on.

Thanks again! I'm not going to be active around here except to reply to a few posts here and there, because I need to cut out other things to focus on development.

frphm wrote:

FRISKIE wrote: Pause registration.

How would this work in practice as a single user can point as many miners as they want at PH under a single account?
There's no miner registration process and even if there were how would you account for 1 user that has 10 x A2 Minis@33Mh/s and another that has 10 x L3+@504MH/s (or Baikal minis vs Bitmain D3s)

Plus if the system is hitting CPU limits with the existing user base (and their combined hash/sharerate), then limiting user registrations would only affect future failures once capacity is increased, it won't reduce user numbers and hashrates below what they are today (assuming they remain constant). On that point I wonder how many existign Scrypt miners here are waiting on and receving L3+s this month and next and will be adding more hash under exisiting accounts?

Has splitting X11 and Scrypt across different mining servers been considered. Apologies if we've been there, I'm late as usual to this party.

frphm wrote:

FRISKIE wrote: Implement reasonable safeguards against NH abuse.

Perhaps working with NH to configure their Web UI or stratum proxies with a filter/policy that effectively restricts low diff and high share rates when pointing them at PH may be an option? When both systems are stable everyone wins so there's economic motivation for NH admins to implement this to keep their users happy when pointing hash at PH.

vinylwasp wrote: How would this work in practice as a single user can point as many miners as they want at PH under a single account?

Limit unique IPs under existing accounts. The idea would be that if we experience problems now, we limit new miners being added and then work to expand capacity, then open up registration and adding miners up to the capacity limit again.

This is opposed to the current system of smashing into capacity limit, pool goes down, add capacity, pool instantly exceeds capacity again because of NH, pool goes down, rinse and repeat infinitely.

That won't work either as most users will have multiple miners behind a single NAT address per location and doesn't account for hosted miners, and local stratum proxies. Limiting connections won't work either because of the variation in hash power per miner where you could have 1 account with 330 MH/s across 10 Innosilicon A2 Minis and another with 5040 Mh/s with 10 Bitmain L3+s; each with 10 connections. The only way you could attempt to do this is to limit the actual submitted hashrate per registered user, and I suspect that's a lot of low level re-work for a very small gain that can be worked around easily by registering multiple accounts.

What's happening is in effect a Flash Crowd, demand driven Denial of Service event which news outlets, gambling and ticket sites often experience.
The solution to demand is always more resources whether its more hardware or more sites.

vinylwasp wrote: The solution to demand is always more resources whether its more hardware or more sites.

Of course a scaleable architecture helps too.

Dooh, I quoted when I shoulda edited.

vinylwasp wrote:That won't work either as most users will have multiple miners behind a single NAT address per location and doesn't account for hosted miners, and local stratum proxies. Limiting connections won't work either because of the variation in hash power per miner where you could have 1 account with 330 MH/s across 10 Innosilicon A2 Minis and another with 5040 Mh/s with 10 Bitmain L3+s; each with 10 connections. The only way you could attempt to do this is to limit the actual submitted hashrate per registered user, and I suspect that's a lot of low level re-work for a very small gain that can be worked around easily by registering multiple accounts.

What's happening is in effect a Flash Crowd, demand driven Denial of Service event which news outlets, gambling and ticket sites often experience.
The solution to demand is always more resources whether its more hardware or more sites.

This only works when it's possible to parallelize the algorithms. The problem is that coin selection is inherently singlethreaded. One person's assignment is directly influenced by the assignment of all other people.

Our first step right now is to create additional processes to do other things than coin selection, so that the coin selection core can concentrate only on that. There are five different "core components" we hope to separate. The first, which we are working on now, is share processing. Share-processing is computationally intensive because the weights of each miner and the sell price of that coin need to be calculated. However, on August 6 we believe that we will be able to permanently eliminate share processing from ever being an issue again, because we will be able to support many processes doing it simultaneously. We'll be able to just buy more cores if share processing ever becomes a problem again.

Once we solve that, then we will sever block processing next, and then sever coin assignment by algorithm, and then finally sever stratum communication. In each case, we'll be able to support multiple "cores" of each communicating through WAMP.

Steve Sokolowski wrote: However, on August 6 we believe that we will be able to permanently eliminate share processing from ever being an issue again, because we will be able to support many processes doing it simultaneously. We'll be able to just buy more cores if share processing ever becomes a problem again.

Does this mean that lower diff will no longer be an issue?

Yes.