-
Getting Fed Up With D/C
Can someone PLEASE tell me the steps to figure out why these dang disconnects keep happening? I have NEVER had this problem when I played this game months back.
What's even more funny, is that during the free login weekend, when it was the busiest... I didn't D/C... ONCE. Now I can barely stay on for 2 minutes at a time without one of the 90k errors popping in my face. It happens regardless of where I am, whether it be in Mor Dhona or in my Inn Room.
I want to play this game, but if I can't because of some stupid reason... Why should I pay for something I can't access.
Please... Someone help...
-
https://us.battle.net/support/en/art...g-a-traceroute
A how-to for running/interpreting a tracert and such to Blizzard's servers. Apply the concepts to this games servers. There is one exception to the guide, and that is in regards to dumping it to a text file. To make it just display the text on the screen, remove everything after the server address in there example, so it would be "tracert xxx.xxx.xxx". The command they give dumps the results to a text file with no output to the screen, and it will overwrite the file each time you run it. Dumping it to a file like that means you have to open the file to read it, and since it is in a protected location you have to use Admin privileges to edit or rename it.
Alternatively, you can put in an extra > in the command to make it append results each time instead, so it would read "tracert xxx.xxx.xxx >>c:\tracert.txt" instead (>> versus >). Also note that you can make that path and file name anything you want. For example, you can create a folder called FFXIVTRACE at the root of your C:drive, and point the command to C:\FFXIVTRACE\tracert.txt to put it in a file within that folder. This will remove the need to run the CMD prompt as admin, since it won't be at the root of the C:\ drive...which also means you could save the command in a .BAT file and run it from the desktop at will.
If you opt to just display it on the screen with the "tracert xxx.xxx.xxx" command, to copy/paste the text into an email or text file to save it, just right-click anywhere within the DOS window. A context menu should pop up to allow you to Mark or Select All. Mark will allow you to click/drag over text to highlight it, while Select All will highlight all text from the session. At that point, hitting just the <ENTER> key will copy all the highlighted text to clipboard. Then you can use your normal pasting method to put it in an email or text document as you see fit.
If you don't know the IP address of your server, you can use the registered DNS names of the lobby servers (they are in the same subnet and all), or get the IP you actually play on by running the NETSTAT command from the same DOS window after you have logged fully into the game. Netstat will display a list of addresses, many may be in and TIME_WAIT state. You want to look at the ones that are ESTABLISHED. The servers in Canada currently all start with 199. We periodically may servers from up to 3 subnets in Japan at the moment, but the main ones for game play start with 124 (you may also see ones starting with 125 or 202 as well, depending on various circumstances).
Here are the DNS names for the current lobby servers, separated by region:
NA/EU (Canada)
neolobby02.ffxiv.com
neolobby04.ffxiv.com
neolobby06.ffxiv.com
Japan
neolobby01.ffxiv.com
neolobby03.ffxiv.com
neolobby05.ffxiv.com
If you find anything noteworthy in this process pertaining to anything before the SE IP addresses (the ones starting with 199 or 124). Check against other established servers/sites as well (Blizzard's servers, Google, Youtube, Twitch, etc.) as well to see if it is better/worse, then get in touch with your ISP's Tier3 support team. Forward your findings to them so they can conduct a proper investigation and <hopefully> pull in the proper people to address the routing issues.
It is very important that you are dealing specifically with Tier3 (sometimes referred to as Engineering). We are repeatedly seeing issues pertaining to our ISP's routing policies that determine how and with whom we are routed to get to SE's ISP. These are decisions made by our ISP's, but those are made and implemented by Tier3 techs or people higher up the administrative staff. As such, the lower tier guys (like the ones that answer the phone or come check your cables and such) cannot address such issues.
-
I'm not seeing anything unusual so far... Is there something I should be looking for specifically?
-
Pasting something in from another thread, simply because it was still up in my DOS window, and it has some examples which I will colorize to make them stand out better:
Code:
Tracing route to 124.150.157.28 over a maximum of 30 hops
1 1 ms <1 ms 1 ms LPTSRV [10.10.100.1]
2 26 ms 28 ms 28 ms cpe-075-176-160-001.sc.res.rr.com [75.176.160.1]
3 19 ms 22 ms 16 ms cpe-024-031-198-005.sc.res.rr.com [24.31.198.5]
4 15 ms 14 ms 55 ms clmasoutheastmyr-rtr2.sc.rr.com [24.31.196.210]
5 165 ms 195 ms 75 ms be33.drhmncev01r.southeast.rr.com [24.93.64.180]
6 31 ms 29 ms 34 ms bu-ether35.asbnva1611w-bcr00.tbone.rr.com [107.14.19.42]
7 90 ms 88 ms 90 ms bu-ether22.vinnva0510w-bcr00.tbone.rr.com [107.14.17.179]
8 90 ms 91 ms 89 ms bu-ether13.tustca4200w-bcr00.tbone.rr.com [66.109.6.2]
9 86 ms 86 ms 88 ms 0.ae3.pr0.lax10.tbone.rr.com [66.109.9.26]
10 88 ms 88 ms 89 ms 66.109.10.194
11 196 ms 194 ms 197 ms ip-202-147-0-52.asianetcom.net [202.147.0.52]
12 195 ms 196 ms 195 ms gi1-0-0.gw1.nrt5.asianetcom.net [202.147.0.178]
13 193 ms 194 ms 197 ms squareco.asianetcom.net [203.192.149.210]
14 196 ms 196 ms 197 ms 61.195.56.129
15 186 ms 189 ms 187 ms 219.117.144.66
16 294 ms 313 ms 186 ms 219.117.144.53
17 206 ms 214 ms 201 ms 219.117.144.41
18 194 ms 195 ms 195 ms 219.117.147.194
19 192 ms 193 ms 230 ms 124.150.157.28
Trace complete.
High jitter is a bad sign that utilization is getting too high. Jitter is the difference in time between each response. It is often presented as a calculation of the average differences between all replies in a given set. Hop5 is off the scale: 165 -> 195 -> 75. That is 30ms between the first two responses, then 120ms difference between the last two responses. If this were the set of results, the average jitter between them would be 75ms (120+30, divided by 2). If the jitter exceeds about 6% of the average response time (145 in this small set), then it is usually considered in the "red". By that application, this session could be rendered virtually unusable for anything critical... so it would require much more extensive testing to be sure it wasn't just a fluke.
But.. that's a lot of pinging and calculating to prove something you can more easily "eyeball". If you see more than about a 10-15% variance between two adjacent responses, that's a decent enough smoke test to get someone to look at it more closely if you are having stability issues. In this case, 195 to 165 represents an 18% variance (30/165.. use the lower number for the calculation), and meets the test of maybe needing a closer look... but when you look on the other side: 165 to 75 represents a 120% variance. Big red flag there that you want to keep an eye on that to see if it keeps happening. If so, then we need to move into more rigorous testing for that hop (with your ISP's Tier3 guys doing the work of course).
Another red flag is the latency for the distance. That hop is really close to me...Raleigh-Durham in North Carolina. I live in Florence, SC. It's like maybe a 4 hour or so drive to there. I should NOT be getting 75ms latency to there, much less up to 195. One way to prove that is some funky math involving the speed of an electron across both copper wire, the speed of light, and the distance it must travel on either copper or fiber optic cable, adjusting for expected forwarding latency and other factors along the path....
BLEH! Just look at the hops before and after it. Your response times should increment steadily the further away from you it goes. The major component in latency is distance, so the further you are the longer it takes---just like taking a trip on the interstate. Keep in mind that if you are covering big distances between hops, you can get big jumps in response times (like an undersea line from Australia or Japan to California). But, if you see something like what we have here where hop 6 has a WAY lower response time than hop 5, that is a red flag.
If you are unsure about where a hop is located when checking against these variances between hops, you can plug the address into some websites to get an idea of where it may reside (sometimes the DNS name reported gives a good clue though, but sometimes all you have is an IP). I like to use myip.ms a lot. It usually gives you a general enough idea of where it is. Otherwise you can try sites like www.arin.net or www.nic.ad.jp. But usually, you get enough names reported you can kind of tell how far you have gone so you can guage the increases somewhat.
The third one and easiest to spot is if the same hop intermittently returns * events and response times. A result like 126 * 180 for example. That means that it took too long to respond to the second query and it just gave up waiting and moved on to the third one. This typically means that hop is so overloaded that it's shaping rules are either delaying or denying lower priority traffic to try to prevent congestive failure. In other words, it's a dead ringer that it is overly congested and someone needs to step up to the plate and unclog the pipes somehow.
***Note that a hope that consistently reports three stars (* * *) is not necessarily an indication of high utilization. Some may be programmed to not respond at all to the ECHO request. It is when you see a hop give BOTH a response time and any number of stars that it is something to cause concern. So, if it give * * * three times in a row, and then gives at least one time on the fourth trace---something is up.
Ok.. now... an important thing to remember. Traffic flows in a linear path along the route, and an issue at one hop can affect anything that comes after it. This can happen in either direction, but you need different tools for testing return path---this is testing for smoke along the forward path mostly (though, the signs of high lag COULD be on return path). The purpose of this is to try to pinpoint if issues may be occurring, and a general idea of where one might want to look more closely for the root problem. To continue a theme, you are conducted a test for smoke before calling your ISP to test for fire. Just like you wouldn't take an axe to the wall in your home if you see smoke coming from the light switch--you call the fire department.
All you are looking for are the signs of a problem that may warrant further investigation, documenting it, and then forwarding that to your ISP. You are providing them a roadmap for them to follow. Otherwise, you are just one of hundreds of people making background noise to them... and will be paid little more attention than most people give to the guys on the street corners wearing signs proclaiming the pending apocalypse. It you can provide them more concrete signs of a problem occurring, and where it may be happening---they have something actionable to work from and will be far more inclined to assist you.
But you need to be in touch with Tier3 support. Cannot stress this enough. They are the ones most likely to understand the value in what you are providing, how to best interpret it, and how best to move forward. I don't mean to disparage the Tier1 and 2 guys that answer the phones or come check your local cables an such. Some of them are in fact well versed in all this--but company policy will prevent them from even doing anything about it if they wanted to. That is pretty much reserved to Tier3 technicians and further up the administrative staff structure.
-
After some messing around, it seems it's not a ping issue (I usually average about 50ms overall) but my jitter seems to range between 0-20% on some tests... I'm not sure what to make of this, but I know it's not a good thing.
Judging by your last post (and thank you for the useful information btw) I think I might be able to check which hop might be causing the issue but I'm not sure.