The size of a miner is completely irrelevant. Hash is hash. There is no such thing as a miner draining the pool (unless he's purposefully withholding blocks), or for that matter a smaller miner somehow making a larger miner's hash less wasted. Miner 1 has no impact on the probability of miner 2 hitting a block, regardless of the hash rates of either miner.
Remember... that guy with 1.4PH could have a warehouse with 100 S9s, or 234 A721s, or 1273 S5s or 3091 S3. His hardware is no different than the guy with a single S3 in his basement... he just happens to have a whole lot more of it.
Yes, hash is hash. However, a pool stratum server can be overwhelmed with too many TCP connections by attackers with numerous low hash miners. It is my understanding that some pool operators have set minimum hash rate in order to protect pool resources from this form of attack. Although, I could be mistaken.
On a pool run using software that requires a lot of hardware and can't grow without concerns, that may be the case.
That, of course, is not the case here.
Here, the number that has an effect on the network is simply just "Workers" and that relates pretty close to the actual limiting number: total SPS (shares per second)
A botnet wont actually affect SPS since e.g. it takes ~500 thousand CPU miners to match an S9.
The main reason I don't allow botnets is coz they waste resources and directly represent someone stealing from someone else. No one runs a botnet they pay for unless they are a moron. I'll save those morons some money by not allowing them to mine here.
If there were botnets mining here, then it would affect the the total time it takes to send out a block change.
That would show as a higher than normal rate of stale and orphan blocks.
Of course, everyone would also be able to see the botnets due to there being a silly high "Workers" count.
I block CPU and GPU miners coz they are a waste of resources and I don't want them here wasting resources.
Consider that, on a work change, a 1PHs proxy requires as much network as a CPU miner - so yep it's a complete waste.
Aside: as the pool stands at the moment, it would be well over a few hundred PHs before I 'might' start to notice performance problems.
The code is well threaded in both cases, ckpool and ckdb, and in the case of ckpool, automatically increases threads as needed, and ckdb, I can tell it to add threads as needed, while running, but the main server is far from caring about the workload
