Post
Topic
Board Pools
Re: [850 TH] Slush's Pool (mining.bitcoin.cz); TX FEES + VarDiff
by
KNK
on 27/02/2014, 11:51:06 UTC
One certainty is that as the pool grows then so does the traffic into servers and it doesn't matter how much hashing goes on, it has to get to a server and 800-825TH seems to be the current 'lucky' number range.

No, the traffic problem is what vardiff solves.
True, but binja9 is also right - vardiff solves the problem for a single miner and his hashrate, but more miners means more traffic.
If a single miner points more of his equipment at Slush, the pool will change his vardiff and the traffic and server load will remain the same.
If 1000 miners point 1Gh at the pool they will increase the traffic and the server load for just 1Th increase.

Still the pool hashrate is not related to the load it takes to serve it.

I am sure in such cases Slush just starts an additional stratum back-end (or adds a CPU to the virtual server instance) to take the load. With getwork the load was many times more than with stratum, so we are far from the limit. I also have a reason to believe that most of the processing is done in the startum back end servers, so adding another one scales almost linearly.

If the load got too high, then Slush could simply increase the minimum variable difficulty. I don't think that will be a problem though - the pool isn't attracting as many new miners as other pools.
VarDiff with Slush aims at 15-20 shares per minute. Setting a higher minimum diff will increase the variance for the slower miners and may force them to move away.
If the load is high because of very slow miners not worth the additional server - Yes higher min diff is the solution, but if the load is high because of increased number of 'average speed' miners it is not a solution.

I am sure Slush is smart enough to figure it out when and what to do, when he has much more insight on the load than us - that's why i don't buy the conclusion of pool hashrate being a limiting factor.