Quote from: phenom on June 19, 2011, 09:47:20 AM

What's the point in telling people to choose a specific server? Can't you have some sort of load balancing so that if one server goes down you can redirect users to another/backup? I've switched back to deepbit for now as your servers are terrible. Always overloading or going down. The fees from deepbit outweigh the downtime I get from your servers at the moment.

I think the problems so far is that BTC Guild has relied on Round-Robin DNS to "load balance" before picking servers. Problem is, RR-DNS is NOT load balancing, but load distribution. Just like pools get lucky and unlucky, RR-DNS can overload and underload servers since it's just random.

The current "solution" is to pick a server, which might be nice in theory, but BitCoin mining isn't really suppose to be a full time job. If you're not monitoring the IRC chat and/or your miner's logs, you could miss out on quite a lot of money in no time at all. As was the case when UK's MySQL daemon had connectivity issues with US West. Everyone who pointed to the UK, as the website suggested when one of the other servers got overloaded, probably experienced at least an hour or two of idle miners last night, possibly more if their router/ISP/computer cached the subdomain's DNS longer than normal.

My proposed solution is to handle load balancing in mining clients intelligently by use of data provided by the pool's API. At the moment, the pool's API doesn't give enough true load data for this to happen (but rather, quite meaningless, relatively, hash rates per server, which are estimations, no less).

The API would need to be something along the lines of this... http://pastebin.com/PHNbU0u1
The preferred load function doesn't just reference server load, but also server capacity. An ideal function:

Code:

function server_load() {
$load = explode(' ', file_get_contents('/proc/loadavg'));
$cpus = substr_count(file_get_contents('/proc/cpuinfo'), 'processor');

return $load[2]/$cpus;
}

Between every few blocks, clients should check an improved pool stats API and determine the best server to connect to with weighted odds, as to not have every client jumping on the idlest server. For example, using the ideal json response from above, the ideal odds for hitting each server:

uswest.btcguild.com - 26.12%
useast.btcguild.com - 25.17%
nl.btcguild.com - 25.17%
uscentral.btcguild.com - 23.54%
uk.btcguild.com - 0% (offline)

If every large pool can adopt this same API design, more clients can be aware. And since the chance part of it can be done in the API of the server (the "suggested_server" variable), each API hit can run the calculations and pick a server for the client. The client only needs to check the API between every few blocks and listen.