Slow internet past couple of weeks?

[samran]

Anyone have the same experience? IT bloke at work says there has been issues with the international gateway at CAT. Not sure if this should impact my ToT one, but it has certainly been a dog of late.

[gerry123]

so cat has been a dog ?? sort of reincarnation

[JAS21]

My wife has been complaining for a few days that our internet is slow ... her You Tube! she just ask me to phone TOT and complain ...I just got these though, TOT are going to say okay??

Edited September 26, 2014 by JAS21

[Thaimaishoe]

Anyone else see a connection?

http://www.thaivisa.com/forum/topic/759944-massive-internet-surveillance-to-begin-monday-report-claims/

Maybe they should have installed it on a new computer, not that old 386 that was holding the door open.

[WhizBang]

The undersea cable linking Thailand with Hong Kong has been damaged, hence the current problems.

From what I have read, they will START the repair operation October 1 and are expected to finish around October 16/17, weather permitting.

[Pib]

My wife has been complaining for a few days that our internet is slow ... her You Tube! she just ask me to phone TOT and complain ...I just got these though, TOT are going to say okay??

T1.PNGT2.PNG

Expect the Speedtest.net download speed result from Europe is completely bogus as it's basically the same as the other in-Thailand speed test result. Speedtest.net as a "flash-based" speedtester can be easily fooled by local cache servers...that is, you think you are speedtesting to that far off farangland server but the results are really coming form a local cache server. Speedtest.net is fine for local speedtesting, but don't use it for international speedtesting. Use a Java-based tester which are much harder to fool.

[npboy99]

The undersea cable linking Thailand with Hong Kong has been damaged, hence the current problems.

From what I have read, they will START the repair operation October 1 and are expected to finish around October 16/17, weather permitting.

Whizbang is right - see article here http://www.techinasia.com/southeast-asia-slow-internet-misery-broken-undersea-cable-needs-20-days-to-repair/

[jpinx]

There seems to be a new thread started on this subject regularly. There's always something up, international gateways, undersea cables, "filtering", individual isp's DNS issues, etc, etc.

I suppose the only solution is your own satellite link - once the slack is taken up they go quick

[csabo]

The undersea cable linking Thailand with Hong Kong has been damaged, hence the current problems.

From what I have read, they will START the repair operation October 1 and are expected to finish around October 16/17, weather permitting.

Interesting information. I wonder exactly how such a cable designed for this task is damaged. Earthquake, hydrothermic vent, kraken??

[franck1972]

In my building, they posted a notice saying that internet to oversee website will slow down due do the typhoon in Hong-Kong.

The AAG submarine internet cable has been damaged and seems to be responsible for this.

[jpinx]

The undersea cable linking Thailand with Hong Kong has been damaged, hence the current problems.

From what I have read, they will START the repair operation October 1 and are expected to finish around October 16/17, weather permitting.

Interesting information. I wonder exactly how such a cable designed for this task is damaged. Earthquake, hydrothermic vent, kraken??

Deep sea bottom trawler

[Straight8]

The undersea cable linking Thailand with Hong Kong has been damaged, hence the current problems.

From what I have read, they will START the repair operation October 1 and are expected to finish around October 16/17, weather permitting.

Had a techie from True over today, even though they had a recorded message about that problem you mentioned, I explained all the symptoms and they still sent someone over.. So I showed him the dial-up like download speed I was getting.. told him I was getting faster speed on my old 56.6k modem...

Anyway, what are you guys getting? Apart from slow download speeds, getting a lot of "Timeouts" when trying to access some sites, whilst others work fine.

I was told it will be fixed by the 6th October, meaning about the 20th.

Today, other than the slow downloads on Port 119, interent has been solid and responsive.

[oztaurus]

My wife has been complaining for a few days that our internet is slow ... her You Tube! she just ask me to phone TOT and complain ...I just got these though, TOT are going to say okay??

T1.PNGT2.PNG

Expect the Speedtest.net download speed result from Europe is completely bogus as it's basically the same as the other in-Thailand speed test result. Speedtest.net as a "flash-based" speedtester can be easily fooled by local cache servers...that is, you think you are speedtesting to that far off farangland server but the results are really coming form a local cache server. Speedtest.net is fine for local speedtesting, but don't use it for international speedtesting. Use a Java-based tester which are much harder to fool.

I find that www.testmy.net is a good test

[GOLDBUGGY]

Was having the same problem to. Then I decided to buy an Air Card from 7-11, replaced my IT Card with it, and now have lightning speed. My wife to, on her Tablet.

[Thaimaishoe]

My wife has been complaining for a few days that our internet is slow ... her You Tube! she just ask me to phone TOT and complain ...I just got these though, TOT are going to say okay??

T1.PNGT2.PNG

Expect the Speedtest.net download speed result from Europe is completely bogus as it's basically the same as the other in-Thailand speed test result.

Besides, the graphic clearly showes the bits directly overflying the Syrian conflict, which has been stopped for months. Clearly contrived data.

[matbkk]

We have just called cat which told us that "sharks had eaten the submarine cable".

[JeffreyO]

Regarding this. I have noticed problems related to connecting to sites in North America. As a network engineer, I will help breakdown how to test this in the future and how you can find what/where your problem is.

First, speed tests generally test from local servers and 'speed' is not equal to network stability. They're one way to test speed but dropped packets would still show a fast speed but the actual time to load a site would be much longer.

The first test is to find a site or address that is located in the US or Canada. Goverment sites usually block ICMP traffic so they won't work, use something like pacific bell. Once you have a site, open a command prompt by clicking 'start' and typing 'cmd' into the search field and hit enter. An old black dos window will appear. Type the following command...

ping 'sitename' -t

So I would type ping infohedge.net -t (Infohedge.net has ICMP blocked so this won't work for that site).

Once this is done, an endless ping will start. You may notice return packets based in miliseconds, or you may see connection timed out. A timeout is a very, very bad thing. That means you never got a response in time. If you have nothing but replies, you can assume that your connection is good.

If you are having problems, use CTRL-C to stop the ping test and use "Tracert 'sitename'" as you did with ping in the dos window.

tracert infohedge.net

Once you do this, you'll see various addresses appear on the right. These are 'hops' Your connection has to go through each of these to get to its destination when you're browsing the web or playing games. You can quickly see which hop is having connection timeout issues. Yesterday was exceptionally bad for True leaving Singapore and anything past it. I'm guessing the hardware there needs to be replaced....

This is an image of what 'unhealthy' ping looks like. This is what I was getting to a server in New York yesterday.

Edited September 26, 2014 by JeffreyO

[jpinx]

ping really can be screwed by problems at the recipient server. Traceroute is better

[jpinx]

here's a couple of traceroutes to googles dns server -- first from a server in Europe with massive connectivity

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 sejar0001-rd1.ip-only.net (62.109.46.129) 12.448 ms 12.918 ms 12.904 ms
2 sejar0001-rc4.ip-only.net (62.109.44.177) 0.644 ms 0.643 ms sejar0001-rc4.ip-only.net (62.109.44.173) 0.632 ms
3 sesto1024-rc1.ip-only.net (62.109.44.153) 0.619 ms 0.619 ms 0.609 ms
4 72.14.219.217 (72.14.219.217) 0.598 ms 0.592 ms 0.521 ms
5 216.239.43.122 (216.239.43.122) 0.747 ms 0.770 ms 0.789 ms
6 * 209.85.253.180 (209.85.253.180) 0.770 ms 209.85.254.31 (209.85.254.31) 1.070 ms
7 72.14.238.49 (72.14.238.49) 9.888 ms 209.85.247.89 (209.85.247.89) 9.776 ms 72.14.233.180 (72.14.233.180) 9.592 ms
8 72.14.233.170 (72.14.233.170) 9.627 ms 216.239.46.9 (216.239.46.9) 10.850 ms 216.239.46.17 (216.239.46.17) 9.625 ms
9 * * *
10 google-public-dns-a.google.com (8.8.8.8) 9.015 ms 9.779 ms 10.305 ms

--- and now from a mobile Dtac connection near Bangkok

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 192.168.43.1 (192.168.43.1) 14.912 ms 14.798 ms 14.697 ms
2 10.224.60.2 (10.224.60.2) 410.893 ms 451.803 ms 629.871 ms
3 10.224.60.5 (10.224.60.5) 647.789 ms 666.130 ms 10.224.60.1 (10.224.60.1) 689.697 ms
4 10.224.60.20 (10.224.60.20) 724.120 ms 749.502 ms 770.742 ms
5 10.224.56.57 (10.224.56.57) 785.589 ms 806.357 ms 826.176 ms
6 172.21.127.221 (172.21.127.221) 869.125 ms 160.681 ms 179.503 ms
7 172.30.188.21 (172.30.188.21) 197.983 ms 200.076 ms 242.046 ms
8 124.40.227.41 (124.40.227.41) 242.041 ms 262.166 ms 124.40.227.49 (124.40.227.49) 263.760 ms
9 124.40.227.5 (124.40.227.5) 263.783 ms 124.40.227.1 (124.40.227.1) 281.520 ms 281.463 ms
10 172.30.191.38 (172.30.191.38) 281.275 ms 172.30.191.22 (172.30.191.22) 281.253 ms 298.137 ms
11 72.14.210.190 (72.14.210.190) 321.122 ms 337.564 ms 193.903 ms
12 209.85.242.240 (209.85.242.240) 255.721 ms 209.85.242.246 (209.85.242.246) 255.800 ms 200.574 ms
13 209.85.242.232 (209.85.242.232) 417.701 ms 480.480 ms 209.85.242.242 (209.85.242.242) 560.473 ms
14 209.85.244.23 (209.85.244.23) 496.255 ms 479.965 ms 559.893 ms
15 * * *
16 google-public-dns-a.google.com (8.8.8.8) 584.886 ms 584.688 ms 640.386 ms

-------------

It's not just that the connection is slow - but look at *where* it is slow

[JeffreyO]

Tracert and ping serve two totally different purposes but yes, generally you would want to have two different pings open at the same time for comparison. One to a more localized server and one to the external server.

[wayned]

My TOT has been out a total of 17 days so far this month, but I don't have any choice where I live. One time I called the girl at TOT told me it was because of "waterfall"! For the past couple of days I've had no connectivity on two computers connected to the router, but WiFi with the laptop works with the same router. I've changed the cables, tried all of the router ports and even took one computer to the shop and it works fine.

I finally talked to the local TOT tech on Thursday and he agrees that it's the router and they were supposed to come today, no show. It's now Friday night and they don't work on the weekend so I guess that I start all over next week. They really are a joke!

[petedk]

here's a couple of traceroutes to googles dns server -- first from a server in Europe with massive connectivity

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets

1 sejar0001-rd1.ip-only.net (62.109.46.129) 12.448 ms 12.918 ms 12.904 ms

2 sejar0001-rc4.ip-only.net (62.109.44.177) 0.644 ms 0.643 ms sejar0001-rc4.ip-only.net (62.109.44.173) 0.632 ms

3 sesto1024-rc1.ip-only.net (62.109.44.153) 0.619 ms 0.619 ms 0.609 ms

4 72.14.219.217 (72.14.219.217) 0.598 ms 0.592 ms 0.521 ms

5 216.239.43.122 (216.239.43.122) 0.747 ms 0.770 ms 0.789 ms

6 * 209.85.253.180 (209.85.253.180) 0.770 ms 209.85.254.31 (209.85.254.31) 1.070 ms

7 72.14.238.49 (72.14.238.49) 9.888 ms 209.85.247.89 (209.85.247.89) 9.776 ms 72.14.233.180 (72.14.233.180) 9.592 ms

8 72.14.233.170 (72.14.233.170) 9.627 ms 216.239.46.9 (216.239.46.9) 10.850 ms 216.239.46.17 (216.239.46.17) 9.625 ms

9 * * *

10 google-public-dns-a.google.com (8.8.8.8) 9.015 ms 9.779 ms 10.305 ms

--- and now from a mobile Dtac connection near Bangkok

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets

1 192.168.43.1 (192.168.43.1) 14.912 ms 14.798 ms 14.697 ms

2 10.224.60.2 (10.224.60.2) 410.893 ms 451.803 ms 629.871 ms

3 10.224.60.5 (10.224.60.5) 647.789 ms 666.130 ms 10.224.60.1 (10.224.60.1) 689.697 ms

4 10.224.60.20 (10.224.60.20) 724.120 ms 749.502 ms 770.742 ms

5 10.224.56.57 (10.224.56.57) 785.589 ms 806.357 ms 826.176 ms

6 172.21.127.221 (172.21.127.221) 869.125 ms 160.681 ms 179.503 ms

7 172.30.188.21 (172.30.188.21) 197.983 ms 200.076 ms 242.046 ms

8 124.40.227.41 (124.40.227.41) 242.041 ms 262.166 ms 124.40.227.49 (124.40.227.49) 263.760 ms

9 124.40.227.5 (124.40.227.5) 263.783 ms 124.40.227.1 (124.40.227.1) 281.520 ms 281.463 ms

10 172.30.191.38 (172.30.191.38) 281.275 ms 172.30.191.22 (172.30.191.22) 281.253 ms 298.137 ms

11 72.14.210.190 (72.14.210.190) 321.122 ms 337.564 ms 193.903 ms

12 209.85.242.240 (209.85.242.240) 255.721 ms 209.85.242.246 (209.85.242.246) 255.800 ms 200.574 ms

13 209.85.242.232 (209.85.242.232) 417.701 ms 480.480 ms 209.85.242.242 (209.85.242.242) 560.473 ms

14 209.85.244.23 (209.85.244.23) 496.255 ms 479.965 ms 559.893 ms

15 * * *

16 google-public-dns-a.google.com (8.8.8.8) 584.886 ms 584.688 ms 640.386 ms

-------------

It's not just that the connection is slow - but look at *where* it is slow

Please explain where. I don't understand all of that.

[JeffreyO]

Basically, that's a tracert that I mentioned in my earlier post. Each "Number" is a 'hop'. Or each server that it touches to get to the server you want to use. So number 1, which shows a very low latency in milliseconds, is the router in his house, the next hop goes outside which you can see in ms also. It tests each 'hop' 3 times, which is why there are 3 sets of ms represented. In his second list hops 4, 5 and 6 are showing pretty significant latency (slowness).You wouldn't know this but I do, the addresses listed there are internal addresses and probably are within his ISP's network, not elsewhere.

[jpinx]

Basically, that's a tracert that I mentioned in my earlier post. Each "Number" is a 'hop'. Or each server that it touches to get to the server you want to use. So number 1, which shows a very low latency in milliseconds, is the router in his house, the next hop goes outside which you can see in ms also. It tests each 'hop' 3 times, which is why there are 3 sets of ms represented. In his second list hops 4, 5 and 6 are showing pretty significant latency (slowness).You wouldn't know this but I do, the addresses listed there are internal addresses and probably are within his ISP's network, not elsewhere.

Yep -- good old Dtac's mobile isp -- hops within Dtac are the slowest

It takes 10 hops to get out of Thailand and then it's in California and another 6 to get to Kansas

One thing about traceroute is that if you do it again, it'll likely give you a different answer - the routing will change

[shariq607]

here's a couple of traceroutes to googles dns server -- first from a server in Europe with massive connectivity

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets

1 sejar0001-rd1.ip-only.net (62.109.46.129) 12.448 ms 12.918 ms 12.904 ms

2 sejar0001-rc4.ip-only.net (62.109.44.177) 0.644 ms 0.643 ms sejar0001-rc4.ip-only.net (62.109.44.173) 0.632 ms

3 sesto1024-rc1.ip-only.net (62.109.44.153) 0.619 ms 0.619 ms 0.609 ms

4 72.14.219.217 (72.14.219.217) 0.598 ms 0.592 ms 0.521 ms

5 216.239.43.122 (216.239.43.122) 0.747 ms 0.770 ms 0.789 ms

6 * 209.85.253.180 (209.85.253.180) 0.770 ms 209.85.254.31 (209.85.254.31) 1.070 ms

7 72.14.238.49 (72.14.238.49) 9.888 ms 209.85.247.89 (209.85.247.89) 9.776 ms 72.14.233.180 (72.14.233.180) 9.592 ms

8 72.14.233.170 (72.14.233.170) 9.627 ms 216.239.46.9 (216.239.46.9) 10.850 ms 216.239.46.17 (216.239.46.17) 9.625 ms

9 * * *

10 google-public-dns-a.google.com (8.8.8.8) 9.015 ms 9.779 ms 10.305 ms

--- and now from a mobile Dtac connection near Bangkok

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets

1 192.168.43.1 (192.168.43.1) 14.912 ms 14.798 ms 14.697 ms

2 10.224.60.2 (10.224.60.2) 410.893 ms 451.803 ms 629.871 ms

3 10.224.60.5 (10.224.60.5) 647.789 ms 666.130 ms 10.224.60.1 (10.224.60.1) 689.697 ms

4 10.224.60.20 (10.224.60.20) 724.120 ms 749.502 ms 770.742 ms

5 10.224.56.57 (10.224.56.57) 785.589 ms 806.357 ms 826.176 ms

6 172.21.127.221 (172.21.127.221) 869.125 ms 160.681 ms 179.503 ms

7 172.30.188.21 (172.30.188.21) 197.983 ms 200.076 ms 242.046 ms

8 124.40.227.41 (124.40.227.41) 242.041 ms 262.166 ms 124.40.227.49 (124.40.227.49) 263.760 ms

9 124.40.227.5 (124.40.227.5) 263.783 ms 124.40.227.1 (124.40.227.1) 281.520 ms 281.463 ms

10 172.30.191.38 (172.30.191.38) 281.275 ms 172.30.191.22 (172.30.191.22) 281.253 ms 298.137 ms

11 72.14.210.190 (72.14.210.190) 321.122 ms 337.564 ms 193.903 ms

12 209.85.242.240 (209.85.242.240) 255.721 ms 209.85.242.246 (209.85.242.246) 255.800 ms 200.574 ms

13 209.85.242.232 (209.85.242.232) 417.701 ms 480.480 ms 209.85.242.242 (209.85.242.242) 560.473 ms

14 209.85.244.23 (209.85.244.23) 496.255 ms 479.965 ms 559.893 ms

15 * * *

16 google-public-dns-a.google.com (8.8.8.8) 584.886 ms 584.688 ms 640.386 ms

-------------

It's not just that the connection is slow - but look at *where* it is slow

This is what i am getting from my connection in central bkk,

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 38 byte packets

1 110.77.197.1 (110.77.197.1) 4.682 ms 4.071 ms 1.831 ms

2 110.77.254.137 (110.77.254.137) 17.541 ms 1.918 ms 2.273 ms

3 110.77.223.77 (110.77.223.77) 2.192 ms 2.084 ms 2.059 ms

4 122.155.226.29 (122.155.226.29) 6.140 ms 5.412 ms 122.155.226.37 (122.155.226.37) 3.912 ms

5 61.19.7.141 (61.19.7.141) 2.280 ms 2.193 ms 2.476 ms

6 61.19.7.130 (61.19.7.130) 3.976 ms 2.862 ms 3.976 ms

7 72.14.211.214 (72.14.211.214) 33.260 ms 93.711 ms 41.419 ms

8 66.249.95.124 (66.249.95.124) 31.820 ms 66.249.95.122 (66.249.95.122) 32.268 ms 66.249.95.124 (66.249.95.124) 32.778 ms

9 64.233.174.109 (64.233.174.109) 32.096 ms 32.147 ms 32.099 ms

10 * * *

11 google-public-dns-a.google.com (8.8.8.8) 32.416 ms 32.549 ms 32.441 ms

[jacko45k]

Well I hope that helps you OP

Answer is yes, International Internet traffic is being choked heading Eastwards due to a damaged undersea cable, it will affect TOT, as well as other ISPs.

There is another thread in this section where it is discussed, along with the comments of the usual conspiracy theory persons.

[JeffreyO]

This looks like normal ping to 8.8.8.8 (google open DNS). You can attempt to a more to a more localized server.

Try... in-n-out.com

tracert in-n-out.com

You should see significantly higher latency as you leave the local ocean.

Ping times of 32ms mean you didn't leave the region.

[jpinx]

here's a couple of traceroutes to googles dns server -- first from a server in Europe with massive connectivity

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets

1 sejar0001-rd1.ip-only.net (62.109.46.129) 12.448 ms 12.918 ms 12.904 ms

2 sejar0001-rc4.ip-only.net (62.109.44.177) 0.644 ms 0.643 ms sejar0001-rc4.ip-only.net (62.109.44.173) 0.632 ms

3 sesto1024-rc1.ip-only.net (62.109.44.153) 0.619 ms 0.619 ms 0.609 ms

4 72.14.219.217 (72.14.219.217) 0.598 ms 0.592 ms 0.521 ms

5 216.239.43.122 (216.239.43.122) 0.747 ms 0.770 ms 0.789 ms

6 * 209.85.253.180 (209.85.253.180) 0.770 ms 209.85.254.31 (209.85.254.31) 1.070 ms

7 72.14.238.49 (72.14.238.49) 9.888 ms 209.85.247.89 (209.85.247.89) 9.776 ms 72.14.233.180 (72.14.233.180) 9.592 ms

8 72.14.233.170 (72.14.233.170) 9.627 ms 216.239.46.9 (216.239.46.9) 10.850 ms 216.239.46.17 (216.239.46.17) 9.625 ms

9 * * *

10 google-public-dns-a.google.com (8.8.8.8) 9.015 ms 9.779 ms 10.305 ms

--- and now from a mobile Dtac connection near Bangkok

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets

1 192.168.43.1 (192.168.43.1) 14.912 ms 14.798 ms 14.697 ms

2 10.224.60.2 (10.224.60.2) 410.893 ms 451.803 ms 629.871 ms

3 10.224.60.5 (10.224.60.5) 647.789 ms 666.130 ms 10.224.60.1 (10.224.60.1) 689.697 ms

4 10.224.60.20 (10.224.60.20) 724.120 ms 749.502 ms 770.742 ms

5 10.224.56.57 (10.224.56.57) 785.589 ms 806.357 ms 826.176 ms

6 172.21.127.221 (172.21.127.221) 869.125 ms 160.681 ms 179.503 ms

7 172.30.188.21 (172.30.188.21) 197.983 ms 200.076 ms 242.046 ms

8 124.40.227.41 (124.40.227.41) 242.041 ms 262.166 ms 124.40.227.49 (124.40.227.49) 263.760 ms

9 124.40.227.5 (124.40.227.5) 263.783 ms 124.40.227.1 (124.40.227.1) 281.520 ms 281.463 ms

10 172.30.191.38 (172.30.191.38) 281.275 ms 172.30.191.22 (172.30.191.22) 281.253 ms 298.137 ms

11 72.14.210.190 (72.14.210.190) 321.122 ms 337.564 ms 193.903 ms

12 209.85.242.240 (209.85.242.240) 255.721 ms 209.85.242.246 (209.85.242.246) 255.800 ms 200.574 ms

13 209.85.242.232 (209.85.242.232) 417.701 ms 480.480 ms 209.85.242.242 (209.85.242.242) 560.473 ms

14 209.85.244.23 (209.85.244.23) 496.255 ms 479.965 ms 559.893 ms

15 * * *

16 google-public-dns-a.google.com (8.8.8.8) 584.886 ms 584.688 ms 640.386 ms

-------------

It's not just that the connection is slow - but look at *where* it is slow

This is what i am getting from my connection in central bkk,

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 38 byte packets

1 110.77.197.1 (110.77.197.1) 4.682 ms 4.071 ms 1.831 ms

2 110.77.254.137 (110.77.254.137) 17.541 ms 1.918 ms 2.273 ms

3 110.77.223.77 (110.77.223.77) 2.192 ms 2.084 ms 2.059 ms

4 122.155.226.29 (122.155.226.29) 6.140 ms 5.412 ms 122.155.226.37 (122.155.226.37) 3.912 ms

5 61.19.7.141 (61.19.7.141) 2.280 ms 2.193 ms 2.476 ms

6 61.19.7.130 (61.19.7.130) 3.976 ms 2.862 ms 3.976 ms

7 72.14.211.214 (72.14.211.214) 33.260 ms 93.711 ms 41.419 ms

8 66.249.95.124 (66.249.95.124) 31.820 ms 66.249.95.122 (66.249.95.122) 32.268 ms 66.249.95.124 (66.249.95.124) 32.778 ms

9 64.233.174.109 (64.233.174.109) 32.096 ms 32.147 ms 32.099 ms

10 * * *

11 google-public-dns-a.google.com (8.8.8.8) 32.416 ms 32.549 ms 32.441 ms

Same same but different You bounce around within your isp slightly less and then you end up at the international gateway 72.x.x.x

I'm not sure which of those IP's are the "filter"

Maybe things will improve when they fix that cable -- unless another one gets broken meantime

Here's todays....

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets

1 192.168.43.1 (192.168.43.1) 18.284 ms 18.162 ms 18.062 ms

2 10.224.60.2 (10.224.60.2) 293.629 ms 293.582 ms 338.291 ms

3 10.224.60.5 (10.224.60.5) 357.063 ms 356.684 ms 10.224.60.1 (10.224.60.1) 416.414 ms

4 10.224.60.20 (10.224.60.20) 416.367 ms 476.858 ms 486.596 ms

5 10.224.56.57 (10.224.56.57) 520.612 ms 537.493 ms 537.435 ms

6 172.21.127.221 (172.21.127.221) 537.364 ms 222.577 ms 327.071 ms

7 172.30.188.21 (172.30.188.21) 342.176 ms 121.217 ms 121.098 ms

8 124.40.227.49 (124.40.227.49) 181.439 ms 182.804 ms 199.542 ms

9 124.40.227.1 (124.40.227.1) 227.709 ms 227.588 ms 227.429 ms

10 172.30.191.22 (172.30.191.22) 245.880 ms 259.500 ms 172.30.191.38 (172.30.191.38) 361.134 ms

11 72.14.210.190 (72.14.210.190) 377.121 ms 378.211 ms 137.695 ms

12 209.85.242.240 (209.85.242.240) 215.798 ms 209.85.242.246 (209.85.242.246) 203.479 ms 161.861 ms

13 209.85.242.232 (209.85.242.232) 202.743 ms 221.186 ms 266.924 ms

14 64.233.174.109 (64.233.174.109) 268.087 ms 209.85.244.23 (209.85.244.23) 267.968 ms 64.233.174.109 (64.233.174.109) 280.609 ms

15 * * *

16 google-public-dns-a.google.com (8.8.8.8) 338.278 ms 337.888 ms 337.696 ms

And the summary of a screen of pings to the same IP..

--- 8.8.8.8 ping statistics ---

44 packets transmitted, 44 received, 0% packet loss, time 43063ms

rtt min/avg/max/mdev = 142.777/184.623/315.909/28.560 ms

Nice to see no packet loss

[jpinx]

This looks like normal ping to 8.8.8.8 (google open DNS). You can attempt to a more to a more localized server.

Try... in-n-out.com

tracert in-n-out.com

You should see significantly higher latency as you leave the local ocean.

Ping times of 32ms mean you didn't leave the region.

That was a bit painful

here ya go.....

traceroute to in-n-out.com (199.83.131.71), 30 hops max, 60 byte packets

1 192.168.43.1 (192.168.43.1) 17.437 ms 17.364 ms 17.322 ms

2 10.224.60.2 (10.224.60.2) 830.182 ms 835.043 ms 837.246 ms

3 10.224.60.1 (10.224.60.1) 831.340 ms 10.224.60.5 (10.224.60.5) 833.032 ms 10.224.60.1 (10.224.60.1) 833.024 ms

4 10.224.60.20 (10.224.60.20) 837.048 ms 837.013 ms 836.975 ms

5 10.224.56.57 (10.224.56.57) 834.571 ms 834.538 ms 834.505 ms

6 172.21.127.221 (172.21.127.221) 834.471 ms 455.571 ms 455.338 ms

7 172.30.188.21 (172.30.188.21) 455.213 ms 149.505 ms 175.026 ms

8 124.40.227.41 (124.40.227.41) 205.442 ms 225.231 ms 124.40.227.49 (124.40.227.49) 251.852 ms

9 124.40.227.5 (124.40.227.5) 265.508 ms 124.40.227.1 (124.40.227.1) 287.524 ms 124.40.227.5 (124.40.227.5) 307.853 ms

10 172.30.191.30 (172.30.191.30) 324.567 ms 172.30.191.46 (172.30.191.46) 468.174 ms 468.850 ms

11 snge-b1-link.telia.net (62.115.35.165) 508.537 ms 508.513 ms 396.223 ms

12 hnk-b2-link.telia.net (213.155.136.118) 396.056 ms hnk-b2-link.telia.net (80.91.245.151) 376.305 ms 400.745 ms

13 las-b21-link.telia.net (62.115.138.118) 444.802 ms 444.702 ms las-b21-link.telia.net (213.155.136.44) 503.255 ms

14 las-b3-link.telia.net (213.155.134.77) 520.611 ms las-b3-link.telia.net (213.155.130.127) 479.150 ms las-b3-link.telia.net (213.155.131.83) 502.690 ms

15 * * *

16 * * *

17 * * *

18 * * *

19 * * *

20 * * *

21 * * *

22 * * *

23 * * *

24 * * *

25 * * *

26 * * *

27 * * *

28 * * *

29 * * *

30 * * *

The last IP showing is in switzerland

--- in-n-out.com ping statistics ---

68 packets transmitted, 68 received, 0% packet loss, time 67065ms

rtt min/avg/max/mdev = 320.391/374.460/494.204/41.692 ms

BTW -- I'm not sure where you get the idea about 32ms meaning something other than 32 milliseconds

[JeffreyO]

It's probably showing switzerland as an attempt to bypass 'slow' connectivity across the Pacific right now. Your ISP may be routing out of vietnam instead of singapore, hard to be certain but yeah. Now you can see that it's not your 'speed' that's a problem, it's your routing. So a speedtest won't accurately show you your issues but here in the tracert (short for trace route) you're seeing where the connectivity problem is. There's probably not much your ISP can do at this moment short of rebuilding their routing tables and... good effin' luck getting them to do that =D.