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
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.
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.
Test from China Telecom, doesn't look good.
Not sure why it took 100ms to go from DO's switch to their speedtest server.
My server has this problem too. Get about 20-70 KB/s so I fire ticket yesterday and here reply from DO
btw my traceroute I show them I don't hit UK/London.
via NTT I got about 700 KB/s
I update my server from their own repository, only got 50 KB/s. So I switch mirror to mirror.nus.edu.sg
there is no packet loss just worst speed to outside Asian region,
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.
all ready did 2 days ago
problem fixed :P
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 * .
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
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.
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).
LOL my VPS too, few hours ago I got 20MB/s download from US
@tommy, in fact, few hours ago I actually wanted to say "the problem WILL appear again in no time". And here it comes...
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