Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


OVH Asia-Pacific Network, latest latency optimizations - Page 10
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.

OVH Asia-Pacific Network, latest latency optimizations

16781012

Comments

  • OVH_APACOVH_APAC Member, Patron Provider

    Hello @BKKHK ,
    I'm glad your problem got resolved, but I confirm our network team did not do anything here..
    As you would have already understood, it's not only on OVH side and you have provided a great example. For a connection point to point you will have 2 or more providers involved. As a result, I would suggest you to contact your internet provider to understand what happened, could have been a maintenance at their side.

    Thanked by 1FHR
  • MikePTMikePT Moderator, Patron Provider, Veteran

    @BKKHK said:

    @stefeman said:
    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?

    It doesnt.

  • Wow, several location in Viet Nam ?

  • @OVH_APAC said:
    Hello @BKKHK ,
    I'm glad your problem got resolved, but I confirm our network team did not do anything here..
    As you would have already understood, it's not only on OVH side and you have provided a great example. For a connection point to point you will have 2 or more providers involved. As a result, I would suggest you to contact your internet provider to understand what happened, could have been a maintenance at their side.

    A maintenance for an entire week-end?

  • OVH_APACOVH_APAC Member, Patron Provider

    @BKKHK said:

    @OVH_APAC said:
    Hello @BKKHK ,
    I'm glad your problem got resolved, but I confirm our network team did not do anything here..
    As you would have already understood, it's not only on OVH side and you have provided a great example. For a connection point to point you will have 2 or more providers involved. As a result, I would suggest you to contact your internet provider to understand what happened, could have been a maintenance at their side.

    A maintenance for an entire week-end?

    I cannot answer you but feel free to share the reason here once you have contacted your internet provider. Thank you.

  • any on sale server currently?

  • OVH_APACOVH_APAC Member, Patron Provider

    @Millenniunns said:
    any on sale server currently?

    Hello @Millenniunns, this is a very broad request and not the right thread. I invite you to contact me by PM with more details such as location you are interested in and the type of server you are after: vps, public cloud server, baremetal server.
    Thank you

  • @BKKHK said:

    @stefeman said:
    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?

    That’s not the problem. It is incredibly difficult to optimize routing for everyone.

    In essence, while it may cost the same to route a user over two different paths, it’s perfectly possible that it is out of OVH’s control.

  • roshan91roshan91 Member
    edited August 2019

    2018 July

    @roshan91 said:
    From Sri Lanka

    Pinging sgp.smokeping.ovh.net [139.99.127.250] with 32 bytes of data:
    Reply from 139.99.127.250: bytes=32 time=66ms TTL=50
    Reply from 139.99.127.250: bytes=32 time=65ms TTL=50
    Reply from 139.99.127.250: bytes=32 time=65ms TTL=50
    Reply from 139.99.127.250: bytes=32 time=65ms TTL=50
    
    Ping statistics for 139.99.127.250:
        Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
        Minimum = 65ms, Maximum = 66ms, Average = 65ms
    

    Today

    Pinging sin.smokeping.ovh.net [139.99.72.90] with 32 bytes of data:
    Reply from 139.99.72.90: bytes=32 time=43ms TTL=48
    Reply from 139.99.72.90: bytes=32 time=40ms TTL=48
    Reply from 139.99.72.90: bytes=32 time=43ms TTL=48
    Reply from 139.99.72.90: bytes=32 time=40ms TTL=48
    
    Ping statistics for 139.99.72.90:
        Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
        Minimum = 40ms, Maximum = 43ms, Average = 41ms
    
    Tracing route to sin.smokeping.ovh.net [139.99.72.90]
    over a maximum of 30 hops:
    
      1    <1 ms    <1 ms    <1 ms  192.168.1.1
      2     5 ms     5 ms     4 ms  220.247.232.97
      3     7 ms     7 ms     5 ms  198.51.100.2
      4     9 ms     7 ms     7 ms  198.51.100.1
      5     7 ms     5 ms     7 ms  222.165.175.252
      6     7 ms     8 ms     7 ms  222.165.175.249
      7    13 ms     7 ms     8 ms  103.87.125.17
      8    48 ms    47 ms    46 ms  103.87.124.66
      9     *        *        *     Request timed out.
     10    41 ms    41 ms    40 ms  sin1-sgcs2-g1-nc5.sng.asia [103.5.15.5]
     11     *        *        *     Request timed out.
     12     *        *        *     Request timed out.
     13     *        *        *     Request timed out.
     14     *        *        *     Request timed out.
     15     *        *        *     Request timed out.
     16     *        *        *     Request timed out.
     17    43 ms    40 ms    40 ms  sgp.smokeping.ovh.net [139.99.72.90]
    
    Trace complete.
    
  • Is the CAT IIG a problem nowadays? I often run into "IT experts" in Thailand that haven't got a fucking clue, I've heard the theory of fake speed tests and all that shit, but quite often they back this up with traceroutes and fucking pings and 'see dropped packets at this hop, see high latency' without understanding the common de-prioritization of ICMP and so on..

  • OVH_APACOVH_APAC Member, Patron Provider

    Hello,
    Sharing the latest improvement done from the OVH Singapore datacenter to FPT telecom Vietnam: latency average is now down to 44ms!
    http://sgp.smokeping.ovh.net/smokeping?target=APAC.AS18403

    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_APACOVH_APAC Member, Patron Provider

    Hello,
    We have activated a new transit provider NTT (AS2914), improving the routing in/to Australia while increasing our global network capacity out of Sydney Datacenter.

    Latency tool: http://syd.smokeping.ovh.net/smokeping?filter=AU+
    Weathermap: http://weathermap.ovh.net/#apac

    Feel free to contact us if you have any issue by sending us a traceroute: http://traceroute.apac-tools.ovh

    Thanked by 2DP bdl
  • From home router (Indonesia Myrepublic)

    ping

    trecroute

  • I see you have NTT & TATA, the 2 largest Tier 1 ISPs in Asia-Pac. Any chance of adding PCCW? They are also Tier 1.

  • OVH_APACOVH_APAC Member, Patron Provider

    @isunbejo , thanks for sharing, great latency from Indonesia with only 15ms! (-:
    @nature1 , thanks for the suggestion, I will pass on to our network team for consideration.

  • OVH has a high bandwidth in Los Angeles. Why not use it?

    test tools

    https://tools.ipip.net/traceroute.php

  • @OVH_APAC

    Got a client from Asia he's getting routed through Canada:

    Tracing route to ip195.ip-139-99-22.net [139.99.22.195]
    over a maximum of 30 hops:

    1 1 ms <1 ms <1 ms router.asus.com [120.29.117.143]
    2 * * * Request timed out.
    3 * * * Request timed out.
    4 3 ms 2 ms 2 ms 172.20.21.105 [172.20.21.105]
    5 3 ms 3 ms 2 ms 202.69.174.101
    6 2 ms 1 ms 2 ms 172.20.11.4 [172.20.11.4]
    7 3 ms 3 ms 3 ms 202.69.174.61
    8 4 ms 3 ms 3 ms 154.1.49.161-rev.convergeict.com [161.49.1.154]
    9 3 ms 9 ms 10 ms 194.1.49.161-rev.convergeict.com [161.49.1.194]
    10 * * * Request timed out.
    11 211 ms 211 ms 212 ms be100-1007.ash-5-a9.va.us [198.27.73.219]
    12 211 ms 212 ms 212 ms be100-1367.lax-la1-bb1-a9.ca.us [178.32.135.160]
    13 221 ms * 221 ms be100-1365.sjo-sv5-bb1-a9.ca.us [198.27.73.105]
    14 270 ms 235 ms 235 ms 103.5.15.28
    15 233 ms 233 ms 232 ms 103.5.15.17
    16 * * * Request timed out.
    17 * * * Request timed out.
    18 * * * Request timed out.
    19 235 ms 235 ms 235 ms ip195.ip-139-99-22.net [139.99.22.195]

  • @OVH_APAC Same here, with a client from Philippines.

    Tracing route to ns537726.ip-139-xx-xx.net [139.xx.xx.xxx]
    over a maximum of 30 hops:

    1 <1 ms <1 ms <1 ms DESKTOP-9VRK8K4 [192.168.1.1]
    2 17 ms 17 ms 22 ms 100.72.0.1
    3 18 ms 17 ms 17 ms 122.2.174.222.static.pldt.net [122.2.174.222]
    4 31 ms 31 ms 31 ms 210.213.130.186.static.pldt.net [210.213.130.186]
    5 67 ms 30 ms 31 ms 210.213.130.162.static.pldt.net [210.213.130.162]
    6 167 ms 167 ms 167 ms six.sea.wa.us.ovh.net [206.81.80.214]
    7 180 ms 180 ms 180 ms be102.pdx-prt1-sbb1-nc5.oregon.us [142.44.208.9]
    8 * * * Request timed out.
    9 180 ms 180 ms 181 ms be102.pdx-prt1-sbb1-nc5.oregon.us [142.44.208.9]
    10 180 ms 180 ms 181 ms pao-sv8-bb1-a9.ca.us [142.44.208.8]
    11 180 ms 180 ms 180 ms be100-1368.sjo-sv5-bb1-a9.ca.us [178.32.135.159]
    12 199 ms 199 ms 199 ms 103.5.15.28
    13 205 ms 206 ms 206 ms 103.5.15.17
    14 * * * Request timed out.
    15 * * * Request timed out.
    16 * * * Request timed out.
    17 205 ms 206 ms 205 ms ns537726.ip-139-xx-xx.net [139.xx.xx.xxx]

  • DPDP Administrator, The Domain Guy

    Now that's one hell of a scenic route, from Philippines going sightseeing in the States on the way to Singapore :joy:

  • OVH SG to LA

    ping 168 ms

  • @darthShadow said:
    @OVH_APAC Same here, with a client from Philippines.

    Tracing route to ns537726.ip-139-xx-xx.net [139.xx.xx.xxx]
    over a maximum of 30 hops:

    1 <1 ms <1 ms <1 ms DESKTOP-9VRK8K4 [192.168.1.1]
    2 17 ms 17 ms 22 ms 100.72.0.1
    3 18 ms 17 ms 17 ms 122.2.174.222.static.pldt.net [122.2.174.222]
    4 31 ms 31 ms 31 ms 210.213.130.186.static.pldt.net [210.213.130.186]
    5 67 ms 30 ms 31 ms 210.213.130.162.static.pldt.net [210.213.130.162]
    6 167 ms 167 ms 167 ms six.sea.wa.us.ovh.net [206.81.80.214]
    7 180 ms 180 ms 180 ms be102.pdx-prt1-sbb1-nc5.oregon.us [142.44.208.9]
    8 * * * Request timed out.
    9 180 ms 180 ms 181 ms be102.pdx-prt1-sbb1-nc5.oregon.us [142.44.208.9]
    10 180 ms 180 ms 181 ms pao-sv8-bb1-a9.ca.us [142.44.208.8]
    11 180 ms 180 ms 180 ms be100-1368.sjo-sv5-bb1-a9.ca.us [178.32.135.159]
    12 199 ms 199 ms 199 ms 103.5.15.28
    13 205 ms 206 ms 206 ms 103.5.15.17
    14 * * * Request timed out.
    15 * * * Request timed out.
    16 * * * Request timed out.
    17 205 ms 206 ms 205 ms ns537726.ip-139-xx-xx.net [139.xx.xx.xxx]

    @OVH_APAC , this is the same complain that we have from our clients in the Philippines. It is like roaming around USA and Canada before going to Asia.

  • DPDP Administrator, The Domain Guy

    Not everything will be on OVH's plate.

    In most cases, it's on the end users ISPs and their upstreams.

  • OVH_APACOVH_APAC Member, Patron Provider

    Hello > @marvel said:

    @OVH_APAC

    Got a client from Asia he's getting routed through Canada:

    Tracing route to ip195.ip-139-99-22.net [139.99.22.195]
    over a maximum of 30 hops:

    1 1 ms <1 ms <1 ms router.asus.com [120.29.117.143]
    2 * * * Request timed out.
    3 * * * Request timed out.
    4 3 ms 2 ms 2 ms 172.20.21.105 [172.20.21.105]
    5 3 ms 3 ms 2 ms 202.69.174.101
    6 2 ms 1 ms 2 ms 172.20.11.4 [172.20.11.4]
    7 3 ms 3 ms 3 ms 202.69.174.61
    8 4 ms 3 ms 3 ms 154.1.49.161-rev.convergeict.com [161.49.1.154]
    9 3 ms 9 ms 10 ms 194.1.49.161-rev.convergeict.com [161.49.1.194]
    10 * * * Request timed out.
    11 211 ms 211 ms 212 ms be100-1007.ash-5-a9.va.us [198.27.73.219]
    12 211 ms 212 ms 212 ms be100-1367.lax-la1-bb1-a9.ca.us [178.32.135.160]
    13 221 ms * 221 ms be100-1365.sjo-sv5-bb1-a9.ca.us [198.27.73.105]
    14 270 ms 235 ms 235 ms 103.5.15.28
    15 233 ms 233 ms 232 ms 103.5.15.17
    16 * * * Request timed out.
    17 * * * Request timed out.
    18 * * * Request timed out.
    19 235 ms 235 ms 235 ms ip195.ip-139-99-22.net [139.99.22.195]

    Hello @marvel
    we have fixed it. sorry for the issue:

    Thanked by 2marvel eva2000
  • OVH_APACOVH_APAC Member, Patron Provider

    @jonesolutions said:

    @darthShadow said:
    @OVH_APAC Same here, with a client from Philippines.

    Tracing route to ns537726.ip-139-xx-xx.net [139.xx.xx.xxx]
    over a maximum of 30 hops:

    1 <1 ms <1 ms <1 ms DESKTOP-9VRK8K4 [192.168.1.1]
    2 17 ms 17 ms 22 ms 100.72.0.1
    3 18 ms 17 ms 17 ms 122.2.174.222.static.pldt.net [122.2.174.222]
    4 31 ms 31 ms 31 ms 210.213.130.186.static.pldt.net [210.213.130.186]
    5 67 ms 30 ms 31 ms 210.213.130.162.static.pldt.net [210.213.130.162]
    6 167 ms 167 ms 167 ms six.sea.wa.us.ovh.net [206.81.80.214]
    7 180 ms 180 ms 180 ms be102.pdx-prt1-sbb1-nc5.oregon.us [142.44.208.9]
    8 * * * Request timed out.
    9 180 ms 180 ms 181 ms be102.pdx-prt1-sbb1-nc5.oregon.us [142.44.208.9]
    10 180 ms 180 ms 181 ms pao-sv8-bb1-a9.ca.us [142.44.208.8]
    11 180 ms 180 ms 180 ms be100-1368.sjo-sv5-bb1-a9.ca.us [178.32.135.159]
    12 199 ms 199 ms 199 ms 103.5.15.28
    13 205 ms 206 ms 206 ms 103.5.15.17
    14 * * * Request timed out.
    15 * * * Request timed out.
    16 * * * Request timed out.
    17 205 ms 206 ms 205 ms ns537726.ip-139-xx-xx.net [139.xx.xx.xxx]

    @OVH_APAC , this is the same complain that we have from our clients in the Philippines. It is like roaming around USA and Canada before going to Asia.

    Hello @jonesolutions ,
    we have fixed as well, sorry for the inconvenience.
    http://sgp.smokeping.ovh.net/smokeping?target=APAC.AS9299
    http://sgp.smokeping.ovh.net/smokeping?target=APAC.AS9299-3

    Thanked by 1eva2000
  • OVH_APACOVH_APAC Member, Patron Provider

    To the LET community:
    If you experience latency in the APAC region on the OVH network and you have ruled out your ISP please send us a traceroute directly here: https://www.apac-tools.ovh/traceroute/
    Many thanks! It will land directly in the capable hands of the local OVH network team (-:

    Thanked by 1eva2000
  • Confirmed. From 205ms to 80ms. Thank you for fixing it.

  • marvelmarvel Member

    @OVH_APAC said:
    Hello > @marvel said:

    @OVH_APAC

    Got a client from Asia he's getting routed through Canada:

    Tracing route to ip195.ip-139-99-22.net [139.99.22.195]
    over a maximum of 30 hops:

    1 1 ms <1 ms <1 ms router.asus.com [120.29.117.143]
    2 * * * Request timed out.
    3 * * * Request timed out.
    4 3 ms 2 ms 2 ms 172.20.21.105 [172.20.21.105]
    5 3 ms 3 ms 2 ms 202.69.174.101
    6 2 ms 1 ms 2 ms 172.20.11.4 [172.20.11.4]
    7 3 ms 3 ms 3 ms 202.69.174.61
    8 4 ms 3 ms 3 ms 154.1.49.161-rev.convergeict.com [161.49.1.154]
    9 3 ms 9 ms 10 ms 194.1.49.161-rev.convergeict.com [161.49.1.194]
    10 * * * Request timed out.
    11 211 ms 211 ms 212 ms be100-1007.ash-5-a9.va.us [198.27.73.219]
    12 211 ms 212 ms 212 ms be100-1367.lax-la1-bb1-a9.ca.us [178.32.135.160]
    13 221 ms * 221 ms be100-1365.sjo-sv5-bb1-a9.ca.us [198.27.73.105]
    14 270 ms 235 ms 235 ms 103.5.15.28
    15 233 ms 233 ms 232 ms 103.5.15.17
    16 * * * Request timed out.
    17 * * * Request timed out.
    18 * * * Request timed out.
    19 235 ms 235 ms 235 ms ip195.ip-139-99-22.net [139.99.22.195]

    Hello @marvel
    we have fixed it. sorry for the issue:

    Awesome, thanks for the quick fix!!

  • cazrzcazrz Member

    OVH currently has the worst dashboard in my books. And not it says "408 Request Time-out".

  • cazrzcazrz Member

    @OVH_APAC
    renewal is May 2, vps is suspended on May 1.

    wtf!

Sign In or Register to comment.