fpart VS www.submarinecablemap.com

Native rsync is terrible for lots of small file as it copies each file one by one sequentially. If you have lots of cores to work with, use the fpsync utility that comes with the fpart command to run parallel rsync's. You can easily saturate a 10Gb link with multiple rsync processes in parallel

You should probably use something like fpsync and multiple rsync jobs to get the most bandwidth.

My favorite free solution is fpsync/fpart from https://github.com/martymac/fpart -- basically that is a highly optimized filesystem crawler and indexer that can spit out balanced lists of files to transfer to a waiting army of parallel rsync workers. Tools are provided to manage the rsync fleet. Combining fpsync/fpart with an army of parallel rsync workers is a great design pattern especially for HPC as you can farm the rsync workers out to compute nodes

I've migrated data from our Isilon to zfs hostA using the fpsync tool that comes with the fpart utility. I get reasonably good throughput from this. 15TB in 5 and 1/2 hours

Hillsboro, Oregon's network connections have a lot of advantages. It's worthwhile checking it out here: https://www.submarinecablemap.com/ --Katie

Now you can say that you've 'seen' the internet. You can see the map here

Looking at this site there are 3 companies that own/operate undersea cables to the US

This unfortunately won't get you the whole picture, but using some tools you can determine how your traffic is routed in one direction, and possibly the geographic path it takes as well. For example, in mine, I can see based on the names that I know my traffic is going through Equinix San Jose (equinix-sj), then likely to Palo Alto (pao1, palo), then to Los Angeles (lax). By looking up who owns what IP addresses, I can also see that my traffic goes from my local ISP (Sonic) to Telia, then to Amazon. While concerning, you can effectively ignore all of the hops that say "Request timed out." as those just mean the hop wasn't responding to pings (or in the case of the very end, the game server itself likely doesn't respond to pings). Unfortunately though, this is only half of the picture, as this doesn't let me see the path from anets servers to me. For that, I would need an AWS instance with similar routing rules to anet's servers. Still, this may be useful, as I'm guessing your traffic is using a submarine cable to get to anet's servers in the US. These unfortunately often have issues or maintenance that can cause measurable connectivity impacts - I'm in the US and we have a node on the NLNOG Ring, and we get alerts of connectivity issues with Europe on a regular basis.

Well. Significantly more than that due to latency from switches etc and also because of the fact that there's so little land along the equator, meaning there's only one cable that travels roughly equatorially. It's from Fortaleza, Brazil to Kribi, Cameroon: https://www.submarinecablemap.com/

If you set up a bunch of good first-surface mirrors, I'm pretty sure you could get to pretty much the speed of light. You'd have to put them pretty high up in the air to avoid hitting things (a problem for cables as well, obviously) but putting the beam 2km in the air would still only lengthen the path by 4pi km, or .03%.

I have always found it very neat that the propagation speed of a light wave in glass is roughly the same as electrical waves in a coaxial cable. Both are shockingly slow compared to air/vacuum, but for completely different reasons. In both cases the advantages in signal integrity are immense.