Connection issues.

Woven

Woven

New Member
So some of you know myself and Renee are having connection issues that hit us every night from 8-8:30pm (est) and last until 12-1am.

I've been doing my own trouble-shooting (As much as I can from my home-office in order to compile evidence for my ISP: They tend to disbelieve, if they don't experience it..and end up testing things when the issue is not active). And in working with others we believe it's a capacity issue. I'm going to post 3 tracerts to the terenas server for those who are network geeks and you can tell me what you think.

The first one before severe issues (My latency in game is typicaly 200..not great for a cable connection, but perfectly acceptable/playable with no issues)

1) Tracing route to 12.129.233.23 over a maximum of 30 hops

1 1 ms 4 ms <1 ms 192.168.1.1
2 23 ms 8 ms 8 ms 10.1.1.1
3 14 ms 10 ms 11 ms gw-7206-gige-0-2.tvscable.com [63.173.48.65]
4 32 ms 52 ms 32 ms sl-gw20-roa-15-15.sprintlink.net [144.232.200.85
]
5 36 ms 31 ms 34 ms sl-bb22-roa-2-0.sprintlink.net [144.232.17.185]

6 34 ms 40 ms 37 ms sl-bb20-roa-0-0.sprintlink.net [144.232.17.197]

7 50 ms 39 ms 43 ms sl-crs1-chi-0-13-3-0.sprintlink.net [144.232.18.
36]
8 * 38 ms 36 ms sl-st21-chi-13-0-0.sprintlink.net [144.232.20.91]
9 37 ms 35 ms 46 ms 192.205.33.157
10 93 ms 87 ms 92 ms cr1.cgcil.ip.att.net [12.122.133.26]
11 90 ms 100 ms 98 ms cr2.dvmco.ip.att.net [12.122.31.85]
12 84 ms 90 ms 85 ms cr1.slkut.ip.att.net [12.122.30.25]
13 88 ms 92 ms 90 ms cr2.la2ca.ip.att.net [12.122.30.30]
14 84 ms 95 ms 93 ms gar5.la2ca.ip.att.net [12.122.129.25]
15 83 ms 83 ms 83 ms 12.122.255.74
16 83 ms * 98 ms mdf001c7613r0003-gig-10-1.lax1.attens.net [12.12
9.193.242]

Trace complete. (Couple of dropped packets)

2) Tracing route to 12.129.233.23 over a maximum of 30 hops

1 <1 ms <1 ms <1 ms 192.168.1.1
2 13 ms 12 ms 23 ms 10.1.1.1
3 43 ms * 51 ms gw-7206-gige-0-2.tvscable.com [63.173.48.65]
4 38 ms 55 ms * sl-gw20-roa-15-15.sprintlink.net [144.232.200.85]
5 36 ms 34 ms 36 ms sl-bb22-roa-2-0.sprintlink.net [144.232.17.185]

6 88 ms 50 ms 65 ms sl-bb20-roa-0-0.sprintlink.net [144.232.17.197]

7 60 ms 39 ms 36 ms sl-crs1-chi-0-13-3-0.sprintlink.net [144.232.18.
36]
8 * 46 ms 58 ms sl-st21-chi-13-0-0.sprintlink.net [144.232.20.91
]
9 66 ms 62 ms 69 ms 192.205.33.157
10 106 ms 110 ms 118 ms cr1.cgcil.ip.att.net [12.122.133.26]
11 * 97 ms 115 ms cr2.dvmco.ip.att.net [12.122.31.85] 12 119 ms 111 ms 113 ms cr1.slkut.ip.att.net [12.122.30.25]
13 115 ms 90 ms 89 ms cr2.la2ca.ip.att.net [12.122.30.30]
14 102 ms 104 ms 112 ms gar5.la2ca.ip.att.net [12.122.129.25]
15 88 ms 116 ms 107 ms 12.122.255.74
16 104 ms * 121 ms mdf001c7613r0003-gig-10-1.lax1.attens.net [12.129.193.242]

Trace complete.

Yikes, lots of packet drops. And this is between the time frame of 8pm-1am.
My latency here in game is 900-2k:3k. Not playable. The 3rd hop is my local isp. (Sprint is their backbone)

3) Tracing route to 12.129.233.23 over a maximum of 30 hops

1 1 ms <1 ms <1 ms 192.168.1.1
2 20 ms 19 ms 17 ms 10.1.1.1
3 25 ms 23 ms 21 ms gw-7206-gige-0-2.tvscable.com [63.173.48.65]
4 37 ms 36 ms 57 ms sl-gw20-roa-15-15.sprintlink.net [144.232.200.85
]
5 32 ms 35 ms 32 ms sl-bb22-roa-2-0.sprintlink.net [144.232.17.185]

6 41 ms 30 ms 29 ms sl-bb20-roa-0-0.sprintlink.net [144.232.17.197]

7 38 ms 55 ms 51 ms sl-crs1-chi-0-13-3-0.sprintlink.net [144.232.18.
36]
8 37 ms 51 ms 40 ms sl-st21-chi-13-0-0.sprintlink.net [144.232.20.91
]
9 42 ms 51 ms 34 ms 192.205.33.157
10 96 ms 87 ms 92 ms cr1.cgcil.ip.att.net [12.122.133.26]
11 92 ms 83 ms 99 ms cr2.dvmco.ip.att.net [12.122.31.85]
12 101 ms 89 ms 86 ms cr1.slkut.ip.att.net [12.122.30.25]
13 114 ms 96 ms 104 ms cr2.la2ca.ip.att.net [12.122.30.30]
14 92 ms 90 ms 93 ms gar5.la2ca.ip.att.net [12.122.129.25]
15 97 ms 94 ms 93 ms 12.122.255.74
16 * 91 ms 97 ms mdf001c7613r0003-gig-10-1.lax1.attens.net [12.12

And this is when things get back to "normal" in game..but we still see a drop at hop 16, like we saw in Tracert 1
My latency is once again in the 200 range.

During the time of tracert 2, If I ping any site (cmd/ping www) I get 25-50% packet losses. And pingplotter shows latency in every hop. (Except inside my home network)
 
Last edited:
Couple of things, try a reverse tracert and/or ping from a site like one of the following back to your modem or your ISP gateway:

http://www.missing.com/traceroute.html
http://www.traceroute.org/#USA

If you can, snag one from each ISP leg your traffic is passing through. This will be a map and might identify a peering problem with one of the many (sadly for you) upstream/peering connections.

Couple of questions:
- Do you have a NAT or firewall at all?
- Have you tried pinging with various MTU sizes, for example ping -s 1473 <Blizzard server ip> (I'd try dropping the MTU down to the old slip standard of 512)

I would suggest creating a baseline off peak to the following and track for 3 or 4 days, on the hour (script something to run a ping) which does the following:

ping to your default gateway/router
ping to your DNS server
ping to one of the default ips that commonly show up on each ISP network, but the last ip listed for sprint and the first one for att such as ...


gw-7206-gige-0-2.tvscable.com [63.173.48.65]
sl-gw20-roa-15-15.sprintlink.net [144.232.200.85]
192.205.33.157
cr1.cgcil.ip.att.net [12.122.133.26]
mdf001c7613r0003-gig-10-1.lax1.attens.net [12.129.193.242]


Repost some of those tracerts. For those who don't like the command line, I would personally recommend VisualRoute. I have used this tool for years and recently they have provided a lite version for free (about time!) from http://download.visualware.com/pub/vr/vrle.exe
 
Last edited:
Thanks Adam, I will run these tests tomorrow, before, during and after the above mentioned time frame and post back.
Did not see the added information.

Couple of questions:
- Do you have a NAT or firewall at all?
- Have you tried pinging with various MTU sizes, for example ping -s 1473 <Blizzard server ip> (I'd try dropping the MTU down to the old slip standard of 512)
Click to expand...

-I have no firewalls running. I turned off my wireless router FW and XP FW. I've tested over wireless network and direct cable connection to nic. Same results for all computers.
- I have not tried pinging with various MTU sizes. I can try that.

I would suggest creating a baseline off peak to the following and track for 3 or 4 days, on the hour (script something to run a ping) which does the following:
Click to expand...

Are you familure with pingplotter? I've been using that at the moment. http://www.pingplotter.com/
 
Last edited:
When we started having latency issues, it appeared as if the problem was between our house and the cable box out back. We had the cable company come out and replace the ends on all the wires (both within the house and outside). After that our response time was back to normal.

We've also had problems with modem failure and got a new one to resolve. Not sure if what I experienced will help you in any way, but wanted to share just in case.
 
Thanks Sheri. Was your issue through-out the day or during certain hours? Sounds like you had a generally poor connection. My issue only happens between certain hours. I fired up LOTRO (Free trial) to check latency during the hours I'm having issues and my latency was only 87. The route is different though for LOTRO and Wow.

My belief is that it's a capacity issue and our local provider needs to make more room. (And or speak to their backbone sprint)

For example I did this reverse last night during the hours after my connection tends to clear up. (After 12 am) and it's ok before (8pm) I'll be testing again tonight during the bad hours.

HOST LOSS RCVD SENT BEST AVG WORST
ge1-1-0-18-10g.core-01.easynews.com 0% 10 10 0.41 7.72 46.83
e-2-31-1000m.core-03.phx1.puregig.net 0% 10 10 0.31 0.41 0.67
ve5-10G.core-04.phx2.puregig.net 0% 10 10 0.29 1.34 10.05
v301.ar2.ph.hwng.net 0% 10 10 0.38 0.56 1.06
ve1033.r1.ph.hwng.net 0% 10 10 0.81 1.16 1.45
TenGigabitEthernet2-4.sar2.phx1.gblx.net 0% 10 10 1.09 2.21 6.89
sl-st21-la-4-0-0.sprintlink.net 0% 10 10 10.35 15.87 63.54
sl-crs1-ana-0-4-0-3.sprintlink.net 0% 10 10 11.33 15.73 49.99
sl-crs1-fw-0-0-0-2.sprintlink.net 0% 10 10 34.04 37.91 68.37
sl-crs1-kc-0-6-5-0.sprintlink.net 0% 10 10 68.03 68.25 68.57
sl-crs1-chi-0-5-0-1.sprintlink.net 0% 10 10 74.79 79.02 98.59
sl-bb20-roa-8-0-0.sprintlink.net 0% 10 10 72.43 75.23 99.55
sl-bb22-roa-0-0.sprintlink.net 0% 10 10 77.88 84.27 129.19
sl-gw20-roa-9-0.sprintlink.net 0% 10 10 72.47 72.68 73.11
sl-tvser1-46468-0.sprintlink.net 0% 10 10 92.60 92.87 93.28
ubr-7246-gige-0-1.tvscable.com 10% 9 10 91.81 92.65 94.09
dynamic-65-161-140-113.tvscable.com 10% 9 10 108.02 114.70 143.43

The router most likely responsible for your slow downloads in owned by tvscable.com.

The table above shows the route that packets take from us to you. If you are experiencing slow downloads from EasyNews, the problem is usually caused by an overloaded router along that route.


Thanks again for the thoughts though. They do still need to come out and check things. They claimed to do so the other day, leaving a door-tag..but myself and renee were both home during the hours they said they were here. No one was here, no tag. So I think they went to the wrong house heh..:)
 
Last edited:
unfortunatly most of hte issues are not in your provders network so they aren't going to try to fix it...once the packets leave their network it'sw not their issue. One revrese trace is going to convince them..expecially when they can watch their routers continuously. It may also be an oconomical question..that link could be overloaded..but it may be their cheapest one..depending on how much more expensive their other links are they may be intentionally routing across that link especailly since thei ssue are intermittent and not constant.
 
Thanks for the feed-back Hes.

It may turn out to be an even worse economical issue for them if ppl leave. I'm not the only one having issues. At their message board, others are also having issues. Worse then mine. Declines in DL speed from 600 40..kbps, disconnects at night etc etc. Some of the issue is inside their network. I have probably sent them 10 of my customers who were previously using dsl and not happy, some of them are now having issues. In the end, since they are the only bb company we have access to and I'm only being effected in wow between 8pm-1am, I'll probably stay with them. (unless the issues get worse) For a week last month our modem was doing the light dance (Power to send, back again, power to recieve, back again) No connection from about 10pm until the next morning. Right now, it's just severe latency in wow during certain hours. The general packet losses through out the day (25%) are not effecting my over-all DL/UL speeds.

I've not just sent in one reverse trace, to persuade them. I've sent in continuous pingplotter information over hours. (before, during and after my packet loss times) Showing the issue, some of it, is at their hop. If they were watching their routes continually they would have already seen the issue. They check things during the hours I'm not having issues and tell me it's fine, because they shut down shop 3hrs before the packet loss storm hits. Which is why I sent in before, during and after evidence from Friday and Sat. We will see what happens Monday. Unless they already know of the issue, but are denying it, hoping the amount of ppl effected is low and that it's cheaper to ignore them then work the issue. However, that also have consequences.

There is also a lot of chatter at the wow forums..about similar issues with WOW latency. People are fine until "Peak" hours then their latency gets out of control and they lose connection. The tracerts there I looked at all show dropped packets here:

16 83 ms * 98 ms mdf001c7613r0003-gig-10-1.lax1.attens.net [12.12
9.193.242]
 
Last edited:
attens is not your provider..attens is ATT which has their own massive backbone..hoever they also provide transit for other networks(think of it as a toll road)..the biggest issue is the internet if it works as designed will automatically route around congestion and failures..unfortunatly this is normally not lalowed to happen these days so the packets go where they are told instead of being allowed to find the best path.

upshot of manual control latency averages are much lower...downshot..when there is a problem it's magnified due to the ability to auto-route aorund issues being overriden.
 
actually that's the connection that traffic heads through..i can nearly guarentee your provider has more than one connection to the net..sprintlink is just where they are routing that traffic through.
 
actually that's the connection that traffic heads through..
Click to expand...

Yeah, they call it their backbone, so that's what I call it. (though it might be a part of the whole)

i can nearly guarentee your provider has more than one connection to the net
Click to expand...

I'll try to look into it.
 
Last edited:
from this thread and a little googlin i can name two tier 1 connections for tvs..sprintlink and att..That's two already..:)
 
Allanon said:
Couple of things, try a reverse tracert and/or ping from a site like one of the following back to your modem or your ISP gateway:

http://www.missing.com/traceroute.html
http://www.traceroute.org/#USA

If you can, snag one from each ISP leg your traffic is passing through. This will be a map and might identify a peering problem with one of the many (sadly for you) upstream/peering connections.

Couple of questions:
- Do you have a NAT or firewall at all?
- Have you tried pinging with various MTU sizes, for example ping -s 1473 <Blizzard server ip> (I'd try dropping the MTU down to the old slip standard of 512)

I would suggest creating a baseline off peak to the following and track for 3 or 4 days, on the hour (script something to run a ping) which does the following:

ping to your default gateway/router
ping to your DNS server
ping to one of the default ips that commonly show up on each ISP network, but the last ip listed for sprint and the first one for att such as ...


gw-7206-gige-0-2.tvscable.com [63.173.48.65]
sl-gw20-roa-15-15.sprintlink.net [144.232.200.85]
192.205.33.157
cr1.cgcil.ip.att.net [12.122.133.26]
mdf001c7613r0003-gig-10-1.lax1.attens.net [12.129.193.242]


Repost some of those tracerts. For those who don't like the command line, I would personally recommend VisualRoute. I have used this tool for years and recently they have provided a lite version for free (about time!) from http://download.visualware.com/pub/vr/vrle.exe
Click to expand...

when it comes to ping and traces i don't use windows as they use a non-standard size packet..if you avhe access to a linux/mac/unix box use traceroute which uses a standard sized packet...windows pings are always put at hte lowest queue in a router these days due to past poing o death vulnerabiliteis in the windows tcp stack.
 
right now heading form the cga server to the last ip you posted using a linux box:
65.161.140.113 (65.161.140.113), 30 hops max, 40 byte packets
1 cgalliance-gw.abbacomm.net (206.63.25.65) 0.778 ms 0.692 ms 0.808 ms
2 fe-2-0-br3.cet.com (198.202.26.89) 1.087 ms 1.232 ms 1.217 ms
3 ge-0-0-0-spk-cr1.cet.com (206.63.80.1) 270.852 ms 271.007 ms 271.017 ms
4 ge-0-1-sea-cr1.cet.com (198.202.26.2) 8.485 ms 8.493 ms 8.474 ms
5 204.181.35.201 (204.181.35.201) 8.761 ms * *
6 sl-bb21-sea-4-0-0.sprintlink.net (144.232.6.123) 8.479 ms 8.838 ms 8.304 ms
7 sl-crs1-chi-0-11-3-0.sprintlink.net (144.232.20.157) 52.925 ms 52.927 ms 52.909 ms
8 sl-bb20-roa-8-0-0.sprintlink.net (144.232.18.37) 55.626 ms 55.613 ms 55.594 ms
9 sl-gw20-roa-10-0.sprintlink.net (144.232.17.190) 55.574 ms 55.558 ms 55.539 ms
10 sl-tvser1-46468-0.sprintlink.net (144.232.200.86) 75.651 ms 76.588 ms 77.032 ms
11 ubr-7246-gige-0-1.tvscable.com (63.173.48.66) 81.912 ms 81.904 ms 80.162 ms
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
 
I told my wife we probably would not have a packet loss storm tonight because of the super-bowl. Our latency was fine. (Issues typically start at around 8-8:30 est) Pingplotter starts showing packet drops at almost every hop (except mine).

Anyways, thanks for the ongoing info.

Danny
 
When we were having our problems, I set our pingplotter to ping each second, and graphed 4 or 5 of the hops that appeared to be having the most trouble. When you see a red bar on all hops, it means that your problem is close - your house, your neighborhood router, your ISP....something like that. But when it gets out a few hops before having trouble, it's something else.

We were getting bursts of drops ranging from 3 to 25 seconds until we replaced the modem, router, and all the cable ends between here and the box out back ("we" being me & the cable guy doing our parts, respectively).

After that, the only problem I saw was sporadic 7% packet loss from a single router in Cinci.level3.net Traffic would often route around it, but only to another router that was dropping about 6%. I never left those two routers. Last time I checked, I still get that 6-7% loss at that spot, but it doesn't effect my gameplay at all. In fact, if I didn't run the pingplotter/traceroutes, I'd never know it.

The fact that you're effected more during peak hours doesn't really matter, I think. That's how mine was, too. I'd get a few lag spikes during the day (usually not enough to even kick me offline) but in the evening it was constantly bad for weeks. Again, re-ending the cables and replacing hardware here fixed my problem.
 
Pingplotter shows issues on hop3: ubr-7246-gige-0-1.tvscable.com 10% 9 10 91.81 92.65 94.09. 1-2 are fine. (My internal network is ok) I've tried a direct connection to nic care to. Same issue.

Here is my modem

: Frequency 435000000 Hz
Signal to Noise Ratio 37 dB
QAM QAM256
Network Access Control Object ON
Power Level 16 dBmV The Downstream Power Level reading is a snapshot taken at the time this page was requested. Please Reload/Refresh this Page for a new reading

Upstream Value
Channel ID 1
Frequency 37008000 Hz
Ranging Service ID 561
Symbol Rate 2.560 Msym/s
Power Level 34 dBmV

I'm up for your suggestions on replacing everything, as long as they do their part. In the past I've had lines replaced outside my house as a means to rule as much out as possible and I'll be asking them to do the same this time.

Thanks,

Danny
 
Last edited:
This might not help you today but it is a move in the right direction. Google is providing some support to have an open platform to gauge various measurement tools ...

http://www.measurementlab.net/

You will definitely want to check it out (I'd suggest anyone who loves this stuff). They are attempting (and will succeed) in detecting any throttling your ISP might be doing which might be of help for you Danny, at least to be able to remove it as a possibility. I'll post tonight what each test shows for mine.
 
Ran this test: Network Path and Application Diagnosis (NPAD) (Some of the other tests are not working do to congestion and the NPAD took a while, busy place.

Test conditions

Target: dynamic-65-161-140-113.tvscable.com (65.161.140.113) [?]
Logfile base name: dynamic-65-161-140-113.tvscable.com:2009-02-02-23:28:28 [?]
This report is based on a 10 Mb/s target application data rate [?]
This report is based on a 87 ms Round-Trip-Time (RTT) to the target application [?]
The Round Trip Time for this path section is 87.000000 ms.
The Maximum Segment Size for this path section is 1460 Bytes. [?]
Target host TCP configuration test: Fail! [?]
Warning: TCP connection is not using RFC1323 timestamps. [?]
Critical Failure: Received window scale is 0, it should be 2. [?]
Diagnosis: The target (client) is not properly configured. [?]
> See TCP tuning instructions at http://www.psc.edu/networking/projects/tcptune/ [?]
Path measurements [?]
The data connection was terminated before collecting sufficient data to measure the path.
Tester validation: Pass! [?]
No internal tester problems were detected.
Tester version: $Id: pathdiag.py,v 1.43 2009/01/22 21:51:35 mathis Exp $
 
Last edited:
You must log in or register to reply here.
Back
Top