- Feb 13, 2013
- 3
- 0
- 10,510
My house subscribes to Time Warner cable, and we get a pretty steady 50mbps down on our line, but we've been having connectivity issues. I've been trying, on my own, to get to the most specific issue I can, because talking to their support has been like pulling teeth; they usually don't know much about what I'm talking about.
Mostly, we're having trouble staying connected to online games (FFXIV, TOR, Minecraft, Planetside 2, etc) but the issue also corresponds with horrible experiences trying to load websites. I've pretty much eliminated everything on the customer side of the demarc, and have found that when these issues arise, the first hop out of our gateway (ISP side) usually has a ridiculous 3000ms+ reply, according to traceroutes. Here's where the tricky part comes in:
Doing a traceroute to a remote site results in that ridiculous latency. Doing a traceroute directly TO the ISP side's WAN link doesn't. Pinging the ISP side doesn't. Pinging any other remote site doesn't -- it's ONLY when I traceroute further than that ISP side IP... however, this just CAN'T be coincidence, because when it's acting up, websites load horribly slow, and sometimes only partially.
My question is this: What would cause the ISP's side to return such a high latency only when going through a traceroute, and not a direct ping? What, specifically, can I point their techs to in order to hopefully get this solved?
Traceroute - Stopped after the problematic hop
Ping
Mostly, we're having trouble staying connected to online games (FFXIV, TOR, Minecraft, Planetside 2, etc) but the issue also corresponds with horrible experiences trying to load websites. I've pretty much eliminated everything on the customer side of the demarc, and have found that when these issues arise, the first hop out of our gateway (ISP side) usually has a ridiculous 3000ms+ reply, according to traceroutes. Here's where the tricky part comes in:
Doing a traceroute to a remote site results in that ridiculous latency. Doing a traceroute directly TO the ISP side's WAN link doesn't. Pinging the ISP side doesn't. Pinging any other remote site doesn't -- it's ONLY when I traceroute further than that ISP side IP... however, this just CAN'T be coincidence, because when it's acting up, websites load horribly slow, and sometimes only partially.
My question is this: What would cause the ISP's side to return such a high latency only when going through a traceroute, and not a direct ping? What, specifically, can I point their techs to in order to hopefully get this solved?
Traceroute - Stopped after the problematic hop
tracert -d -h 4 google.com
Tracing route to google.com [74.125.225.39]
over a maximum of 4 hops:
1 1 ms 1 ms 1 ms 192.168.1.1
2 2 ms 2 ms 2 ms 192.168.0.1
3 2739 ms 2820 ms 2657 ms 66.66.152.1
4 13 ms 14 ms 12 ms 24.93.9.222
Trace complete.
Tracing route to google.com [74.125.225.39]
over a maximum of 4 hops:
1 1 ms 1 ms 1 ms 192.168.1.1
2 2 ms 2 ms 2 ms 192.168.0.1
3 2739 ms 2820 ms 2657 ms 66.66.152.1
4 13 ms 14 ms 12 ms 24.93.9.222
Trace complete.
Ping
ping google.com
Pinging google.com [74.125.225.97] with 32 bytes of data:
Reply from 74.125.225.97: bytes=32 time=31ms TTL=53
Reply from 74.125.225.97: bytes=32 time=33ms TTL=53
Reply from 74.125.225.97: bytes=32 time=30ms TTL=53
Reply from 74.125.225.97: bytes=32 time=31ms TTL=53
Ping statistics for 74.125.225.97:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 30ms, Maximum = 33ms, Average = 31ms
Pinging google.com [74.125.225.97] with 32 bytes of data:
Reply from 74.125.225.97: bytes=32 time=31ms TTL=53
Reply from 74.125.225.97: bytes=32 time=33ms TTL=53
Reply from 74.125.225.97: bytes=32 time=30ms TTL=53
Reply from 74.125.225.97: bytes=32 time=31ms TTL=53
Ping statistics for 74.125.225.97:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 30ms, Maximum = 33ms, Average = 31ms
Facebook
Twitter
Instagram