| [TWC] Downstream issues - latency/packetloss TWC Internal Case #: 13437255
Prior to reporting problems:
»pastebin.com/i5cyy64u / »pastebin.com/JESX3LjE (with my router)
»pastebin.com/hAh1Sgnm (bypassing my router)
After reporting problems (several calls, many hours wasted, NEW modem (at this point we've played the game, a truck tech has come to the residence and done their job).
»pastebin.com/kW8ZKYvp (outbound w/ **TWC Router Dg860a**)
»pastebin.com/vfbfCFWB (inbound)
Please note we've had several different IPs at this point, and while the inbound route does change (sometimes I have to DFW-HOU-DFW :/ ) hop 13 (70.125.216.174) is always my second to last hop.
We've been told now that we should expect callbacks and forward progress. (we're still waiting on that). |
|
 kilrathi
join:2005-04-22
Rockaway Park, NY | Are you sure this is downstream issue? cause packet loss is clear on the outbound |
|
| Yes, beginning one hope outside of my residence -- Guess that's not far downstream, but it's downstream of "what i'm responsible for"
You can also see on the inbound - issues begin one hop out from me.
*EDIT: On the inbound I showed this time , 70.125.216.174 doesn't show packetloss (it exists) but a worst return time of 13738 (that's 13 seconds btw) is definitely "a problem" and sure as $!%# not de-prioritization |
|
kilrathi
join:2005-04-22
Rockaway Park, NY | reply to skiingsean
any packet loss over like 0.5% constantly is not acceptable especially if you use voip. |
|
|
|
| ...I'm completely in agreement, not sure where we're not seeing eye-to-eye then
Yes, i'm complaining about the packetloss "outside of my residence" and the latency "outside of my residence" that begins and, persists, starting at hop #2 |
|
| reply to skiingsean
Got home last night around 1730 CDT and things seemed to be a bit better -- Restarted MTR's and other tests and only saw spikes on my gateway (outbound hop #2) but nothing persisted through the route. This lasted for about and hour or two. Since then my ongoing tests show packet loss starting and persisting through the trace and high latency spikes up till the end.
Hey TWC, anyone going to offer us one of the many callbacks we've been promised? What about our open support case (referenced in my first post)?
uVerse is starting to sound like my preferred fix -- I think the roommate is beginning to feel the same (he's the one that likes TWC), it's not this guy...
~Sean
(side note) -- Here's a new INBOUND mtr that I just started --- ~500 packets and I'm already seeing 0.2% on #11 and an 18second rtt
My traceroute [v0.82]
sbuehler2.softlayer.local (0.0.0.0) Fri Apr 5 09:37:05 2013
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 172.30.176.1 0.0% 498 1.5 2.2 0.8 27.2 1.9
2. ir01.sr01.dal05 0.0% 498 0.9 1.0 0.5 15.3 1.5
3. slr01.dal05.softlayer.com 0.0% 498 0.9 7.4 0.6 1969. 98.1
4. ae4.dar02.sr01.dal05.networklayer.com 0.0% 498 0.7 1.2 0.5 33.5 3.0
5. ae5.bbr02.eq01.dal03.networklayer.com 0.0% 498 1.3 2.1 1.1 55.7 5.3
6. ae-11-0.pr0.dfw10.tbone.rr.com 0.0% 498 1.3 3.3 1.1 66.6 8.2
7. ae-10-0.cr0.dfw10.tbone.rr.com 0.0% 498 6.4 5.2 1.4 10.4 2.3
8. 66.109.6.89 0.0% 498 5.3 6.1 2.0 45.9 2.9
9. agg1.dllatx1k-cr01.texas.rr.com 0.0% 498 5.5 7.0 3.0 11.8 2.3
10. tge9-1.dllatx12-er01.texas.rr.com 0.0% 498 3.1 3.3 2.8 33.8 2.4
11. 70.125.216.174 0.2% 498 22.4 384.1 3.3 18847 2120.
12. cpe-76-187-107-27.tx.res.rr.com 0.0% 497 13.0 18.3 11.6 256.4 20.7
*EDIT: For anyone reading this for the first time - pair this with any of my outbound MTRs in post one and you'll understand the correlation. |
|
| And here are the results of today's summary:
(»pastebin.com/kAz2jMdg)
My traceroute [v0.82]
sasha.doomed-knowledge.com (0.0.0.0) Fri Apr 5 17:01:10 2013
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 192.168.0.1 0.0% 29212 0.6 0.5 0.5 618.3 6.5
2. cpe-76-187-96-1.tx.res.rr.com 1.5% 29212 29.3 109.3 9.0 20703 879.0
3. tge7-3.dllatx12-er01.texas.rr.co 1.4% 29212 13.2 24.1 8.3 12461 386.4
4. tge2-1.dllatx1k-tr01.texas.rr.co 1.4% 29212 21.1 29.7 8.9 12046 408.2
5. agg21.dllatxl3-cr01.texas.rr.com 1.4% 29212 14.9 29.9 9.6 12170 409.9
6. ae-8-0.cr0.dfw10.tbone.rr.com 1.5% 29211 19.5 27.0 9.9 12210 368.8
7. ae-1-0.pr0.dfw10.tbone.rr.com 1.4% 29211 19.7 37.3 13.9 11993 457.6
8. 107.14.16.186 1.8% 29211 16.5 37.8 13.9 12873 430.4
9. ae-2-70.edge3.Dallas1.Level3.net 1.5% 29211 19.4 29.3 14.0 12177 336.6
10. b.resolvers.Level3.net 1.5% 29211 18.8 27.0 14.1 12249 369.2 |
|
| reply to skiingsean
Saturday morning not more than 2200 packets in
»pastebin.com/rCQqU7ec
> 2% loss |
|
| We've now had TWC close our original escalation and just had our second truck tech show up at the door to "fix our problem"
This guy now tries to tell us that "packet loss is acceptable" it's a fact of life.
---------------
I'm growing tired of this bullshit TW -- |
|
kilrathi
join:2005-04-22
Rockaway Park, NY | reply to skiingsean
Hey some tw techs dont know difference between packet loss and ping so yea. |
|
| reply to skiingsean
What are your signal levels? Have you tried the direct forum? |
|
| reply to skiingsean
Most times, traceroutes are misused to track 'latency'. Only the destination latency truly matters. To add to that, however, when you begin to see latency go up, then continue to the end of the trace, there "could" be a congestion issues on a link where the latency becomes constant to the end. One of the best ways to see that is using PingPlotter.
The one thing that everyone must remember is that
1) ICMP packets (those used in traceroute and ping in Windows-based computers) are treated by ISP routers with the absolute LOWEST priority. During "peak" times, those routers are processing heavy loads of traffic and it can seem like there are "issues" when there really are none. Google, Yahoo, and other search providers host their websites "in the cloud" and load balance across many different servers and/or routers in various places. This explains why everyone gets a different IP address for Google.com and Yahoo.com.
2) The router on hop 2 is actually the CMTS (cable modem termination system). It will ALWAYS show tons of latency due to #1.
These steps should always be followed in order:
1) do a continuous ping on the URL/domain you are trying to get to (ping -t)
2) do a continuous ping on the DNS servers you are using
2) do a traceroute/PingPlotter once ping times begin to have constant latency. Does it take a different route?
3) Flush your DNS resolver cache (ipconfig /flushdns) and try again. Does the issue persist/continue?
It may well be due to over-utilization within your respective local area. It could be caused by others doing heavy uploads (a.k.a BitTorrent) within your local area or there could be local noise issues causing the problem as well (typically caused by animals and/or those trying to steal cable services, but could also be caused by faulty local power wiring).
The best thing is to do is to call tech support when it's happening as it's extremely hard in tech support to troubleshoot something you cannot "see" or duplicate unless you do it when it's happening. |
|
4 edits | wewt -- well for starters, i'm just simply happy to have had "someone" update. Now to get to answering your questions/remarks.
You've got two parts so I'll break them down between A (1,2) and B (1,2,2,3)
A)
1 - You're absolutely correct, most devices out there deprioritize ICMP. This is why you can do a traceroute (or in my case an MTR) and you'll see one hop provide some packetloss, some latency, or complete packetloss/latency -- You know that this device has "deprioritized" your ICMP because the latency and loss do not persist throughout the route.
**1a - Please define "The Cloud"
**1b - The magical "Cloud" is not why www.google.com resolves to multiple IPs
[root@sasha ~]# host www.google.com
www.google.com has address 74.125.225.242
www.google.com has address 74.125.225.243
www.google.com has address 74.125.225.244
www.google.com has address 74.125.225.240
www.google.com has address 74.125.225.241
www.google.com has IPv6 address 2607:f8b0:4000:802::1013
[root@sasha ~]#
»en.wikipedia.org/wiki/Domain_Name_System
And yes, each one of those IPs is indeed a VIP
2 - Hop two might be termed as a CMTS (I'm not really up on broadband ISP technology) -- However CMTSs are at the "head office" (afaik) -- Either way it's also my gateway .
I do realize that this hop can show packetloss and or latency. That would be ok if my packetloss/latency did not persist until the end hop. In fact my newest cable modem (third) from TWC is actually doing just this, using the DG860a I am now showing solid "loss" on the first hop, but latency is low and neither the packetloss nor the latency continues beyond this first hop immediately into the mtr -- my issues begin as soon as I have a latency spike (which starts at hop 2) and my true issues persist (as shown in my MTRs).
B)
1 - I have been doing a continuous ping on an IP. ping -t is for windows and in my pastebins above you can see my MTR.
quote:
Description : Mtr is a network diagnostic tool that combines ping and traceroute
: into one program. Mtr provides two interfaces: an ncurses interface,
: useful for using Mtr from a telnet session; and a GTK+ interface for X
: (provided in the mtr-gtk package).
2 - I use many DNS resolvers. DNS is not in question here nor is it even relevant.
2 - quote:
2) do a traceroute/PingPlotter once ping times begin to have constant latency. Does it take a different route?
Different route then what?!? You need to have a starting route before you can get a differing one. In fact, please take a look at the MTRs that I have provided along the way. They are time stamped and clearly show you what routes I am having issues with.
3 - Again, DNS is irrelevant.
------------
I don't know if my issues are over subscription -- At this point I just know that I've been having issues for 3 weeks solid (all day long, not "peak times") --- "BitTorrent" is not synonymous with "heavy uploads" as a generality but is simply one of 'everything' that can accumulate to the aggregate total throughput/usage/saturation. --- and I'm done with it --- I can guarantee you that VOIP (one real world usage example) would be utterly destroyed by the current status of my service. What's sad is that I would actually have to purchase TWC phone service for me to PROVE to that there's an issue (since it wouldn't work as is).
quote:
The best thing is to do is to call tech support when it's happening as it's extremely hard in tech support to troubleshoot something you cannot "see" or duplicate unless you do it when it's happening.
I've called tech support, in fact we've been dealing with them for 1 week solid.
WTF do you mean "you cannot "see"" -- Have you even viewed the links/mtr's that I've provided?!?!? |
|
| reply to skiingsean
How about this .. This is what a normal MTR/traceroute/internetconnection/ffsIdontCareSomething should look like
»pastebin.com/LBGt4Ufp |
|
