11
4
What are the main components one should focus on when trying to maximize a mining pool's performance? Assuming the code is pretty optimal (there aren't any inefficiencies), what should a pool owner devote their attention or resources to? I'm thinking about factors such as hardware speed, internet speed, latency, or some additional features, like long polling, and what priority should those have.
7
The code isn't optimal especially not on the merged mining side. Currently there is no optimal method to handle both block chains without a more advanced miner-pool communication protocol.
Excluding merged mining issues, latency is a large factor. When a block change occurs every single miner's effective hashing power is zero until they begin working on updated block header. Thus a pool's effective hashing power goes from total hashing power down to 0 and then rises as miner's are updated. So pool's long term effective hashing power depends on how quickly it can deal with a block change.
This involves three components.
Detecting block change. A good pool should have large number of connections to the Bitcoin network to minimize the delay in learning of block chain. A good pool operator will ensure they maintain connections "close" (within 1 or 2 hops) of every major pool.
Recalculating block headers. During a block each miner will complete their work at differing times and thus getwork requests are staggered. However when a block changes the pool needs to update every miner's block header at once. A pool lacking sufficient processing power to quickly compute block headers will have miners working on stale work longer and thus have a higher average stale %. Updating miners in the order of their hashing power could reduce the pool's overall stales slightly. I don't know if any pool currently does that.
Update miners. The latency of the miner's link is beyond the control of the pool but a pool can improve efficiency by having multiple pool servers reducing the number of hops to all miners. Pool servers should be located as close to miners as possible. A pool consisting mostly of miners in Asia shouldn't use US East Coast datacenter for example.
NTimeRolling reduces the number of communications (getworks) required for a given number of hashes. this makes the pool more efficient as a given amount of hardware can support more clients however it doesn't reduce load at a block change.
Implementing Long Polling ensures that miners are notified when a block change occurs (minus latency indicated above) rather than continuing to work on stale data until complete. Completing one nonce range takes roughly 10 seconds for a 400MH miner. Without long polling on average the miner will waste 5 seconds per block change working on data that can never produce a valid block. Given block changes occur every 600 seconds that is roughly 1% of CPU time wasted hashing invalid block headers. Slower miners have longer period between getworks and thus waste a greater % of GPU time. No pool can be efficient without a good Long Polling implementation.
Both NTimeRolling and Long Polling (LP) require a miner which properly understands these commands.
Would it be an improvement to have miners listen to the network and detect new blocks themselves? They will then be able to stop current work and at least save some electricity.
Also, are miners receiving the next block header (select transactions, etc., minus the previous block's hash) prior to starting work on a new block? That would allow the pool to only send new block's hash, or even have miners detect it themselves from the network.
Is nonce range allocation done in an efficiently? – nivs – 2013-04-02T23:14:33.020
1 @ 2: It seems that Slush has in fact implemented some prioritization of longpolling: https://bitcointalk.org/index.php?topic=1976.msg611014#msg611014
1@ThePiachu Nice catch and a wise decision by Slush. – DeathAndTaxes – 2011-11-09T00:00:17.990
1"Given block changes occur every 600 seconds that is a staggering 8.3% of GPU time wasted" - shouldn't that be 0.83%? – Highly Irregular – 2011-11-09T00:11:06.660
Further to the stale shares topic, presumably the block also changes as further transactions are received by the pool for inclusion in the block. Depending on how a pool managed that, it may add to the number of stale shares. – Highly Irregular – 2011-11-09T00:13:28.070
1@HighlyIrregular Your right on the 0.83% vs 8.3%. I fixed answer. Most (all?) pools don't consider a stale share just because transactions are included. The old transaction set is till valid. Only on a block change is the set not just outdated but completely invalid = stale. – DeathAndTaxes – 2011-11-09T02:08:09.390
@DeathAndTaxes Yes it would be crazy to reject a share (and possible solution worth 50BTC) as stale just because the transaction block had been updated to include 0.01BTC more in fees... however I also have met quite a number of crazy programmers... – Highly Irregular – 2011-11-09T08:24:53.273
3
The most critical factor is this: When a new block is discovered on the Bitcoin network, how long does it take the pool to get a new work unit based on the new block to the vast majority of its clients? This is determined by three factors:
1) Long Polling: If you care about performance, you have to support LP. It's that simple.
2) Network Latency: If the mining controller is on a slow link or the miners are located a long distance from the controller, this becomes a significant factor.
3) CPU on the Controller: The CPU can be 3% normally and you might think you're doing fine. But if it maxes out one core when a new block is discovered, this can be a significant factor in idle miners or stale shares.
3Hmm, this seems to be the 500th question on this SE;). – ThePiachu – 2011-11-08T20:12:45.263