That is why you don't use ping as your only diagnostic tool. Run traces to the actual IP your client uses (can get that from resmon or netstat while logged fully into the game). Forward those traces to your ISP's Tier3 techs so that they can investigate the specific route you are assigned for just this game's connection. When you call in and they look at your modem and such, they are just looking at your local segment and confirming connectivity to your localized nodes. You can have anywhere from 2 to 63 potential points of failure between your system and SE's servers. They need to see your entire path to pinpoint exactly which hops are having trouble. Typically it is either ingress or congestion past your local tap or issues with peering exchanges in your route.
In other words, it's more often a problem in another state or country between your local connection and SE's servers that only your ISP or SE's ISP has the resources and enforceable contracts to get it addressed. But, in order to get them off their duffs and actually do something, you need to push for escalation to Tier3 (not the teir1/2 departments you deal with closer to home) and get them useful details demonstrating the particular characteristics of this game's specific connection to the Canadian IP's that start with 199. The easiest way to do this is to submit a simple report like a tracert.
Notice that 2nd hop in my current trace. This is the last piece of the puzzle that TWC has been trying to address for us in our area. We've been working with them about thier peering issues for quite some time now, and have been switching up our routes about every 2-3 weeks. I've constantly bounce back and forth amongst Level3, TATA, and Congent for the routing partner that gets us into and across Canada. It will be good for a couple weeks, then get congested and they switch us to another partner. That is being managed by Time Warner Cable, not SE nor their ISP Ormuco... it's my TWC Teir3/4 people doing this for me.Code:C:\Windows\System32>tracert 199.91.189.25 Tracing route to 199.91.189.25 over a maximum of 30 hops 1 <1 ms <1 ms <1 ms LPTSRV [10.10.100.1] 2 91 ms 19 ms 19 ms cpe-066-026-112-001.sc.res.rr.com [66.26.112.1] 3 33 ms 31 ms 18 ms cpe-024-031-198-009.sc.res.rr.com [24.31.198.9] 4 23 ms 23 ms 24 ms 24.93.64.134 5 29 ms 27 ms 27 ms bu-ether34.atlngamq46w-bcr00.tbone.rr.com [107.14.19.48] 6 26 ms 25 ms 24 ms 107.14.19.99 7 28 ms 24 ms 36 ms te0-0-0-10.ccr21.atl02.atlas.cogentco.com [154.54.12.109] 8 26 ms 28 ms 28 ms be2050.ccr41.atl01.atlas.cogentco.com [154.54.0.165] 9 36 ms 37 ms 38 ms be2168.ccr21.dca01.atlas.cogentco.com [154.54.31.94] 10 43 ms 44 ms 44 ms be2148.ccr21.jfk02.atlas.cogentco.com [154.54.31.118] 11 48 ms 47 ms 47 ms be2106.ccr21.alb02.atlas.cogentco.com [154.54.3.50] 12 69 ms 70 ms 70 ms be2088.ccr21.ymq02.atlas.cogentco.com [154.54.43.17] 13 62 ms 64 ms 63 ms 38.122.42.34 14 58 ms 47 ms 47 ms 10.2.2.1 15 48 ms 47 ms 47 ms 192.34.76.2 16 48 ms 48 ms 47 ms 199.91.189.234 17 49 ms 47 ms 48 ms 199.91.189.25 Trace complete.
The lag has gone from a typical ~120ms down to staying under ~70ms as a result of it, and for the most part I have no troublesome lag spikes until that gateway at that second hop goes haywire. That is a hop to Hilton Head, SC. We are in Florence... well over 100 miles north of there. This is a temporary routing change while they are trying to address issues with the gateway that serves Florence residential service. Our local gateway was severely overloaded and frequently breaking the 200ms response time. During primetime it could break 3 seconds and time out on us. This was wreaking havoc on gaming.
Again... this is the result of bringing in my ISP's Tier3 techs and providing them relevant data about my specific connection to the SE server I play one (more specifically, tracerts). They sent techs out to inspect my amp, tap, cables, modem... took signal and log dumps, made sure everything was good here. Sent bucket trucks up and down the street to address ingress they found upstream. Fixed problems preventing the CMTS from bonding more than 4 channels--all in an effort to thin out the noise and congestion that was found locally. But the problem STILL persisted, so they sent it further up the chain to try to address it with their peering partners. They keep switching us to different Tier1 ISP's (Level3, TATA, Cogent) trying to find the optimal exchange for us. This last one appears to be an attempt at a new peering agreement with close ties to Ormuco (SE's ISP). It is a route managed in part by PSInet, who has peering agreements with Ormuco. Since this path was established, I have started seeing response time stabilize under 70ms for me (provided my gateway isn't getting overloaded, but even then it is under 100ms typically).
It's the result of identifying the local and regional issues cropping up in route, and getting the right people to investigate/address the problems that were found. And it wasn't SE... but the ISP's involved in getting me to the servers in Montreal. To further illustrate how this is a regional issue between us, I will paste in some connectivity maps that refresh periodically throughout the day for several services that can be found at http://downdetector.com/companies. They track reporting feeds for various services and even some ISP's, and plot the reporting on these maps. They also log the stats and posts for some of them on their site as well. These may seem familiar to some who have been following this, as they have been posted in other threads on the issue.
These snapshots update periodically so may change as the thread is refreshed. They are based on source data from here:
http://downdetector.com/companies
The service specific source pages are linked below each image.
TWC map:
http://downdetector.com/status/time-warner-cable
AT&T map:
http://downdetector.com/status/att
Netflix map:
http://downdetector.com/status/netflix
PSN map:
http://downdetector.com/status/playstation-network
XBL map:
http://downdetector.com/status/xbox-live
Notice how the problems seem to clump up in the same regions across different services? That is because there are issues with the exchanges for the Tier1 providers. Notice specifically the clusterf*ck that is the north-east--up around NY and MA are the primary entry points to Canada for the majority of the US. The big 3 providers we use to get in there have a combined total of 7 exchanges up there for getting into Ontario and Quebec, and only 2 above Seattle, Washington for getting into British Columbia. So, when things are a mess in the north-east of the US, a LOT of us suffer getting into/across Canada. The same can happen for the EU as well, because a lot of them have to come in through Nova Scotia. Then our poor Aussie friends are often stuck coming around Southern California and have to either shoot up around Seattle/Vancouver and come across Canada through Toronto or get shifted across the US to come through the North East corridor with the rest of us.
The NA infrastructure is just a flat out mess in general. Both Level3 and TATA have been in a major pissing contest with our last mile providers (AT&T, Verizon, Comcast, TWC, etc.) to update their peering agreements to compensate for the massive increase in usage. They've even filed formal complaints with the commission to try to force them to operate under fair practices, but have not been able to make any reasonable progress. Everyone is streaming more and more (and cutting the cable/satellite cords), among other things like shopping and social media, putting greater and greater strain on the backbones that connect all the separate networks. But our ISP's have been reluctant to pony up the resources to widen the pipes to thin out the massive port congestion at the exchanges between their networks and those backbones.
If you take some time to track this stuff in general, you can see the ebb and flow of this problem all over the place. This is a handy app for looking at various industries and regions in real time. They have tools for mapping latency, threat levels, and usage by industry... all consolidated in one app with drop boxes and tabs to switch between the different reports.
http://www.akamai.com/html/technolog...try/index.html
Basically, at specific times of day, you may see the same areas line up with problems across multiple services because it is due to regional problems amongst the ISP's... it isn't JUST SE in play here. If so, then it would be affecting the vast majority of players all at once--you would see entire servers/clusters go down and not just groups of users from specific servers. Not to say the SE doesn't have internal stability issues that they need to address, but it is more often people getting routed along problematic paths to the server that are getting affected together (ie, we've seen everyone using level3 get hammered at once, while Cogent users were fine). It is more because we have a systemic problem with our infrastructure that affects critical regions all at once. When the transit is down, it affects everyone that is getting pushed through that corridor. That is why sometimes you see multiple games/services affected in kind for some and not for others---there is a bigger regional transit problem with our providers and their partners.
Edit:
To further support this, here is an example of the issue in action with my connection. During the final cut scene for my 50 BRD fight tonight, I got booted and suffered the same issues trying to log back in (connection lost, character already logged in, connection to lobby lost, failed to connect to lobby, etc.), so I pulled up a DOS window and started running traces to my lobby and game server. The portion of my path where I slingshot DC and Chicago (NSA scan and such) was stalling out. As soon as it cleared, I logged straight into the game...the stalling and disconnect was happening between TWC and Cogentco--hadn't even gotten to Ormuco, much less SE. There was nothing SE could do to remedy this until Cogent fixed it or TWC routed me away from the bad segments. Unfortunately I had to do that annoying fight again, but was able to get right back into the game as soon as the problem corrected itself in my route. Note that I've been logged in all day non-stop since shortly after initially posting here... roughly 12 hours straight (took breaks, queuing for duties and such--but short of this 10 minute hiccup, my character stayed logged into the game.)
Code:Microsoft Windows [Version 6.2.9200] (c) 2012 Microsoft Corporation. All rights reserved. C:\Windows\System32>tracert 199.91.189.74 Tracing route to 199.91.189.74 over a maximum of 30 hops 1 <1 ms <1 ms <1 ms LPTSRV [10.10.100.1] 2 49 ms 29 ms 40 ms cpe-066-026-112-001.sc.res.rr.com [66.26.112.1] 3 19 ms 31 ms 18 ms cpe-024-031-198-009.sc.res.rr.com [24.31.198.9] 4 22 ms 23 ms 23 ms 24.93.64.134 5 44 ms 27 ms 43 ms bu-ether44.atlngamq46w-bcr00.tbone.rr.com [107.14.19.46] 6 29 ms 25 ms 25 ms ae-1-0.pr0.atl20.tbone.rr.com [66.109.6.177] 7 27 ms 41 ms 25 ms te0-0-0-10.ccr21.atl02.atlas.cogentco.com [154.54.12.109] 8 27 ms 25 ms 45 ms be2051.ccr42.atl01.atlas.cogentco.com [154.54.0.161] 9 36 ms 51 ms 59 ms be2171.mpd22.dca01.atlas.cogentco.com [154.54.31.110] 10 43 ms 54 ms 44 ms be2151.mpd22.jfk02.atlas.cogentco.com [154.54.40.74] 11 48 ms 48 ms 48 ms be2109.ccr21.alb02.atlas.cogentco.com [154.54.3.138] 12 70 ms 73 ms 66 ms be2088.ccr21.ymq02.atlas.cogentco.com [154.54.43.17] 13 88 ms 70 ms 77 ms 38.122.42.34 14 50 ms 47 ms 63 ms 10.2.2.1 15 48 ms 57 ms 83 ms 192.34.76.2 16 50 ms 47 ms 48 ms 199.91.189.234 17 73 ms 50 ms 47 ms 199.91.189.74 Trace complete. C:\Windows\System32>tracert -d 199.91.189.25 Tracing route to 199.91.189.25 over a maximum of 30 hops 1 <1 ms <1 ms <1 ms 10.10.100.1 2 44 ms 36 ms 38 ms 66.26.112.1 3 17 ms 18 ms 15 ms 24.31.198.9 4 37 ms 23 ms 23 ms 24.93.64.134 5 27 ms 30 ms 28 ms 107.14.19.48 6 25 ms 24 ms 25 ms 107.14.19.99 7 25 ms 28 ms 25 ms 154.54.12.109 8 28 ms 32 ms 27 ms 154.54.0.165 9 * * * Request timed out. 10 * * * Request timed out. 11 * ^C C:\Windows\System32>tracertd 199.91.189.25 'tracertd' is not recognized as an internal or external command, operable program or batch file. C:\Windows\System32>tracert 199.91.189.25 Tracing route to 199.91.189.25 over a maximum of 30 hops 1 <1 ms <1 ms <1 ms LPTSRV [10.10.100.1] 2 56 ms 34 ms 38 ms cpe-066-026-112-001.sc.res.rr.com [66.26.112.1] 3 18 ms 19 ms 18 ms cpe-024-031-198-009.sc.res.rr.com [24.31.198.9] 4 25 ms 27 ms 24 ms 24.93.64.134 5 25 ms 27 ms 31 ms bu-ether34.atlngamq46w-bcr00.tbone.rr.com [107.14.19.48] 6 30 ms 25 ms 25 ms 107.14.19.99 7 25 ms 25 ms 25 ms te0-0-0-10.ccr21.atl02.atlas.cogentco.com [154.54.12.109] 8 42 ms 32 ms 28 ms be2050.ccr41.atl01.atlas.cogentco.com [154.54.0.165] 9 * * * Request timed out. 10 * * * Request timed out. 11 * * * Request timed out. 12 * * * Request timed out. 13 68 ms 84 ms 70 ms 38.122.42.34 14 48 ms 49 ms 62 ms 10.2.2.1 15 51 ms 47 ms 48 ms 192.34.76.2 16 47 ms 47 ms 47 ms 199.91.189.234 17 49 ms 50 ms 47 ms 199.91.189.25 Trace complete. C:\Windows\System32>tracert 199.91.189.25 Tracing route to 199.91.189.25 over a maximum of 30 hops 1 <1 ms <1 ms <1 ms LPTSRV [10.10.100.1] 2 870 ms 35 ms 68 ms cpe-066-026-112-001.sc.res.rr.com [66.26.112.1] 3 16 ms 18 ms 18 ms cpe-024-031-198-009.sc.res.rr.com [24.31.198.9] 4 24 ms 23 ms 23 ms 24.93.64.134 5 29 ms 27 ms 27 ms bu-ether34.atlngamq46w-bcr00.tbone.rr.com [107.14.19.48] 6 27 ms 34 ms 25 ms 107.14.19.99 7 27 ms 25 ms 25 ms te0-0-0-10.ccr21.atl02.atlas.cogentco.com [154.54.12.109] 8 27 ms 28 ms 28 ms be2050.ccr41.atl01.atlas.cogentco.com [154.54.0.165] 9 37 ms 47 ms 38 ms be2168.ccr21.dca01.atlas.cogentco.com [154.54.31.94] 10 43 ms 44 ms 44 ms be2148.ccr21.jfk02.atlas.cogentco.com [154.54.31.118] 11 49 ms 46 ms 47 ms be2106.ccr21.alb02.atlas.cogentco.com [154.54.3.50] 12 69 ms 70 ms 70 ms be2088.ccr21.ymq02.atlas.cogentco.com [154.54.43.17] 13 73 ms 75 ms 75 ms 38.122.42.34 14 50 ms 48 ms 50 ms 10.2.2.1 15 51 ms 47 ms 47 ms 192.34.76.2 16 49 ms 47 ms 47 ms 199.91.189.234 17 48 ms 47 ms 47 ms 199.91.189.25 Trace complete. C:\Windows\System32>







Reply With Quote







