New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Get a globe and look where Singapore is and where is Chicago. Any route will be long.
What "issue" or "latency" you want them to solve if it's literally on the other side of Earth.
Hello @dgprasetya, maybe easier to look at a dedi or VM in our Canadian datacenter if this client of yours is in NorthAmerica. (OVH has 28 datacenters accross the globe).
Hello all,
Just to inform you that we have connected a new provider to the OVH network in Australia (2x10G). This new provider is Vocus. This provider is going to help for the routing to Vocus network but also to Dodo and also to iPrimus Telecommunications.
Feel free to send us your traceroute on http://traceroute.apac-tools.ovh in order to improve routing on the OVH network.
Hello,
Networks from APAC Viet Nam - Viettel AS7552 very slow and problems. Please check again help me.
Hello @trongtri
Could you please send us a traceroute here for further investigation: http://traceroute.apac-tools.ovh
thank you!
Hello all,
Good news for all our vietnamese users, we have recently improved the latency from our Singapore datacenter with VNPT, now down to 89ms.
Are you experiencing a long or unusual latency with your OVH service based in Singapore or in Australia, let us know your traceroute details here for further investigations by our netowrk team: http://traceroute.apac-tools.ovh
@OVH_APAC Please have a look at this. I'd say 100ms is reasonable, but 180 isn't
https://atlas.ripe.net/measurements/21971995/#!probes
This isn't publicly accessible.
I can access it with chrome's incognito on, and I though unless I explicitly set it to private via the API, all informaition on Atlas is public?
Edit:
PUBLIC
Indicates this measurement is publicly available; may be changed from false to true, but not from true to false
Oh nevermind, it worked in another browser. As for the actual issue, I think they will ask you which of the ASes or source IPs you have the most high-priority issue with, it's not useful to show a broad list of ASes and ask "improve all these".
That makes sense. I'm on mobile right now so maybe when I get to a desktop
Hello @sanvit, our network team have done a few improvements already with few providers (-:
I let you check and I suggest you to send directly your traceroute details here if you need further assistance: http://traceroute.apac-tools.ovh
Thanks
Hello all,
Thanks to all LET user precious feedbacks, we are continually improving our APAC Network (-:
We have just reduced the latency between MY REDtone in Malaysia and the OVH Singapore datacenter from 180ms, now down to 7ms!
Are you experiencing a long or unusual latency with your OVH service based in Singapore or in Australia?
Let us know your traceroute details here for further investigations by our network team: http://traceroute.apac-tools.ovh
Not just long latency , i am even seeing timeout here.I sent the traceroute
@OVH_APAC Hello, your latency optimization is amazing, but somehow these days Singapore OVH have a weird packet lost bursts of between 5 - 20 minutes.
More info is available on this thread : https://www.lowendtalk.com/discussion/159098/bad-ovh-sg-network#latest
Hello @leang97
Sorry for the late answer and we apologize for any inconvenience caused. I believe the issue is now solved, please confirm otherwise.
With such cases, best is to check http://status.ovh.com/ and open a ticket with our support team.
Hello,
Sharing the latest improvement done from the OVH Singapore datacenter to LA Unitel LAOS : latency average is now 68ms.
http://sgp.smokeping.ovh.net/smokeping?target=APAC.AS131267
Are you experiencing a long or unusual latency with your OVH service based in Singapore or in Australia?
Let us know your traceroute details here for further investigations by our network team: http://traceroute.apac-tools.ovh
@OVH_APAC
Hey the entire week-end has been a shitfest in regards of routing, have a look:
tcptraceroute 171.100.253.XXX
Selected device ens3, address 139.99.46.XXX, port 42479 for outgoing packets
Tracing the path to 171.100.253.222 on TCP port 80 (http), 30 hops max
1 139.99.40.1 0.336 ms 0.231 ms 0.230 ms
2 192.168.143.254 0.282 ms 0.410 ms 0.361 ms
3 10.29.193.254 0.385 ms 0.420 ms 0.447 ms
4 10.29.192.16 0.556 ms 0.473 ms 0.464 ms
5 10.133.2.28 0.709 ms 0.680 ms 0.773 ms
6 10.75.0.10 0.574 ms 0.379 ms 0.552 ms
7 10.75.248.4 1.100 ms 1.074 ms 1.149 ms
8 sin1-sgcs2-g1-nc5.sng.asia (103.5.15.224) 1.120 ms 1.012 ms 0.756 ms
9 sin-sg1-bb1-a9.sng.asia (103.5.15.4) 7.666 ms 1.418 ms 1.360 ms
10 218.100.7.51 91.601 ms 94.570 ms 91.792 ms
11 61.19.7.14 93.874 ms 92.364 ms 93.852 ms
12 122.155.226.98 92.697 ms 93.154 ms 92.666 ms
13 103-3-177-169.static.asianet.co.th (103.3.177.169) 93.326 ms 93.441 ms 93.409 ms
14 203-144-161-8.static.asianet.co.th (203.144.161.8) 94.711 ms 95.108 ms 94.778 ms
15 171-102-254-67.static.asianet.co.th (171.102.254.67) 94.392 ms 94.711 ms 94.469 ms
16 58-97-82-83.static.asianet.co.th (58.97.82.83) 94.142 ms 94.245 ms 94.335 ms
17 * * *
18 *^C
Hop 10:
whois 218.100.7.51 | grep country
country: JP
country: JP
country: JP
I am no expert but it seems there are some shenanigans 90ms to reach Thailand instead of the usual 29ms, unacceptable.
Also there's no reason for you to try to reach AS7470 (TRUE) through AS4651's (CAT) oversaturated IIG when you could reach AS7470 directly at SGIX as you supposedly peer with them.
Fix ASAP.
Hello @BKKHK ,
I will get our Network team to have a look for you as soon as possible, but I'm pretty sure a "Please" will help them to work faster...
Cheers
I’m sorry if I hurt your e-feelings but you shouldn’t expect a “please” when I’m paying for such service. If it was a “best effort service” or better yet a totally “free service” provided by a charity ran organization then you could/would have expected a “please”.
However, once this shitfest gets resolved you can fairly expect a “thank you”.
In the meantime you can have another first extra “thank you” for acknowledging and escalating the issue(s) to your network team.
So have it, Thank you.
Someone seems to have forgotten the Internet is a best-effort delivery mechanism...
I guess I’ll make my next payments and my upcoming subscriptions as “best effort” too then.
I think you need to take your Networking 101 class.
You'll try out a different provider in Singapore then complain when they don't have DDoS protection, cost 100-200% more, use older hardware, and don't reply to you on a public forum. Work with OVH to solve the routing problem then be happy.
Just some deliver this best effort better than others. @BKKHK is clearly used to a different kind of service. No need to jump on him or her.
In @OVH_APAC ‘s defense I would like to state the service is actually fine 90% of the times which suits me perfectly fine and works out of the box.
I just find it ironic that they’re requesting a “please” simply because THEY are failing to do their job properly which is to run a network the most optimized way.
As I said again, they are peering with TRUE at the SGIX why would they want to route the traffic through CAT’s broken IIG to begin with?
If I was OVH I’d depeer CAT immediately to make sure traffic never gets routed through their shitty IIG ever again.
But then again that’s just me and I’m no expert on the subject.
I guess it's a good thing I picked up an Ovh SGP vps via @hostdoc for wireguard use.
My ISP is now randomly routing me halfway around the globe to my leaseweb SGP, at certain hours.
Always have a Plan B.
Great 55ms route for me from Asianet Kerala @OVH_APAC.
Your efforts are much appreciated.
@OVH_APAC
As of 9:40PM tonight, 3 different routes:
tcptraceroute 124.122.35.XXX
Selected device ens3, address 139.99.46.XXX, port 45289 for outgoing packets
Tracing the path to 124.122.35.XXX on TCP port 80 (http), 30 hops max
1 139.99.40.1 0.390 ms 0.215 ms 0.327 ms
2 192.168.143.254 0.355 ms 0.261 ms 1.627 ms
3 10.29.193.254 0.691 ms 0.389 ms 0.678 ms
4 10.29.192.16 0.556 ms 0.583 ms 0.608 ms
5 10.133.2.28 0.829 ms 0.870 ms 0.783 ms
6 10.75.0.8 0.606 ms 0.469 ms 0.501 ms
7 10.75.248.2 1.173 ms 0.861 ms 1.277 ms
8 sin-sg1-bb1-a9.sng.asia (103.5.15.4) 22.674 ms 1.442 ms 1.827 ms
9 103.231.152.17 1.584 ms 1.737 ms 1.329 ms
10 TIG-Net25-211.trueintergateway.com (122.144.25.211) 27.579 ms 27.335 ms 27.189 ms
11 171-102-250-157.static.asianet.co.th (171.102.250.157) 27.631 ms 27.543 ms 27.571 ms
12 171-102-250-152.static.asianet.co.th (171.102.250.152) 28.843 ms 28.766 ms 28.721 ms
13 171-102-250-18.static.asianet.co.th (171.102.250.18) 28.932 ms 29.022 ms 28.645 ms
14 * *^C
28ms? good.
Through SGIX:
tcptraceroute 124.122.35.XXX
Selected device ens3, address 139.99.46.XXX, port 33281 for outgoing packets
Tracing the path to 124.122.35.XXX on TCP port 80 (http), 30 hops max
1 139.99.40.1 0.282 ms 0.216 ms 0.250 ms
2 192.168.143.254 0.452 ms 0.207 ms 0.503 ms
3 10.29.193.254 0.548 ms 0.579 ms 0.442 ms
4 10.29.192.16 0.462 ms 0.950 ms 0.583 ms
5 10.133.2.28 0.769 ms 0.697 ms 0.748 ms
6 10.75.0.10 0.573 ms 0.363 ms 0.364 ms
7 10.75.248.4 1.099 ms 0.983 ms 1.082 ms
8 sin-gss1-bb1-a9.sng.asia (103.5.15.16) 1.321 ms 1.376 ms 1.087 ms
9 true.sgix.sg (103.16.102.46) 4.974 ms 1.731 ms 1.415 ms
10 * * *
11 TIG-Net241-192.trueintergateway.com (113.21.241.192) 30.602 ms 31.038 ms 32.705 ms
12 TIG-Net25-210.trueintergateway.com (122.144.25.210) 29.493 ms 29.229 ms 29.234 ms
13 TIG-Net25-211.trueintergateway.com (122.144.25.211) 29.198 ms 29.259 ms 29.169 ms
14 171-102-250-157.static.asianet.co.th (171.102.250.157) 29.983 ms 29.352 ms 29.546 ms
15 171-102-250-150.static.asianet.co.th (171.102.250.150) 30.608 ms 30.522 ms 30.553 ms
16 171-102-250-2.static.asianet.co.th (171.102.250.2) 30.740 ms 30.712 ms 30.949 ms
17 171-102-247-231.static.asianet.co.th (171.102.247.231) 30.069 ms 31.291 ms 33.410 ms
18 *^C
30ms~33ms? Pretty good.
Through Equinix SG:
tcptraceroute 124.122.35.XXX
Selected device ens3, address 139.99.46.XXX, port 47449 for outgoing packets
Tracing the path to 124.122.35.XXX on TCP port 80 (http), 30 hops max
1 139.99.40.1 0.270 ms 0.191 ms 0.226 ms
2 192.168.143.254 0.403 ms 0.221 ms 0.323 ms
3 10.29.193.254 0.430 ms 0.547 ms 0.404 ms
4 10.29.192.14 0.441 ms 0.347 ms 0.408 ms
5 10.133.2.24 0.637 ms 0.716 ms 0.668 ms
6 10.75.0.8 0.408 ms 0.368 ms 0.614 ms
7 10.75.248.2 0.943 ms 1.199 ms 0.917 ms
8 sin-sg1-bb1-a9.sng.asia (103.5.15.4) 1.244 ms 1.550 ms 1.242 ms
9 38082.sgw.equinix.com (27.111.228.76) 1.443 ms 1.209 ms 1.415 ms
10 TIG-Net25-204.trueintergateway.com (122.144.25.204) 29.121 ms 29.221 ms 29.252 ms
11 TIG-Net25-205.trueintergateway.com (122.144.25.205) 29.114 ms 29.096 ms 28.977 ms
12 171-102-250-157.static.asianet.co.th (171.102.250.157) 29.224 ms 29.142 ms 29.172 ms
13 171-102-250-152.static.asianet.co.th (171.102.250.152) 30.384 ms 30.433 ms 30.682 ms
14 171-102-250-18.static.asianet.co.th (171.102.250.18) 30.962 ms 30.568 ms 30.756 ms
15 171-102-247-181.static.asianet.co.th (171.102.247.181) 41.152 ms 34.438 ms 30.271 ms
16 * *^C
30ms? Very good.
The other way around now from home to OVH:
Tracing route to xxx.ip-139-99-46.eu [139.99.46.XXX]
over a maximum of 30 hops:
1 1 ms 1 ms 1 ms 192.168.2.1
2 2 ms 2 ms 2 ms 192.168.1.1
3 6 ms 6 ms 6 ms 10.169.163.174
4 6 ms 5 ms 6 ms 10.169.163.9
5 5 ms 5 ms 5 ms 10.185.163.234
6 6 ms 6 ms 6 ms 10.185.163.53
7 8 ms 10 ms 7 ms 171-102-247-201.static.asianet.co.th [171.102.247.201]
8 8 ms 8 ms 7 ms 171-102-247-80.static.asianet.co.th [171.102.247.80]
9 7 ms 7 ms 7 ms 171-102-250-1.static.asianet.co.th [171.102.250.1]
10 7 ms 7 ms 9 ms 171-102-254-232.static.asianet.co.th [171.102.254.232]
11 7 ms 7 ms 7 ms 171-102-250-158.static.asianet.co.th [171.102.250.158]
12 8 ms 9 ms 7 ms tig-net25-208.trueintergateway.com [122.144.25.208]
13 39 ms 35 ms 36 ms tig-net241-189.trueintergateway.com [113.21.241.189]
14 * * * Request timed out.
15 36 ms 36 ms 35 ms sin1-sgcs2-g1-nc5.sng.asia [103.5.15.5]
16 * * * Request timed out.
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.
21 * * * Request timed out.
22 34 ms 33 ms 33 ms XXX.ip-139-99-46.eu [139.99.46.XXX]
The traceroute looks a bit wonky wonky but 33ms is all good.
What I'm trying to say here, is THANK YOU.
Tell your network engineering team to avoid routing other Thai ISP/NSP through CAT as much as possible whenever possible, their network is a giant dictatorship lagging sniffing honeypot due to political instability in the region.
Thank you again @OVH_APAC.
Why wouldn't they use it if its cheaper? Don't forget that nobody can match OVH in asia as a provider when it comes to server + bandwidth prices.
Imagine how much a simple incoming DDoS costs them if mitigated fully locally (which is what they do for asia origin traffic)? And you expect them to use the most expensive pipes for ur pennies lol. If its under 100ms and has a working unlimited anti-ddos for cheap, its a god tier service in current Asia.
If you care so much about latency be expected to pay premium for the traffic such as what softlayer provides.
Completely irrelevant post besides, why would it make a difference when it's peering A vs. peering B anyways, costs them the same amirite?