Choosing a datacenter
I have been using Linode for half an year now. I love Linode for the VPS boxes, interface, great support and documentations.
I have been using a few boxes in different datacenters, but recently I want to consolidate to only one server. (save cost, and have less need.) The following network performances are compared with fresh linodes without other stuff running, and from a 100Mbps connection in Hong Kong.
Tokyo
Download speed (from Linode): up to 8MB/s
Upload speed (to Linode): maximum 300KB/s
Ping: 60ish ms
Fremont
Download speed: around 400KB/s
Upload speed: max 1.4MB/s
Ping: 160ish ms
Dallas
Download speed: around 600KB/s
Upload speed: max 1.4MB/s
Ping: 190ish ms
The Tokyo DC satisfies me by that wonderful ping and download speed, but I am really troubled by that upload speed. If the routing is so good, why the upload speed is that low?
What I sometimes do is to open a US node for a day, just to upload data and transfer it to a Tokyo node. This is kind of stupid, but I couldn't find another way to cut my upload time.
Maybe I should take a US node and be satisfied with that download and upload speeds? It really feels bad when I know I could download ten times faster with Tokyo nodes…
Do you guys have any idea on how to pump up the Tokyo upload speed? Or any other comments?
Thanks!
5 Replies
Considering the poor speeds you're seeing on all three linodes, I'm tempted to blame the latter two, your home connection or your ISP's routing. 100 megabit fibre is all well and good, but if you combine it with an oversaturated backbone with terrible routing…
Yea I won't say the home connection is perfect in overseas routing… but is it normal to have 10 times speed difference in download and upload to a same location? Isn't the routing the same?
@kevinamadeus:
Isn't the routing the same?
Not necessarily.
There are lots of routers and cables between Hong Kong, Tokyo, and the USA. Any part of that network could be congested in either direction. Most people simply don't notice because 500KB/s is fast enough for streaming HD video. Hey, in most parts of North America, it is either impossible or costs a fortune to get more than 1MB/s on a home connection.
@kevinamadeus:
Yea I won't say the home connection is perfect in overseas routing… but is it normal to have 10 times speed difference in download and upload to a same location? Isn't the routing the same?
Not necessarily (though for my part I wish it were more often). For example, I regularly (but not 100% of the time) find myself with asymmetric routing between my home connection in New York to the Dallas data center. The path is consistently symmetric from, for example, the Newark data center. Annoyingly, in almost all cases I've tracked connectivity issues, the most likely problem point was a transit provider only existing on the return path in cases when the asymmetry was present. Makes troubleshooting tricky.
Since IP routing is (by and large) purely destination based, and provides can make choices about how long to stay internal to their own network before handing off a packet if multiple exit points are present - and depending on the network announcements and metrics involved - it's not that hard to get such scenarios. I suspect it's more prevalent nowadays than in the earlier days of the network where there were fewer connection points exchanging routes, but it's been a long time since I looked closely.
Of course, this need not be a problem if both paths are of roughly the same quality (loss, latency and bandwidth), or in the case of TCP, if the return path (opposite of primary data transfer) is at least within an order of magnitude of the forward path. In fact, the bandwidth asymmetry of most consumer broadband connections (at least in the US) depends on this fact.
But if the two paths are not of similar quality, you can absolutely get pretty significant differences in performance - think of uploading over that home asymmetric connection versus downloading.
– David
traceroute to TOKYO NODE, 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) 0.331 ms 0.379 ms 0.315 ms
2 210006193065.ctinets.com (210.6.193.65) 2.209 ms 2.482 ms 2.588 ms
3 10.239.5.9 (10.239.5.9) 1.992 ms 2.026 ms 2.001 ms
4 014199254197.ctinets.com (14.199.254.197) 10.662 ms 10.677 ms 10.656 ms
5 014136129014.ctinets.com (14.136.129.14) 2.334 ms 2.394 ms 2.373 ms
6 118.155.194.125 (118.155.194.125) 70.062 ms 70.178 ms 70.128 ms
7 otejbb204.kddnet.ad.jp (59.128.7.194) 64.455 ms 63.870 ms 63.806 ms
8 cm-fcu203.kddnet.ad.jp (124.215.194.180) 65.607 ms 65.600 ms 79.139 ms
9 124.215.199.122 (124.215.199.122) 66.561 ms 66.483 ms 66.398 ms
10 TOKYO NODE 66.288 ms 67.814 ms 66.704 ms
traceroute to HOME, 30 hops max, 60 byte packets
1 106.187.33.2 (106.187.33.2) 0.471 ms 0.539 ms 0.575 ms
2 124.215.199.121 (124.215.199.121) 13.394 ms 13.395 ms 13.378 ms
3 otejbb204.kddnet.ad.jp (124.215.194.177) 1.952 ms 1.932 ms 59.128.4.121 (59.128.4.121) 1.873 ms
4 tr-ote124.kddnet.ad.jp (59.128.7.148) 1.878 ms tr-ote124.kddnet.ad.jp (118.155.197.18) 2.045 ms tr-ote124.kddnet.ad.jp (59.128.7.148) 1.829 ms
5 118.155.194.158 (118.155.194.158) 64.408 ms 64.432 ms 64.419 ms
6 014136129017.ctinets.com (14.136.129.17) 72.000 ms 71.111 ms 70.995 ms
7 014199254198.ctinets.com (14.199.254.198) 70.722 ms 69.992 ms 69.967 ms
8 061093019253.ctinets.com (61.93.19.253) 65.006 ms 65.171 ms 65.158 ms
9 * * *
10 HOME 65.772 ms 65.907 ms 65.902 ms
````
Traceroute results are quite symmetric :\