Howdy, Stranger!

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


Problem with Singapore Server DigitalOcean
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.

Problem with Singapore Server DigitalOcean

mentarimentari Member

Any LET member have Singapore location that have problem with network speed recently , i try to download 100mb file and it take more than 30 minute to complete

Comments

  • Are you having packet loss? My droplet there is having connectivity issues, sometimes up to 98% packet loss. Support is taking quite some time to figure out what's wrong. Already gave them an MTR. Every reply there's a new name popping up. Its damn annoying.

  • rm_rm_ IPv6 Advocate, Veteran
    edited April 2014

    mpkossen said: My droplet there is having connectivity issues, sometimes up to 98% packet loss.

    In my experience Telia just filters out ICMP completely, at least from/to some source ranges.
    I suppose this is a left-over from them fighting multiple DDoSes in Singapore.
    As my route to them alternates between Telia, NTT and Tata for whatever reason, this effect comes and goes:

    But even while my droplet will have 100% packet loss on IPv4 ping, it pings absolutely fine on IPv6 (via the HE.net tunnel), and the network speed on both IPv4 and IPv6 is alright.

  • halczyhalczy Member
    edited April 2014

    Test from China Telecom, doesn't look good.

    Not sure why it took 100ms to go from DO's switch to their speedtest server.

  • tommytommy Member

    My server has this problem too. Get about 20-70 KB/s :( so I fire ticket yesterday and here reply from DO

    Once of our service providers have had an outage on their links from London which has resulted in congestion along some of the other paths.
    They are working on the issue but there is no ETR just yet. 
    

    btw my traceroute I show them I don't hit UK/London.

    5 las-bb1-link.telia.net (62.115.138.118) 196.544 ms las-bb1-link.telia.net (213.155.134.194) 182.236 ms las-bb1-link.telia.net (62.115.138.118) 196.817 ms
    6 ae8.edge1.LosAngeles.Level3.net (4.68.70.129) 191.435 ms 177.710 ms 197.148 ms
    7 vlan70.csw2.LosAngeles1.Level3.net (4.69.144.126) 247.810 ms 248.534 ms vlan60.csw1.LosAngeles1.Level3.net (4.69.144.62) 237.217 ms
    8 ae-62-62.ebr2.LosAngeles1.Level3.net (4.69.137.17) 256.996 ms 257.450 ms ae-72-72.ebr2.LosAngeles1.Level3.net (4.69.137.21) 262.732 ms
    9 ae-3-3.ebr3.Dallas1.Level3.net (4.69.132.78) 250.673 ms 271.519 ms 251.651 ms
    10 * * *
    11 ae-101-101.ebr1.Atlanta2.Level3.net (4.69.202.65) 244.045 ms 244.027 ms 240.188 ms
    12 ae-1-10.bar1.Charlotte1.Level3.net (4.69.200.209) 268.076 ms 277.770 ms 256.860 ms
    13 ae-11-11.bar2.Charlotte1.Level3.net (4.69.200.206) 271.437 ms 257.428 ms 271.409 ms
    14 ae-3-3.car2.Charlotte1.Level3.net (4.69.200.222) 270.931 ms 271.785 ms 256.686 ms
    15 CAROLINA-IN.car2.Charlotte1.Level3.net (4.71.126.30) 273.462 ms 268.022 ms 268.021 ms 
    

    via NTT I got about 700 KB/s

    3 103.253.144.249 (103.253.144.249) 0.581 ms 0.543 ms 0.268 ms
    4 116.51.27.189 (116.51.27.189) 1.242 ms 1.166 ms 1.123 ms
    5 ae-1.r20.sngpsi05.sg.bb.gin.ntt.net (129.250.3.146) 1.108 ms 1.092 ms 1.063 ms
    6 ae-3.r20.snjsca04.us.bb.gin.ntt.net (129.250.3.48) 180.825 ms 180.567 ms 173.147 ms
    7 ae-4.r21.asbnva02.us.bb.gin.ntt.net (129.250.4.102) 253.299 ms 247.220 ms 244.740 ms
    8 ae-0.r20.asbnva02.us.bb.gin.ntt.net (129.250.4.4) 243.524 ms 263.389 ms 241.675 ms
    9 ae-8.r23.nycmny01.us.bb.gin.ntt.net (129.250.2.148) 250.727 ms 248.639 ms 265.036 ms
    10 ae-13.r05.nycmny01.us.bb.gin.ntt.net (129.250.4.166) 250.438 ms ae-1.r05.nycmny01.us.bb.gin.ntt.net (129.250.4.69) 247.856 ms ae-13.r05.nycmny01.us.bb.gin.ntt.net (129.250.4.166) 250.991 ms
    11 ae3.ar1.nyc3.us.nlayer.net (69.31.34.120) 249.235 ms 254.903 ms *
    12 as20473.ae7.ar1.nyc3.us.nlayer.net (69.31.34.62) 248.782 ms 244.896 ms 239.750 ms
    13 ethernet1-50-c11-8-c6-1.pnj1.choopa.net (108.61.138.66) 249.098 ms 257.702 ms 260.750 ms 
    
  • tommytommy Member

    halczy said: Not sure why it took 100ms to go from DO's switch to their speedtest server.

    I update my server from their own repository, only got 50 KB/s. So I switch mirror to mirror.nus.edu.sg

  • @mpkossen said:
    Are you having packet loss? My droplet there is having connectivity issues, sometimes up to 98% packet loss. Support is taking quite some time to figure out what's wrong. Already gave them an MTR. Every reply there's a new name popping up. Its damn annoying.

    there is no packet loss just worst speed to outside Asian region,

    CPU model : Intel(R) Xeon(R) CPU E5-2630L 0 @ 2.00GHz
    Number of cores : 1
    CPU frequency : 1999.999 MHz
    Total amount of ram : 497 MB
    Total amount of swap : 0 MB
    System uptime : 5 min,
    Download speed from CacheFly: 5.83MB/s
    Download speed from Coloat, Atlanta GA: 849KB/s
    Download speed from Softlayer, Dallas, TX: 1.23MB/s
    Download speed from Linode, Tokyo, JP: 3.03MB/s
    Download speed from i3d.net, Rotterdam, NL: 1020KB/s
    
    
    root@mysg:~# wget http://tx.lg.fliphost.net/100MB.test
    --2014-04-15 16:39:11-- http://tx.lg.fliphost.net/100MB.test
    Resolving tx.lg.fliphost.net (tx.lg.fliphost.net)... 38.68.13.24, 2602:ffe8:100:1::2
    Connecting to tx.lg.fliphost.net (tx.lg.fliphost.net)|38.68.13.24|:80... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: 100000000 (95M) [application/octet-stream]
    Saving to: `100MB.test'
    
    1% [ ] 1,704,994 22.6K/s eta 53m 9s 
    
  • gonggogonggo Member
    edited April 2014

    from my DO-sg box
    `
    [~]# wget -O /dev/null http://cachefly.cachefly.net/100mb.test
    --2014-04-15 23:45:23-- http://cachefly.cachefly.net/100mb.test
    Resolving cachefly.cachefly.net... 205.234.175.175
    Connecting to cachefly.cachefly.net|205.234.175.175|:80... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: 104857600 (100M) [application/octet-stream]
    Saving to: â/dev/nullâ

    100%[======================================>] 104,857,600 32.5M/s in 3.2s

    2014-04-15 23:45:26 (30.9 MB/s) - /dev/null

    [~]# wget -O /dev/null http://tx.lg.fliphost.net/100MB.test
    --2014-04-15 23:46:26-- http://tx.lg.fliphost.net/100MB.test
    Resolving tx.lg.fliphost.net... 38.68.13.24, 2602:ffe8:100:1::2
    Connecting to tx.lg.fliphost.net|38.68.13.24|:80... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: 100000000 (95M) [application/octet-stream]
    Saving to: â/dev/nullâ

    100%[======================================>] 100,000,000 5.42M/s in 24s

    2014-04-15 23:46:51 (3.96 MB/s) - /dev/null
    `

  • Hey,

    Can any of you who haven't already submitted a ticket about this issue do so? We're trying to track and fix!

    Thanks.

  • mentarimentari Member
    edited April 2014

    @Sebguer said:
    Hey,

    Can any of you who haven't already submitted a ticket about this issue do so? We're trying to track and fix!

    Thanks.

    all ready did 2 days ago

  • aoleeaolee Member
    $ wget http://tx.lg.fliphost.net/100MB.test
    --2014-04-16 01:07:07--  http://tx.lg.fliphost.net/100MB.test
    Resolving tx.lg.fliphost.net... 38.68.13.24, 2602:ffe8:100:1::2
    Connecting to tx.lg.fliphost.net|38.68.13.24|:80... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: 100000000 (95M) [application/octet-stream]
    Saving to: “100MB.test”
    
    100%[===================================>] 100,000,000 4.23M/s   in 27s
    
    2014-04-16 01:07:35 (3.56 MB/s) - “100MB.test” saved [100000000/100000000]
    
  • tommytommy Member

    problem fixed :P

  • nonubynonuby Member
    edited April 2014

    Using ping, traceroute and MTR (and variants) to detect packet loss kills kittens. If you want to determine packet loss ideally one should begin with setting up a iperf udp flow.

    ICMP responses from intermediate routes (peering hubs, transit providers whatever) are not accurate, the only thing useful is the route (which is why sometimes DO request it, and again one sided), not the RTT of intermediate routes, nor the packet loss showing for intermediate routers. It's not accurate on intermediate routers for two reasons (3 if you count those that completely drop/ignore ICMP) 1) routers handle ICMP ttl off the routing engine, and general have hardcoded limits to how much the process per second (if at all) - see Stallman's paper 2) the router path back to you (strangely) might not be same path you observe in the traceroute (again referenced in Stallman's paper because ISPs tend to put router in a special router subnet) not have same routing path as packets transiting through * .

    • i.e. say you have A -> B -> C -> D -> E and you traceroute from A to E and see that A rtt is 1ms B is 13ms C is 50ms D is 188ms and E is 88ms, pretty common. How is that possible? D isn't necessarily overloaded/congested/faulty/mis-timing, its usually because when D originates a packet (such as TTL expiry response on traceroute) the IP of the router is in a subnet which isn't configure to use the same routes.

    All that said, Ive seen DO Singapore connection behave erratic in recent weeks, however others in the regions seem affected to (SimplerCloud, albeit much smaller), with more competition in the region (Azure SG etc.. and the battle of the cloud providers) things should only get better.

    Update: Not Stallman - bah I mean Richard A Steenbergen / nLayer - Google for his paper on traceroute

  • rm_rm_ IPv6 Advocate, Veteran
    edited April 2014

    tommy said: problem fixed :P

    Funny because now I am getting 20 KB/sec from http://tx.lg.fliphost.net/100MB.test (was 4 MB/sec before).

    updated some time later: and now it's 4 MB/sec again.

    nonuby said: Using ping, traceroute and MTR (and variants) to detect packet loss kills kittens.

    Way to come off as a snobist asshole right in the first sentence there, ping/mtr do have their use, just need to know what you're looking at. E.g. in the screenshot some posts above things are quite clear-cut (15-20% packet loss starting from a certain hop, all you need to pinpoint the exact cause is a similar trace in the reverse direction), but don't go as some users and raise fuss on forums when you see one router with 70% packet loss (with zero packet loss on all hops before and after it).

  • tommytommy Member

    rm_ said: Funny because now I am getting 20 KB/sec from http://tx.lg.fliphost.net/100MB.test (was 4 MB/sec before).

    LOL my VPS too, few hours ago I got 20MB/s download from US

     2% [>                                      ] 2,757,608    155K/s  eta 10m 8s
    
  • eLohkCalbeLohkCalb Member
    edited April 2014

    @tommy, in fact, few hours ago I actually wanted to say "the problem WILL appear again in no time". And here it comes... :D

    From the VPS I have with them, I find that the routes are like the weather which is purely mood based.

  • tommytommy Member

    eLohkCalb said: @tommy, in fact, few hours ago I actually wanted to say "the problem WILL appear again in no time". And here it comes... :D

    From the VPS I have with them, I find that the routes are like the weather which is purely mood based.

    sadly but that's true

Sign In or Register to comment.