Still getting massive (50%+) packet loss to many US servers.

Try Singapore server. Normally I get faster speedtests there.

You forget that Google's DNS will try to return the closest host to you. You can also ping Google "in Germany" (www.google.de) and get the same ping time. It has nothing to do with connecting to Australia.


Not really. The time it takes for your torrent to reach "full" speed is based on how long it takes you to find enough peers to fill your pipe. Latency (ping) is the tiniest portion of this, insignificant really.


You're missing the point about why packet loss is a problem, and why it is much worse for speed than latency (which, by comparison, is not very important at all except for high interactivity applications like gaming).

With TCP, all the data will eventually get to you, even at moderately high rates of packet loss (unless you give up and stop waiting).

But it becomes very slow. That's because the remote computer will send you a bunch of data, but after a while it will stop sending if it doesn't receive any confirmation from your computer that the data has arrived. If either the data from the remote server to you, or the acknowledgement from you to the remote server, keeps getting lost, then both computers will hang around waiting until a timeout period expires, then they will try to send again. The timeout period can be several seconds, which is far longer than even the longest live link latency.


No, your understanding of latency's effect on transmission is incorrect. With TCP, the sending machine does not wait for each acklowledgement before sending the very next packet. As long as it is receiving acknowledgements from recent packets, it will continue to send data in arrears.

There's a pretty clear explanation here: http://www.osischool.com/protocol/Tcp/slid...indow/index.php and a Flash animation at the bottom of the page that demonstrates what is happening. The gap between the upper (sender) and lower (receiver) is the latency.

With 100ms ping or 600ms ping, the difference in total send time is not that high, and as the amount of data being sent increases, the difference in total send time doesn't increase. That is, it might take about 1000ms (one second) longer to send your 25KB at 600ms latency vs 100ms latency, and if you were receiving 500GB instead of 25KB, the totaly difference in transmit time for 100ms vs 600ms latency would still be only about 1000ms unless there was also packet loss. Latency is really not that big a deal for data transfer.

I am finding it considerably worse than it was before April.

On any IP I have high packet loss to many destinations for much of the day, and high latency (900ms+) for part of the day as well. It wasn't like this before.

March 2009 is the last time I was able to use Streamyx without going through VPN or proxy. The international link has been basically useless all of April.

Not related.

Yeah, everyone can get decent connections to a few select places.

The problem is that each Streamyx customer can only get good connections to about 50% of the internet. The rest is riddled with packet loss.

Using .my or .au doesn't make any difference for Google.

If you look up www.google.com.(wherever) you get their geo-targeted DNS which should find the data centre nearest you. From Malaysia you get 216.239.61.104 - it's the same if you use www.google.com.my or www.google.fr or www.google.com.mx or anything else. It's about 35ms from TMnet so it has to be quite close to here, maybe India?

google.com (without the www) and google.com.my and so on get you a different set of servers, always located in USA.

As of yesterday, things seem to be improved compared to the past month.

On 60.49, brf03. 350ms pings and normal throughput to most US destinations, but there are some where it's still quite bad.

Major packet loss to, e.g., AS27357 & AS3561, and 550+ms pings on the occasions when packets do get through.

Prior to all these problems I generally had 250-300ms pings and no packet loss to all.