because some mod thought they be funny to move my previous thread to resolved..without being resolved
http://forum.square-enix.com/ffxiv/t...57#post3206057
I keep getting the D/C symbol and eventual 90k about 3-4 times an hour. And I can't figure out how to fix my issue.
I have tried:
2 different VPNs, 2 different ISPs, 2 different versions of windows, 2 different NIC cards with different drivers. I have my port triggers and virtual servers all set up. I have completely disabled firwall on PC and router and even attmpted DMZ..no fix to this issue.
Keep getting D/C symbol
Printable View
-
08-03-2015, 01:20 AMRydisKeep getting D/C symbol
-
08-03-2015, 04:09 AMRaist
Sounded like intermittent delays in your packets...may see intermittent spikes well over 50% along your route or intermittent timeouts if you run a series of tracerts to the server you use (can get the IP from Resource Monitor (resmon from search/run) once you are fully logged into the game).
This sometimes is a side effect of malware--back door transmissions, proxy locks, etc. can do all kinds of weird things. If you haven't done a thorough scan yet, may want to head to malwarebytes.com and try their free scanner. Usually does a pretty good job of catching stuff--many of the big names in security refer people to their site for assistance with the harder problems.
Could also be something locally consuming bandwidth to the point that it is intermittently delaying packet delivery--especially if on cable. Not sure how of the particulars on DSL/FiOs like how big the bursts are and such, but typically your data doesn't flow in a constant stream but is sent in a sort of store-and-forward routine. Modem gets data, requests a time slice to transmit, then burst it at high speed. Your bandwidth is gated basically by metering out the time slices. For example, a 15Mb cable plan may burst data in anywhere up to 5Mbit chunks at speeds higher than 16Mbit, but delays the bursts enough to maintain an average of 14-17Mbit transfer rate over time--but if you were to take a sort of "freeze-frame" image of one of the transfers it may actually be at a rate comparable to a 20-30 mbit transfer if it wasn't restricted to the smaller buffer size.
So if someone is streaming video or something on your line, it might be consuming upwards of 3Mb/sec or so and is interfering with the routine. Note that this can happen upstream as well if the neighborhood is saturating the nodes as well. And if there is a signaling issue that has degraded performance along the route, it becomes easier to cap out the usable bandwidth on that failing segment.
Looking at isolated segments of the path is likely to miss something (typically what happens when you start dealing with your ISP--they look at local segments, MAYBE a little further upstream--but rarely at the entire route). A proper analysis needs to be done over time across the run of your path to the servers to better narrow down potential problems. Then, if something is found, your ISP can either try to work with whoever manages the questionable segment--or work to route you away from it. -
08-03-2015, 07:34 AMRydisive ran trace routes with WTFast and consulted with them, and forwarded that info along to my ISP, both who say there is nothing wrong. And if that was the case, changing ISPs should of solved it no? I have tried two different ISPs & USB tethering from my phone.Quote:
Originally Posted by Raist
http://i.imgur.com/xFZHoz0.jpg
I understand there is a particular hop there that drops, but multiple people including ISP tell me it isnt an issue because all hops after it are perfect. 2nd hop 100% times out because it doesn't allow echos.
my connection, I live alone and I have wifi disabled. I can assure you nothing else is using my bandwidth
http://i.imgur.com/cvb3bAw.png
so knowing that, and ISP already telling me there are no issues, and same issue over 3 different possibles routes..what would be the next course of action?
Edit: Wanted to also add, this is the only game I have any issues whatsoever with. None with any other game I play/played, including LoL, Tera, Rift, Ark, Guild Wars 2, Wild Star. -
08-03-2015, 09:16 AMRaist
Neither of those tests is to the ffxiv servers. You need to be looking at your specific path to Ormuco's 199.91.189.0/24 subnet that the game's servers are hosted on in Montreal Canada. And your bandwidth is not an issue with this game, generally speaking. About the only time you need more than a DSL-Lite level of bandwidth is for patching, heavily congested areas, and initial loading. And even then, you would be more then fine with a 15Mb bandwidth plan. What is of greater concern is latency---it needs to be consistent, and it needs to be low.
Any test to anywhere other than the network hosting the game is only going to show you issues on your localized networks at best. Looks like you are in or otherwise coming through the Florida area---you will NOT have a direct line to Montreal from there. You will be handed off to a third party network. Typically, we see a lot of issues either around that hand off, or between there and Ormuco (SE's ISP in Montreal). So the route taken specifically for your game client is what needs to be looked at.
Oh, and even though that trace is not to the game service in Montreal...it does show a lot of jitter in a few spots, which can cause problems. Even in your more local segments you have a swing just over 3x your average response times. Further down, you see the trend continue to 3x and 4x the average time (not to mention it is an even bigger jump from the best times). And that TWC hop with the intermittent dropped packets is a bad sign. Even though we are talking forwarding in the route, it is a clear indication that that hop has reached a high enough utilization point that it is ignoring lower priority traffic trying to preserve throughput. In other words--that hop is trying to prevent congestive failure---which is not good.
The game relies on timely, orderly delivery of the packets. If packets get too far out of order/delayed you're risking a retransmit which can get progressively worse when there are lag spikes kicking in. Overly congested nodes present a problem for this game. The packets aren't encrypted (like with a VPN), and aren't otherwise flagged to put them on a higher priority list. This makes them vulnerable to getting delayed during periods of high congestion....which is the problem more often than not. Since they cleaned up my routing earlier this year, EVERY time there has been any instability that was not announced to be an issue server-side, it was because either my local devices were flaking out (modem or router), or there was an overly congested segment along my route--which Time Warner would get me routed around and service would improve. -
08-03-2015, 09:24 AMRydis
so your saying its my ISP..and not really anything I can do about it?
So why does the same issue present over 3 different ISPs? TWC, Verizon & ATT 4g.
Or is the game just not playable in my location??
I showed WTF traceroute because it shows the drop on the hop, where as a normal tracert doesn't, but here you go. The 2nd image was just to show..bandwidth on my end really wasn't an issue.
http://i.imgur.com/Yx9vNIy.png
I must say today wasn't an issue day either, as I didn't encounter the issue. Usually late Saturdays and Sundays I dont. but I got the issue earlier in the day on both days. -
08-03-2015, 09:39 AMRaist
It looks to be the same as most everyone else that has taken a closer look at their route. Issues persist in the way you are being routed. Changing ISP's doesn't automatically prevent you from getting sent to the same exchange point--nor even the same routing partner...it could just send you through a different exchange point but you wind up with the same ISP that is having problems.
In the pic you posted of a Windows Tracert, you have signs of trouble right there in Tampa, before you get handed off into Level3--which is also showing signs of trouble. The later spike could be due to the earlier spike though...but with Level3's history, I wouldn't be too quick to dismiss them either.
We frequently see Level3 having issues with various ISP's---more frequently with Verizon in the north east, Texas, and a few other places...but other ISP's have had issues with them as well. Every time I get put on their routes, they usually last about a week before we have to get it switched back to either TATA or Cogent.
And yes... it is an issue your ISP can and SHOULD address for you. If they can't/aren't willing to work things out with their peering partner (in that case Level3) to clean things up, then they should be able to arrange for you to use someone else for the peering. Mine gets changed often...was changed just before this weekend in fact--TATA was having issues in the Ashburn/DC area and TWC flipped me to Cogent and I'm going through Atlanta now. As a result, I no longer slingshot Toronto on the way to Montreal either--knocking two hops off my route.
Edit: Just did a quick lookup on your gateway...Bright House Networks. Close ties to Time Warner. They also peer with TWC, Qwest, XO, and Verizon. Not the greatest options...but through some of them they should be able to get to either TATA or Cogent. Perhaps if they took advantage of their peering with Time Warner it may pan out better for you in the long run, even though it may mean a few more hops (could go BHN -> TWC/RR -> TATA -> Ormuco). It will likely involve pushing for someone higher up the chain to escalate the issue to Tier3/Engineering though. You may find you fair better going through the online contacts than the phone. DSL Reports has forums set up with more direct access to the higher support tiers that may help you move things along. Here is a link to their Bright House forum:
https://www.dslreports.com/forum/bhousedirect -
08-03-2015, 09:42 AMRydis
this is quite unfortunate news..as doesn't look like Ill be able to play, as ISP has already stated few times..not them..and they can't do anything.
appreciate your help. -
08-03-2015, 10:08 AMRaist
no.. they can help. They just aren't willing to...perhaps you are still stuck in Tier1 or Tier2 support level. I worked directly with Time Warner's Tier3 people...and they have done WONDERS with cleaning things up. Here is a snapshot from tonight:
Believe it or not... that is actually kind of sluggish for a Cogent routing. Don't get me wrong---that is still very solid from here in South Carolina. It's just that I often see the responses around 60 or better at the end. TATA is usually on the order of 70-80, with Level3 pushing up near the 90's (until it hits 150-ish and have to get it changed again).Code:Tracing route to neolobby02.ffxiv.com [199.91.189.74]
over a maximum of 30 hops:
1 <1 ms <1 ms 1 ms LPTSRV [10.10.100.1]
2 27 ms 18 ms 28 ms cpe-75-176-160-1.sc.res.rr.com [75.176.160.1]
3 29 ms 24 ms 33 ms cpe-024-031-198-009.sc.res.rr.com [24.31.198.9]
4 20 ms 20 ms 18 ms 24.31.196.212
5 24 ms 25 ms 25 ms be33.chrcnctr01r.southeast.rr.com [24.93.64.182]
6 30 ms 26 ms 31 ms bu-ether14.atlngamq46w-bcr00.tbone.rr.com [66.109.6.82]
7 24 ms 25 ms 40 ms 0.ae2.pr0.atl20.tbone.rr.com [107.14.19.11]
8 26 ms 26 ms 27 ms te0-0-0-10.ccr21.atl02.atlas.cogentco.com [154.54.12.109]
9 27 ms 25 ms 29 ms be2050.ccr41.atl01.atlas.cogentco.com [154.54.0.165]
10 35 ms 34 ms 33 ms be2168.ccr41.dca01.atlas.cogentco.com [154.54.31.94]
11 42 ms 39 ms 43 ms be2148.ccr41.jfk02.atlas.cogentco.com [154.54.31.118]
12 63 ms 60 ms 73 ms be2106.ccr21.alb02.atlas.cogentco.com [154.54.3.50]
13 52 ms 49 ms 51 ms be2088.ccr21.ymq02.atlas.cogentco.com [154.54.43.17]
14 65 ms 68 ms 68 ms 38.122.42.34
15 65 ms 64 ms 64 ms 192.34.76.10
16 65 ms 67 ms 63 ms 199.91.189.242
17 74 ms 68 ms 74 ms 199.91.189.74
Trace complete.
When I started with them on my issues, we had lag spikes breaking a full second (1000ms), intermittent timeouts, random modem rebooting... you name it. They started at one end and worked their way out. Modem, the DMARC out back, up on the pole.... got everything cleaned up locally and then went to the CMTS (which was bad---no longer use a gateway here in Florence because of it), and on up the route. They routinely change my peering trying to stay ahead of the congestion. It IS manageable to some extent by your ISP---just have to find someone willing to work on it. -
08-03-2015, 10:11 AMRydis
Im currently at level 2 support without any responses back. Sending again.
Hopefully can get the help you got. -
08-04-2015, 07:06 AMRydis
http://i.imgur.com/m8l0JAB.jpg
so this is todays, is a lot better than yesterday. Oddly, Im having this issue today, and didn't yesterday. Same route as yesterday, better results, have issue today, but not yesterday...
ill check out the link, didn't see before.
But like I said..todays trace looks really good..and im having this issue..dont know if that can convince them..
Edit: Found this and ran it. Posted on that website. Hopefully will help.
http://i.imgur.com/YefR6Vy.png -
08-04-2015, 12:30 PMRydisis basically what I was toldQuote:
Originally Posted by Raist
"The route you showed actually had no loss. That is called ICMP deprioritization and is non-impactful and completely normal. It simply means the router you were pinging was too busy doing real things to be bothered with your pings. Based on what I see at the moment there is nothing wrong on our end. If you have more I'm more than happy to look at it." -
08-09-2015, 12:33 AMRydis
i have not spoken with ISP again and SE again, and replaced the router. I have done every possible solution on my end and still have this issue.
Both ISP and SE says..they have 0 issues -
08-09-2015, 01:13 AMRaistOh wow...you do realize they just admitted there is a problem with over-utilization, right?Quote:
Originally Posted by Rydis
They admitted that the load has ramped up to the point that it has to enforce prioritization rules. In other words it is intentionally ignoring/delaying/discarding what they consider lower priority traffic in order to preserve bandwidth for what they deem is higher priority traffic. Basically it is overloaded and they are throttling the traffic. If traffic was in the normal range (below 80%), there would be no need to enforce such rules.
Ties in quite well with some of the Level3 blog posts we've often linked to in these threads over the last year or so...especially the two I quoted from recently in one of the Verizon threads:
http://blog.level3.com/open-internet...tal-mea-culpa/
http://blog.level3.com/open-internet/not-neutrality/Quote:
So let’s look at what that means in one of those locations. The one Verizon picked in its diagram: Los Angeles. All of the Verizon FiOS customers in Southern California likely get some of their content through this interconnection location. It is in a single building. And boils down to a router Level 3 owns, a router Verizon owns and four 10Gbps Ethernet ports on each router. A small cable runs between each of those ports to connect them together. This diagram is far simpler than the Verizon diagram and shows exactly where the congestion exists.
http://blog.level3.com/wp-content/up...w-1024x351.jpg
Verizon has confirmed that everything between that router in their network and their subscribers is uncongested – in fact has plenty of capacity sitting there waiting to be used. Above, I confirmed exactly the same thing for the Level 3 network. So in fact, we could fix this congestion in about five minutes simply by connecting up more 10Gbps ports on those routers. Simple. Something we’ve been asking Verizon to do for many, many months, and something other providers regularly do in similar circumstances. But Verizon has refused. So Verizon, not Level 3 or Netflix, causes the congestion. Why is that? Maybe they can’t afford a new port card because they’ve run out – even though these cards are very cheap, just a few thousand dollars for each 10 Gbps card which could support 5,000 streams or more. If that’s the case, we’ll buy one for them. Maybe they can’t afford the small piece of cable between our two ports. If that’s the case, we’ll provide it. Heck, we’ll even install it.
Quote:
But it is now late September. So what has changed? Well, let us look at three large Local Exchange Carriers (LECs) in the United States. These LECs are telephone companies that built broadband networks on the back of monopoly-funded telephone infrastructure. Over the past six months, the utilization of each interconnection location between their networks and Level 3’s has changed as shown in the following diagram.
http://blog.level3.com/wp-content/up.../09/lec123.jpg
Each number shows utilization at one of the interconnection locations in various cities throughout the United States between Level 3 and the LECs. Utilization above 85% indicates the LEC is causing congestion in that city by refusing to add interconnection capacity
This shows a dramatic improvement for LEC1 and LEC3, but a continued degradation for LEC2. You might say that it’s good news overall. But if you value an open Internet underpinned by a dynamic competitive environment, you may have a different opinion.
And that’s because the reason the interconnect utilization between Level 3 and LEC1 and LEC3 improved is that these LECs forced Netflix to pay them to interconnect directly with them. And as Netflix CEO Reed Hastings has pointed out several times, Netflix didn’t do that because they were taking advantage of a highly competitive Internet marketplace. They did it because they had no choice: all third-party content that LEC broadband users want to see eventually has to go through LEC interconnection points. When the LEC tries to turn these interconnection points into Internet tollbooths there is no alternate path for the content to take to reach the consumers.
-
08-09-2015, 03:28 AMRydis
so what does that mean for me?
I did mention that fact to him and it said its just because traceroutes are not as important as other traffic and that the depriorization isn't effect my actual connection to the game. Hence they only de-prioritize ICMP requests and only them. -
08-09-2015, 05:24 AMRaist
It means there is a strong chance the node is indeed overly congested...which could be part of your instability--and something they can address. THAT is what the tracert is for...to help identify potential points of instability in the route. Without being able to see how consistently or inconsistently it manages traffic at that hop, we have no way to test that theory. Notice they are ONLY dropping ICMP at that one particular hop---it isn't a rule across all nodes, just that one spot. What makes that one hop so special?
Follow the link to that mea culpa blog post. The scenario is near identical to what you are describing--everything appears just fine on either end of the network, but somewhere along the path things are breaking down. In that scenario, there is one exchange point that is running 100% utilization on 4 of 4 port cards--meaning it is at full capacity and going into congestive failure (discarding packets). It could be easily remedied (or at least dramatically diminished) by adding one or more additional port cards. One 10Gbit port card would increase the bandwidth available by 25%, and have a profound impact on the congestion between the client and the content server--but Verizon was unwilling to do the upgrade.
What you are being told is all is good on their end, and all is good on SE's end---but there is one point in between them that you can't verify if that is true or not. You are left with taking their word for it that everything is fine at that point in the route. BUT... and it is a very big one at that---they admitted that the "router you were pinging was too busy" and was thus ignoring the ICMP ECHO request. That is a rule that is often enforced specifically to help stave off high levels of congestion. That rep basically just told you the node is indeed congested or at least is prone to frequently high enough utilization for it to be on full time. Would be interesting to see if it actually responds during off-peak times...if it does, then you have a clear indication that it is getting overloaded periodically and that needs to be addressed.
Try running a pathping instead of a tracert (it will take a while to run). At the very start of the process, it will give a list of the route's IP addresses. If you actually get an IP for that hop in that list, you might be able to ping it directly to see how it is behaving. The default results are for 4 pings. If it does in fact respond to normal pings, you can use the -n switch to tell it how many times to ping to see a larger sample, like this:
ping -n 25 199.91.189.74
That would ping the neo2lobby.ffxiv.com service 25 times. Note you can use either the DNS name or the IP address for that command.
A pathping report may also show signs of issues in forwarding as well. If it indeed demonstrates problems exist with that function of the routers along the route, then you have signs of smoke and they need to be checking for the fire.
Just for comparison's sake, here is my current tracert (they just changed me back to TATA again, so I'm going through Raleigh/Durham and Toronto again.. bleh). Notice how not ONE of my hops is set to ignore ICMP--because utilization has more or less been brought into check now:
That is more along the lines of what you should be seeing...barring them clamping down because of potential security issues (like they are experiencing DDoS attacks and such). Under NORMAL conditions though, there should be no reason to ignore ICMP ECHO---unless there are stability concerns at that point in the route. And they just told you this is the case...their reason was because the "router you were pinging was too busy".Code:Tracing route to neolobby02.ffxiv.com [199.91.189.74]
over a maximum of 30 hops:
1 1 ms 1 ms <1 ms LPTSRV [10.10.100.1]
2 32 ms 31 ms 38 ms cpe-75-176-160-1.sc.res.rr.com [75.176.160.1]
3 26 ms 22 ms 31 ms cpe-024-031-198-005.sc.res.rr.com [24.31.198.5]
4 13 ms 11 ms 13 ms clmasoutheastmyr-rtr2.sc.rr.com [24.31.196.210]
5 28 ms 26 ms 25 ms be33.drhmncev01r.southeast.rr.com [24.93.64.180]
6 35 ms 29 ms 34 ms bu-ether35.asbnva1611w-bcr00.tbone.rr.com [107.14.19.42]
7 32 ms 29 ms 32 ms 0.ae2.pr1.dca10.tbone.rr.com [107.14.17.204]
8 31 ms 31 ms 32 ms ix-17-0.tcore2.AEQ-Ashburn.as6453.net [216.6.87.149]
9 51 ms 54 ms 54 ms if-2-2.tcore1.AEQ-Ashburn.as6453.net [216.6.87.2]
10 52 ms 66 ms 55 ms 64.86.85.1
11 52 ms 52 ms 53 ms if-10-2.tcore1.TTT-Toronto.as6453.net [64.86.32.33]
12 54 ms 52 ms 53 ms if-9-9.tcore1.TNK-Toronto.as6453.net [64.86.33.25]
13 54 ms 53 ms 53 ms if-7-2.tcore1.W6C-Montreal.as6453.net [66.198.96.61]
14 54 ms 52 ms 55 ms 66.198.96.50
15 52 ms 54 ms 53 ms 192.34.76.2
16 54 ms 55 ms 54 ms 199.91.189.234
17 53 ms 52 ms 54 ms 199.91.189.74
Trace complete.
-
08-09-2015, 05:52 AMRydis
i can't because my 2nd hope never responds..it just stops there
-
08-09-2015, 06:09 AMRaist
At the head end? Then something odd may be going on indeed. If you have a combo router from them, you might be able to connect through your local gateway address (192.168.0.1, sometimes it may be 192.168.100.1) and pull up a utility section from there that will let you run traceroute and such that may reveal more information. Depends on how you are setup. Sometimes the user/pass are really simple like admin/password, admin/admin, user/password, etc. There may even be a FAQ out there telling you how to pull up your signal/event logs on their website that will provide you the address and login details.
If you can't get to a utilities section built into the router, the modem's connection/signal status pages and such may give you the primary gateway and/or CMTS addresses you can test against. You may indeed have some issues closer to home that they don't want you to see--and for good reason I guess. Because if you can show them there is a problem, they need to fix it.
Edit:
Try running this command from a command prompt to see if you get the list of IP's for the route:
The -n switch tells it not to try resolving the host names for the IP's, so it should be able to report just the IP addresses. If you want to see the host data on a particular IP, you may be able to get that from sites like myip.ms or arin.net.Code:pathping -n neolobby02.ffxiv.com
If using the -n switch fails to give the IP, then you can try looking up your real-world IP address through speedguide.net's TCP Analyzer and from there we may be able to dig a little bit into what may be going on once we know the subnet you are on (if you click the address on that page, you will get some info and tools you can use to do some testing--may need to set your router/firewall to respond to pings either globally or from their server). -
08-09-2015, 06:51 AMRydishas nothing to do with it. If pathping encounters a spot that doesn't allow it to receive the commands it ends it there. My ISP doesn't allow any echo type commands to its server at all, so every traceroute and such will always show it as *** and 100% fail. Pathping will always end here because it can't pass. its just how pathping worksQuote:
Originally Posted by Raist
Either way ISP wont do anything they said..so unfortunate I just can't play the game. -
08-09-2015, 07:13 AMRaist
That 2nd hop should be your gateway on their network. There should be a simple way to identify it. You should at least get the route list from pathping. At least I would in the past. Even though I would have starred events along the way, I could always get the list of IP addresses for the route so we had a road map and knew were to look for problems.
Perhaps there is something stronger clamping down access to that gateway (firewall or ACL)? Who knows... but without being able to test against it, you are in a bad pickle because you can't confirm that things are indeed good on their side of the equation. You can have signs of potential trouble show up down the route that are actually from something in your first 5 hops. -
08-09-2015, 08:15 AMRydis
just to show...
http://i.imgur.com/AFvs8Ze.png