how-to block ads
|reply to Shina |
Re: [AZ] Huge latency and packet loss issues in the Valley Area
I to have Cox, and live in the Valley. I have same issues that started Jan 9th Connecting to Blizzard's Chicago Data server. My ping plotter results look nearly identical to yours so I won't bother posting them. I have spoken to 4people, and had someone come out to my house, and all they say is "your levels look good"
I also remember the issues a month ago with cognet servers, and am baffled that they are using them again.... I
|reply to Shina |
So looking into this further I did a traceroute to another server and see that my second hop seems to be where the delay is happening.
Tracing route to 61.d3.5446.static.theplanet.com [188.8.131.52]
over a maximum of 30 hops:
1 7 ms 1 ms 1 ms xx.xx.xx.xx
2 1117 ms 1133 ms * 10.132.160.1
3 896 ms 868 ms 715 ms ip68-2-7-81.ph.ph.cox.net [184.108.40.206]
4 785 ms 789 ms 831 ms chndcorc01-te-0-15-0-0.ph.ph.cox.net [70.169.72.
5 * 977 ms 1027 ms 220.127.116.11
6 1320 ms 1156 ms 1189 ms 18.104.22.168
7 1084 ms 1123 ms 1104 ms xe-1-0-0.bbr01.eq01.pal01.networklayer.com [50.9
8 1137 ms 1179 ms 1215 ms ae3.bbr02.eq01.sjc02.networklayer.com [173.192.1
9 991 ms 991 ms 899 ms ae0.bbr02.cs01.lax01.networklayer.com [173.192.1
10 837 ms 847 ms 524 ms ae7.bbr01.cs01.lax01.networklayer.com [173.192.1
11 462 ms 873 ms 877 ms ae19.bbr01.eq01.dal03.networklayer.com [173.192.
12 972 ms 1007 ms 1085 ms po31.dsr02.dllstx3.networklayer.com [173.192.18.
13 1172 ms 1237 ms 1296 ms po32.dsr02.dllstx5.networklayer.com [22.214.171.124
14 827 ms 825 ms 854 ms 61.d3.5446.static.theplanet.com [126.96.36.199]
Now if I trace back from that server to the first internet routable Cox address, 188.8.131.52, the latencey is non existent, comparitively speaking.
Tracing route to 184.108.40.206 [220.127.116.11]...
hop rtt rtt rtt ip address fully qualified domain name
1 1 1 1 18.104.22.168
2 0 0 0 22.214.171.124
3 0 0 0 126.96.36.199
4 0 0 0 188.8.131.52
5 0 0 0 184.108.40.206
6 50 50 50 220.127.116.11
7 59 48 59 18.104.22.168
8 43 42 43 22.214.171.124
9 52 52 52 126.96.36.199
10 54 54 54 188.8.131.52
|reply to Joby |
It took a good hour to get to one, but I have a history of legitimate internet issues and have always made a point of calling as soon and as often as possible until they are resolved because they directly impact my ability to make a living.
Chances are because this is an issue that they've had before, and fixed, and because I had extensive documentation of the nature of the problem (meaning the "reset your router and modem" step could be skipped), they put me through to a higher-level tech.
I'd like to emphasise that the tech I spoke to, whilst shedding some light on a probable cause for the change that triggered the issues, did not know how to fix it, nor did he know who to refer me to that could. My internet (as well as that of other people in the area) is not any better at present at all.
|reply to Shina |
how did you get to talk to a Tier II technician? I am having this same issue sadly and would like to call to vent/report as well.
|reply to Shina |
Posting this for the benefit of anyone else that might have had this issue (it's rather specific as the signal would have to be routed through Cognet servers but for those who have it, it's devastating):
Spoke for two hours today on the phone with Cox "Tier II" technicians about the issue. Was informed that the cause of the swap back could be due to some sort of software update in the area that inadvertently rolled back the pathing specification, because the change that fixed it wasn't "saved" permanently and thus could be overwritten. He didn't claim with authority that this is what did happen, but implied it was a very possible cause. That said, none of the technicians I was able to reach knew how to switch the pathing back to something that works, knew of no one who knew how to do this, and could not find any notes on file about the incident from a month ago.
And yet, when this issue occured a month ago, someone at Cox was indeed able to get the routing switched to resolve the issues.
I basically took the same steps on the phone as I did last time when a resolution was attained. I have no idea what to do and am at my wit's end with this problem ; if anyone has an idea of how to proceed I would greatly appreciate the advice.
|reply to Shina |
I have been experiencing this for everything I do, not just gaming. I have been through the whole power cycle the cable modem, etc bit.
I even thought that maybe my wireless connection was the issue, but even connecting up with ethernet doesn't change the issue. Even the speed tests via Cox's website are showing a huge amount of latency.
Just today, I've noted very severe packet loss issues in my conncetion, resulting in unacceptable (> 1000ms) latency in any sort of online gaming. This issue is not limited to me or my own connection ; all gamers that I know connecting to the same server who live in the Valley area, and those who live in the Valley only, are experiencing the same night-and-day decline in performance.
I believe I have identified the source of the sudden problems, but a bit of background is needed. About a month ago, persistent issues arose from Cox's use of Cognet-hosted servers in order to route my signal to, amongst other places, the World of Warcraft server to which I connect in Chicago. Long story short, those servers, for whatever reason, are associated with poor performance and a lot of latency. After multiple calls, Cox rerouted the path to this server through hops that did not appear to be Cognet-hosted. This change immediately cleared up the persistent latency issues for not only myself but also for several other people living in the Valley area who had been reporting similar issues.
Just today (9 January), my tracerts revealed that Cox has swapped back to Cognet servers. The extreme latency and packet loss have immediately returned with this change, for both myself and other gamers that I have spoken to who live in the Valley. Only the inital and terminal hops on the Cognet network are the same IP's as they were a month ago. Unfortunately, the first hop, 184.108.40.206, happens to be the server that was known to be causing issues the last time around.
I know that there are Cox technicians who browse these boards, and I'd like to know if possible why Cox swapped back to the terrible Cognet servers in the first place. Additionally, I'd like this change to be reverted, because at present, the poor connection precludes any sort of actual gaming. There are no suitable ISP alternatives in my area.
The following image displays the acceptable trace route at top, taken from a PingPlotter sample recorded yesterday evening, and the Cognet trace route at bottom from tonight. I have chosen trace routes to my Chicago-based World of Warcraft server because I know my signal is routed through the Cognet network to get there. I am experiencing no issues with connecting to servers that do not entail routing my signal through said network.
If a comparison would be needed, here is an old traceroute from 4 December when similar lag issues were occuring prior to my swap off the Cognet servers. Cognet hops that I have used previously are bolded.
1 NELTHARION [192.168.1.1]
4 chndcorc01-te-0-4-0-2.ph.ph.cox.net [220.127.116.11]
5 chnddsrj01-ae2.0.rd.ph.cox.net [18.104.22.168]
6 langbprj02-ae2.rd.la.cox.net [22.214.171.124]
7 te7-5.ccr02.lax05.atlas.cogentco.com [126.96.36.199]
8 te0-1-0-1.ccr22.lax01.atlas.cogentco.com [188.8.131.52]
9 te0-3-0-6.ccr22.iah01.atlas.cogentco.com [184.108.40.206]
10 te0-4-0-6.ccr22.dfw01.atlas.cogentco.com [220.127.116.11]
11 te0-2-0-6.ccr22.mci01.atlas.cogentco.com [18.104.22.168]
12 te0-5-0-4.ccr22.ord01.atlas.cogentco.com [22.214.171.124]
13 te0-5-0-3.ccr22.ord03.atlas.cogentco.com [126.96.36.199]
14 att.ord03.atlas.cogentco.com [188.8.131.52]
15 cr1.cgcil.ip.att.net [184.108.40.206]
16 gar2.clboh.ip.att.net [220.127.116.11]
Note that even in the best circumstances, the Cognet route would have an extra hop, resulting in unneccessary latency. The top image corresponds with a ping of about 77ms to the server, whereas the bottom one results in a ping of 900-1200ms. The apparent packet loss after 18.104.22.168 is the result of pings past that hop being blocked and is not indicative of a problem.
I also find it interesting that the Cox server 22.214.171.124 shows consistent 40-50 % packet loss with PingPlotter, regardless of my actual connection performance. I have never gotten less than 40 % packet loss at this address at any time of day or on any connection. This particular hop does not appear to affect my connection quality at all, but as I have never recorded any instance where there was not packet loss at this address, I have little basis for comparison.
For reference for any Cox tech that may come accross this thread, I am presently on the Ultimate package. I can provide further details if it will help bring about a resolution of this problem.