said by kaugustino9:Hello ShawSean,
I've been having some really poor speed issues here in Edmonton for the past couple of weeks. I think I might have tracked the problem to a lossy router of a transit provider Shaw is peered with. Here is an mtr from myself to my server:
[snip]
I know mtr isn't really fool proof since a lot of backbone routers prioritize traffic directed at them differently than what is routed through them. However I believe the as6453.net routers to be the source of this problem. I did some further testing using looking glasses from both as6453.net and cogentco. From the as6453 looking glass pinging back to me there was packet loss in 2 out of every 5 runs, but no packet loss when I ran the test going forward to the server I mtr'd. Using the cogentco looking glass pinging back to me there was also packet loss pinging back to me, but no packet loss pinging toward the server again. So I'm fairly certain the problem lies with as6453.
If you could help me with this issue I'd be very grateful.
Thanks!
I took a look at your destination from my connection in Calgary. While I don't end up routing through as6453.net I still end up with a large amount of packetloss near the end of cogentco's network (more than you were seeing). Wanting to avoid any re-prioritization of ICMP packets I re-ran my test using TCP SYN packets to port 80, followed by a RST packet, by the bucketful (assuming a bucket is 100 packets for each respective TTL :P) I didn't want more than 100 since that could be seen as a SYN flood. The same principle applies with the default *nix UDP traceroute though; when a packet expires an ICMP packet should be sent back indicating the original packet expired in transit.
You can have a look at my results (and the command I ran) here »
pastebin.com/q4W4eVSe - its pretty huge and I didn't want to clutter up this forum.
What I see is that around hop 15 ("around" because there are different routes used for each packet right from the get go [I enforced a start TTL of 4, and even then we had divergent routes], not that different routes are necessarily a bad thing) the 'time exceeded in-transit' packets were starting to be reliably unseen.
A few hops further, however, (around 17) we start to see reliable 'time exceeded in-transit' responses again. This means that while these cogentco routers are not sending the 'time exceeded in-transit' packets (either load related or design related), they are not seeing much packetloss; the TCP SYN packets are making it through when the TTL is high enough.
The last hop (18) is supposed to be your target (dragon305.startdedicated.com), but due to the differing paths 209.239.152.4 shows up for ~50% of the responses. Since it is listening on port 80 we should see SYN ACK packets back from it (i.e. packets that would not be re-prioritized or preferentially dropped by the network in between). The 209.239.125.4 responses there are the same-old 'time exceeded in-transit'. If we prune out the divergent route responses (and only focus on the SYN ACK responses we need to look at), I count 52 responses and 2 lost packets, just shy of 4% packetloss right at the destination.
If you have a linux machine, or can get a linux VM running, I would try to run the same test from your location to see if your results match mine.