Something seems off with the routing. I'm on one of the big 3 internet providers in Singapore, and I'm getting a 300-400ms latency to their ping server (speedtest-sgp1.digitalocean.com) and to a droplet which I just started.
DO <-> SL ~2ms
DO <-> AWS ~2ms
Me <-> SL ~15ms
Me <-> AWS ~15ms
Me <-> DO 350ms
I'm glad you pointed out the importance of checking the reverse path. Traceroute can often be misinterpreted. I'd recommend the NANOG presentation "A Practical Guide to (Correctly) Troubleshooting with Traceroute".
13 ae-6.r21.tkokhk01.hk.bb.gin.ntt.net (129.250.4.26) 61.168 ms 59.223 ms 59.476 ms
14
p64-2-1-2.r22.tokyjp01.jp.bb.gin.ntt.net (129.250.4.36) 108.462 ms
p64-2-1-3.r23.tokyjp01.jp.bb.gin.ntt.net (129.250.4.56) 112.855 ms
p64-2-1-2.r22.tokyjp01.jp.bb.gin.ntt.net (129.250.4.36) 122.359 ms
15
as-6.r21.sngpsi02.sg.bb.gin.ntt.net (129.250.5.157) 132.448 ms
as-5.r21.sngpsi02.sg.bb.gin.ntt.net (129.250.4.151) 132.776 ms
as-6.r21.sngpsi02.sg.bb.gin.ntt.net (129.250.5.157) 142.057 ms
16 ae-6.r00.sngpsi02.sg.bb.gin.ntt.net (129.250.6.105) 138.498 ms 139.374 ms 139.766 ms
17 116.51.27.150 (116.51.27.150) 147.845 ms 146.281 ms 147.800 ms
18 103.253.144.242 (103.253.144.242) 136.963 ms 131.681 ms 137.451 ms
It's a coinflip. Some users will route straight to Asia (because their ISPs are buying the right bandwidth) and be better off with Singapore. Some will route to Asia via the western US, and will be better served from California.
It's bad enough that when Blizzard sold region-locked Starcraft 2, the Australian version of the game was the only one which gave players access to two regions - Southeast Asia and North America.
Fortunately, it's 2014 and both AWS and Rackspace are in Sydney now. If you're serving Australians, I think you should just use one of them.
We are seeing some issues with the network transit providers that we selected in Singapore where some of the traffic is being routed optimally. Bryan has been working hard on determining the best mix of network transit providers and peering to setup to get this resolved as quickly possible, unfortunately when it comes to provisioning network cross connects with service orders and contracts its not a 24-48 hour turn around, but we are actively working on this very diligently.
This is actually expected behavior. I'm Singaporean and we are well-known for this. Each request, even from Singapore to a Singapore-based site takes multiple hops
"Australia is hit or miss depending on what provider or area your in. We had some delays in our peering installs and you should see some improvement within the next couple weeks. I will keep you update every few days on the progress since your in one of those areas we cannot immediately optimize the routing too."
Peering from Sweden via Telia is excellent, considering the distance.
Ping statistics for 128.199.255.139:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 213ms, Maximum = 215ms, Average = 214ms
Comments
Something seems off with the routing. I'm on one of the big 3 internet providers in Singapore, and I'm getting a 300-400ms latency to their ping server (speedtest-sgp1.digitalocean.com) and to a droplet which I just started.
Checking their BGP, they're only peering with NTT and Teliasonera: http://bgp.he.net/AS133165
Honestly, I don't understand this stuff but possibly this is why things are so bad...?
Peering matters a lot. Routing is often more of a financial decision than a technical one.
My tests from dedicated servers hosted with the big three in Singapore showed this:
I don't have a droplet with DO to perform the reverse path.So this looks quite unoptimised for actual Singaporean users right now.
I'm glad you pointed out the importance of checking the reverse path. Traceroute can often be misinterpreted. I'd recommend the NANOG presentation "A Practical Guide to (Correctly) Troubleshooting with Traceroute".
https://www.nanog.org/meetings/nanog45/presentations/Sunday/...
Not best from Thailand either.
This is some traceroute result from True IDC
13 ae-6.r21.tkokhk01.hk.bb.gin.ntt.net (129.250.4.26) 61.168 ms 59.223 ms 59.476 ms
14 p64-2-1-2.r22.tokyjp01.jp.bb.gin.ntt.net (129.250.4.36) 108.462 ms p64-2-1-3.r23.tokyjp01.jp.bb.gin.ntt.net (129.250.4.56) 112.855 ms p64-2-1-2.r22.tokyjp01.jp.bb.gin.ntt.net (129.250.4.36) 122.359 ms
15 as-6.r21.sngpsi02.sg.bb.gin.ntt.net (129.250.5.157) 132.448 ms as-5.r21.sngpsi02.sg.bb.gin.ntt.net (129.250.4.151) 132.776 ms as-6.r21.sngpsi02.sg.bb.gin.ntt.net (129.250.5.157) 142.057 ms
16 ae-6.r00.sngpsi02.sg.bb.gin.ntt.net (129.250.6.105) 138.498 ms 139.374 ms 139.766 ms
17 116.51.27.150 (116.51.27.150) 147.845 ms 146.281 ms 147.800 ms
18 103.253.144.242 (103.253.144.242) 136.963 ms 131.681 ms 137.451 ms
Another HNer in Thailand , I'm in Bangkok where are you ?
Not the best from Australia yet either.
Despite what DO said in their announcement, my experience says that Australian users are better served by servers in California than Singapore.
They're all terrible, but SFO does look better for me than the rest.
It's a coinflip. Some users will route straight to Asia (because their ISPs are buying the right bandwidth) and be better off with Singapore. Some will route to Asia via the western US, and will be better served from California.
It's bad enough that when Blizzard sold region-locked Starcraft 2, the Australian version of the game was the only one which gave players access to two regions - Southeast Asia and North America.
Fortunately, it's 2014 and both AWS and Rackspace are in Sydney now. If you're serving Australians, I think you should just use one of them.
tpg user from sydney, routed through SanJose, 4xx ms
Check your routing, I'm on the east coast with Level3 and I get 250ms:
PING speedtest-sgp1.digitalocean.com (128.199.255.139) 56(84) bytes of data.
64 bytes from 128.199.255.139: icmp_req=1 ttl=51 time=256 ms
64 bytes from 128.199.255.139: icmp_req=2 ttl=51 time=256 ms
64 bytes from 128.199.255.139: icmp_req=3 ttl=51 time=256 ms
64 bytes from 128.199.255.139: icmp_req=4 ttl=51 time=256 ms
64 bytes from 128.199.255.139: icmp_req=5 ttl=51 time=256 ms
--- speedtest-sgp1.digitalocean.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 256.248/256.456/256.851/0.211 ms
We are seeing some issues with the network transit providers that we selected in Singapore where some of the traffic is being routed optimally. Bryan has been working hard on determining the best mix of network transit providers and peering to setup to get this resolved as quickly possible, unfortunately when it comes to provisioning network cross connects with service orders and contracts its not a 24-48 hour turn around, but we are actively working on this very diligently.
This is actually expected behavior. I'm Singaporean and we are well-known for this. Each request, even from Singapore to a Singapore-based site takes multiple hops
A response from support:
"Australia is hit or miss depending on what provider or area your in. We had some delays in our peering installs and you should see some improvement within the next couple weeks. I will keep you update every few days on the progress since your in one of those areas we cannot immediately optimize the routing too."
So sounds like those delays are the issue.
Peering from Sweden via Telia is excellent, considering the distance.
From Germany over France, Netherlands and the US:
--- speedtest-sgp1.digitalocean.com ping statistics --- 50 packets transmitted, 50 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 277.878/291.729/306.448/5.964 ms