All serious pools are located in major datacenters with 100 Mbps connectivity. Datacenters in China are well connected to other datacenters in China. Datacenters outside of China are well connected to datacenters outside of China. Datacenters in China have terrible connectivity to datacenters outside of China. So if you want to have good connectivity to the rest of the Bitcoin network, then either all of the Bitcoin network needs to be inside China, or all of it needs to be outside of China. Since we will never be able to agree on which of those is the right option, we have to deal with the fact that many pools will have bad connectivity to other pools.
Even if you have good connectivity, the nature of TCP gives you far less good throughput than you would expect. TCP uses a congestion control algorithm that limits the number of packets in flight to the TCP congestion window (cwnd). When a packet makes the trip successfully, cwnd gets increased by one. When a packet is dropped or times out, cwnd gets decreased by e.g. 50%. This is known as the additive increase/multiplicative decrease feedback control. With this feedback, the cwnd can double each round trip time (RTT). Thus, if your RTT is 1 ms, you'll send 1 packet at t=0ms, 2 packets at t=1ms, 4 packets at t=2ms, 1024 packets at t=10ms, etc, until you reach the capacity of your network.
That works pretty well in low-latency networks, but in high-latency networks, things start to suck. If your RTT is 200 ms, then it can take 2 seconds before you're able to scale your bandwidth to 1024 packets per 200 ms, or 7.6 MB/s. During those first two seconds, you will have sent a total of 2047 packets, or 3 MB (1.5 MB/s). So long distance links with high latency are in ideal circumstances only able to provide high bandwidth after they've been transmitting for a few seconds.
But that's only for ideal situations. Things get really bad when you start adding packet loss to the mix. Let's say you have a 50% decrease in cwnd for each lost packet, and you have a packet loss rate of 5% (fairly good for cross-China border communication). In this case, you will reach a cwnd equilibrium where every 20 packets gives you the same amount of linear increase from packets that arrive as you lose from dropped packets. (20 + x)*.50 = x, so x=20. With 5% packet loss, you will get a cwnd that oscillates between 20 and 40. At 1500 bytes per packet, that's an average of 45 kB per round trip time, or 225 kB/s for a 200 ms RTT. This is completely independent of your local pipe bandwidth, so even if you have a 40 Gbps connection, you're only going to get 225 kB/s through it per TCP connection.
And that's with a 5% packet loss rate. 5% is a *good day* in China for cross-border communication. On an average day, it's about 15%. On a bad day, packet loss is around 50%. With 50% packet loss, your average cwnd will be 2, and you'll get about 15 kB/s.
Yes, 15 kB/s. Even if you have a 1 Gbps pipe. I've seen it happen dozens of times.
Why does this happen in China? It has nothing to do with technology, actually. China could easily get packet loss to 0% if they wanted to. They just don't want to, because it does not align with their strategic goals.
China has three major telecommunications companies: China Unicom, China Telecom, and China Mobile. Of the three, China Mobile mostly just does cell phones and is of only tangential relevance. CT and CU are the big players. Both CT and CU have a policy of keeping their international peering links horribly underprovisioned. Why? Because there's no money to be made off of peering. By making peering slow and lossy, they can drive their international customers to pay a premium for bandwidth that doesn't suck.
And boy do they charge a premium. Getting a 1 Mbps connection from China Telecom in Shenzhen to Hong Kong (20 km away! but it crosses the China border) can cost $100 per month. Getting a 1 Mbps connection from Shenzhen to Los Angeles (11,632 km), on the other hand, will only cost about $5.
Yes, the longer the route, the cheaper the bandwidth is. That is not a typo.
China Unicom and China Telecom both charge more for shorter connections
because they can. They have a government-enforced duopoly, so in the absence of competition or net neutrality laws, they charge whatever they think they can get away with, regardless of how much the service actually costs them to provide.
Because the China-USA and China-Europe connections are cheaper than the China-Asia ones, most routers in Asia are configured to send data to the USA or Europe first if the final destination or origin is China. This is known in network engineer circles as the infamous Asia Boomerang. Bulk traffic from Shenzhen to Hong Kong will often pass through Los Angeles because that's the most economical option. This adds an extra 250 ms of unnecessary latency, and wreaks all sorts of havoc on TCP congestion control.
China Mobile, on the other hand, is usually willing to engage in fair peering practices abroad and does not charge predatory rates. Unfortunately, they mostly only serve mobile phones and rarely have fixed line offerings, so they aren't in direct competition with CT and CU for most of the market. But if you ever find yourself in China having trouble accessing websites abroad, setting up your phone as a mobile hotspot will likely give you better bandwidth than using the 200 Mbps fiber optic connection in your office.
So... do you put all your pools inside China, where most of the hashrate is? Or do you put the pools outside China, where friendlier governments and better telecommunications are? Or do you write a new protocol like Graphene that compresses data so much that it doesn't matter if you only get 15 kB/s? Or -- and this is my favorite option -- do you stop using TCP altogether and switch to UDP with forward error correction?
One thing is certain: you don't blame miners for being in remote regions with poor connectivity. That just isn't what's going on at all.
@Norway @Richy_T @awemany
