Square, your NA/EU data centre has serious issues...

[Istym]

Also since maintainence this morning everything has been fine.

So the issue I was having up until this point were down 100% to SE as they obv fixed some issue they were having with their data centre this morning.

Yeah sure lets carry forward the points we want too and ignore those we don't.

I created this thread to express frustration at being ignored by Support via in game support, which directed me here to then be ignored. So any interjection bejond those points is a derailment of obvious proportions.

[Raist]

It actually could also be tied into changes in the traffic patterns. Granted, AnalogX has lost a lot of the routers in that app, but it can still give some interesting insight into the patterns for some regions. For instance, Ontario was bogging down last night, and the UK has been all over the map for some time now.

As for complaining about someone trying to help you track down your problems, and possibly find a solution...if you don't want such advice or assistance, then don't ask for it.

...because I can play fine on JP server.

So yeah must be my ISP or equipment or or or or

LOL-worthy

So um please advise?

Edit:
And, just out of curiosity, I did a quick dig on sky (seen this name come up with people having issues also--again, can find them come up in WoW forums), and there seems to be some issues around some of the main names showing up in your traces:
http://www.dslreports.com/pingtest/n...om=sky.com&p=1

Just saying... don't be so quick to discard routing issues as a contributor to your problems. There is plenty of evidence out there to support it as being a valid concern worth investigating.

[worldofneil]

watch this game coding through ping process its the servers from game side

You can't look at ICMP traceroute packets (where each bit of data is typically less than 100 bytes) and compare it to the TCP/UDP packets that the game is using to relay information. ICMP and TCP (and UDP for that matter) are completely different protocols (and the TCP/UDP packets being sent while playing are probably a lot bigger than the ICMP traffic too!).

Sure they'll be taking the same path across the Internet, but ICMP data is rarely interrupted (and if it is it's just outright blocked), but TCP/UDP data can (and often is) filtered/restricted depending on who's network it's passing through and what priority the traffic has.

You can use a traceroute to see what route the traffic is taking (like the name suggests) and to see if there's any obvious blockages, but you cannot use it as guarantee of speed.

[Raist]

Traffic pattern's have nothing to do with the issue that she is currently having from what she has posted if you could properly read her pc coding you can tell its a issue with the server from the game side and you said you work with honda it has nothing to do with computers and vast networking information i look at this coding 16 hrs a day and get home play game and watch this game coding through ping process its the servers from game side please stop with your foolish help and defending the SE Fan Boy and stick what you do best and thats work for Honda and not coding

Actually, if you look at the traces... it is falling in line with what others have noticed--it's just not as bad as it has been documented elsewhere, but then again this is only a couple traces taken after the traffic patterns have appeared to have leveled off again. Have to look at the bigger picture, and there is evidence of a problem when you look at all the info out there.

Just because I now work for Honda doesn't mean I don't have any experience with computers--I used to work on implementations years ago. Also, I experienced this very thing in the past with XI, worked with my ISP to identify these very indicators--and they managed to get me routed differently to resolve the problem. Had to go through the process twice, and since then I haven't had to get them involved again since (this was discussed in another thread that the OP was active in already).

Despite there being both precedent as well as evidence of similar circumstances with XIV, some just want to put it all on SE and their servers, regardless of how much evidence is out there pointing out there are also issues in route that may be resolved without SE's involvement. Resolving one will likely not fix all of the issues, but it stands to make a marked improvement for the vast majority of those really suffering because of how it compounds the problem. The point being, that you can't just expect SE to do something at the servers and completely resolve the issues when you also have problems with a third or fourth party's segments between you and the servers. They will still be there causing issues. These will still need to be addressed---and they can't reasonably be addressed by SE alone. You will likely fair much better if you get your ISP involved--after all, they are the ones using these guys for routing in the first place. But, you need to gather the proper information to forward to them so they have something to work with.

[Istym]

Okay I spoke to technical support with my ISP and they are unable to find any routing issues too the the IP's in question and queried with me why I thought this may be an issue. I explained somebody who works at Honda on an internet forum said its the problem, they stipulated that they would need some dialog or communication from the service provider namely SquareEnix in this case to be able to investigate further although they also communicated with me that its quite apparent that the service provider appears to be having issues providing their service, namely FF XIV ARR.

Soooo your focusing on the result of 204.62.14.156 as the issue it takes for my fishing rod to cast 10 seconds after I click the button. I havent seen this IP in other threads, its completely plausible it has nothing to do with FF XIV ARR whilst the ones that are certainly to do with ARR 199.91.189.74 & 199.91.189.21 both showed no routing issue whatsoever, nor do they ever, when ever i run those, however, conveniently you choose to look only at and spin the data as can be likened to some kind of damage limitation, public relations expert, and its a shame Square didn't employ Customer Service Advisors instead.

Raist you are ignoring evidence and precedent as thus.

In beta I had no issues whatsoever.

In Early Access I had major issues as did 100%(?) of the community re logging in because quite simply the servers could not cope to the point that SquareEnix stopped selling their product because they realised they had a major issue. Now I don't know how heavily involved your have ever been in the higher echelons of a business however, I can confirm it takes major problems for a firm to decide to stop selling its product.

Prior to last weeks maintenance everything was rosy, then after maintenance the problems started again, then after this weeks maintenance everything is fine again.

The evidence is plain to see that SquareEnix are doing something during their maintainence sessions that is alleviating and causing problems for users.

This is compounded by the fact they refuse to communicate and support their customers who made a financial investment with them regarding purchase.

[Raist]

Okay I spoke to technical support with my ISP and they are unable to find any routing issues too the the IP's in question and queried with me why I thought this may be an issue. I explained somebody who works at Honda on an internet forum said its the problem, they stipulated that they would need some dialog or communication from the service provider namely SquareEnix in this case to be able to investigate further although they also communicated with me that its quite apparent that the service provider appears to be having issues providing their service, namely FF XIV ARR.

Soooo your focusing on the result of 204.62.14.156 as the issue it takes for my fishing rod to cast 10 seconds after I click the button. I havent seen this IP in other threads, its completely plausible it has nothing to do with FF XIV ARR whilst the ones that are certainly to do with ARR 199.91.189.74 & 199.91.189.21 both showed no routing issue whatsoever, nor do they ever, when ever i run those, however, conveniently you choose to look only at and spin the data as can be likened to some kind of damage limitation, public relations expert, and its a shame Square didn't employ Customer Service Advisors instead.

Raist you are ignoring evidence and precedent as thus.

In beta I had no issues whatsoever.

In Early Access I had major issues as did 100%(?) of the community re logging in because quite simply the servers could not cope to the point that SquareEnix stopped selling their product because they realised they had a major issue. Now I don't know how heavily involved your have ever been in the higher echelons of a business however, I can confirm it takes major problems for a firm to decide to stop selling its product.

Prior to last weeks maintenance everything was rosy, then after maintenance the problems started again, then after this weeks maintenance everything is fine again.

The evidence is plain to see that SquareEnix are doing something during their maintainence sessions that is alleviating and causing problems for users.

This is compounded by the fact they refuse to communicate and support their customers who made a financial investment with them regarding purchase.

At least you finally took the steps and contacted your ISP and provided data for them to look at.

Why so angry? And why all the mockery? Yeah, I work for Honda now... but you know nothing of my employment. FYI, I used to work for an IBM and MS Gold partner. As stated earlier, I worked on implementations. I've put up all kinds of hardware in all kinds of environments in the past. I've done my share of telnets into Cisco routers trying to track down issues, working with service providers to locate issues before sending technicians on-site.

As for them not finding any issues now, well that's great! Thought things were better in game for you atm too? Would stand to reason if that's the case... and doesn't automatically discount the fact that there have been issues in routing. This is where I first picked up on it the situation:
http://forum.square-enix.com/ffxiv/t...ute-to-servers

So I poked around a bit. There is a bad hop in my route that is dropping packets.

Tracing route to 199.91.189.74 over a maximum of 30 hops

1 <1 ms <1 ms <1 ms Wireless_Broadband_Router.home [private]
2 6 ms 8 ms 7 ms L100.WASHDC-VFTTP-63.verizon-gni.net [private]
3 28 ms 14 ms 10 ms G0-9-2-6.WASHDC-LCR-21.verizon-gni.net [130.81.97.106]
4 9 ms 8 ms 8 ms ae1-0.RES-BB-RTR1.verizon-gni.net [130.81.209.206]
5 11 ms 12 ms 11 ms 0.ae5.XL1.IAD8.ALTER.NET [152.63.8.121]
6 9 ms 8 ms 8 ms 0.xe-10-0-1.GW9.IAD8.ALTER.NET [152.63.33.161]
7 * 14 ms 14 ms tinet-gw.customer.alter.net [152.179.50.30]
8 41 ms 39 ms 37 ms xe-1-0-0.mtl10.ip4.tinet.net [89.149.185.41]
9 41 ms 37 ms 40 ms ormuco-gw.ip4.tinet.net [216.221.156.110]
10 47 ms 41 ms * 192.34.76.2
11 47 ms 41 ms 42 ms 199.91.189.234
12 37 ms 39 ms 38 ms 199.91.189.74

Hop 9 is actively dropping traffic.

9 41 ms 37 ms 40 ms ormuco-gw.ip4.tinet.net [216.221.156.110]

Example:

Reply from 216.221.156.110: bytes=64 time=40ms TTL=250
Reply from 216.221.156.110: bytes=64 time=39ms TTL=250
Reply from 216.221.156.110: bytes=64 time=37ms TTL=250
Request timed out.
Request timed out.
Reply from 216.221.156.110: bytes=64 time=40ms TTL=250
Reply from 216.221.156.110: bytes=64 time=34ms TTL=250
Reply from 216.221.156.110: bytes=64 time=33ms TTL=250
Reply from 216.221.156.110: bytes=64 time=38ms TTL=250
Reply from 216.221.156.110: bytes=64 time=32ms TTL=250
Request timed out.
Reply from 216.221.156.110: bytes=64 time=38ms TTL=250
Request timed out.
Reply from 216.221.156.110: bytes=64 time=38ms TTL=250
Reply from 216.221.156.110: bytes=64 time=38ms TTL=250
Reply from 216.221.156.110: bytes=64 time=39ms TTL=250
Reply from 216.221.156.110: bytes=64 time=35ms TTL=250
Request timed out.
Reply from 216.221.156.110: bytes=64 time=38ms TTL=250
Reply from 216.221.156.110: bytes=64 time=42ms TTL=250
Reply from 216.221.156.110: bytes=64 time=36ms TTL=250
Reply from 216.221.156.110: bytes=64 time=37ms TTL=250


Whois:

http://whois.arin.net/rest/nets;q=21...se&ext=netref2

It's semi inconsistent. It keeps going in and out, but it's definitely that location.

Hope this helps.

There are countless examples like this where people having issues are showing problems in route when lagging out. Those not experiencing problems (like my self) are not showing problems in their traces. Could just be coincidence... but when you see it happening consistently, it certainly looks like a pattern. A pattern that has been seen before, and resolved without SE getting into it. That seems to be being overlooked here--the similarities. Note that trace had issues with a tinet segment as well, as did you in that one trace. This is a common theme--certain groups have similar issues in the same regions. you know the old saying.. where there's smoke, there's fire?

It just so happens, as I mentioned before, I experienced this same thing in the past with XI, and worked with my ISP to resolve it. It was in Virginia one time, and once in Nova Scotia--not in my ISP's network, and not in SE's either. The time in VA was in Ashburne, on a Verizon FiOS segment. I remember that specifically because the RR tech was shocked to see the problem looked like it was on their end.

As for SE doing something in their maintenance that fixed connectivity... they didn't announce any such changes. All they said about the last one was to address an issue with item abuse. Perhaps it can be attributed to a butt-load of AFK'ers that temporarily went off-line when he servers went down? Maybe things will get worse again when the servers and lines get busy again?

Again, I commend you on at least taking the first steps to try to draw someone else in that might be able to affect changes for the better. At least now your ISP has some data to use as a reference for both yourself and others that might contact them as well. Perhaps now if things go south and you or others contact them again, they will have data to analyze while things are in both a good and troubled state.

[Istym]

Raist you are ignoring evidence and precedent as thus.

In beta I had no issues whatsoever.

In Early Access I had major issues as did 100%(?) of the community re logging in because quite simply the servers could not cope to the point that SquareEnix stopped selling their product because they realised they had a major issue. Now I don't know how heavily involved your have ever been in the higher echelons of a business however, I can confirm it takes major problems for a firm to decide to stop selling its product.

Prior to last weeks maintenance everything was rosy, then after maintenance the problems started again, then after this weeks maintenance everything is fine again.

The evidence is plain to see that SquareEnix are doing something during their maintainence sessions that is alleviating and causing problems for users.

This is compounded by the fact they refuse to communicate and support their customers who made a financial investment with them regarding purchase.

Please take you routing crap elsewhere, it is not, nor ever was relevant to my thread.

[Raist]

Please take you routing crap elsewhere, it is not, nor ever was relevant to my thread.

You asked for advise on your communication issues with their data center. Other's have been actively researching and documenting where they have noticed problems in the routing to those data centers. I advised you to research that angle and forward your findings to your ISP like others have begun doing in an effort to begin the troubleshooting phase to confirm whether or not it is indeed an issue. Troubleshooting is a process of elimination, sometimes it involves a lot of trial and error testing, checking the known-knowns and the known-unknowns and such (cue Samuel Jackson... "the absence of evidence is not the evidence of absence" bit). The key thing is sometimes you need to begin the troubleshooting phase by collecting pertinent information/materials and such, then handing it over to someone who can review it all and test things out.

Advise was sought, a plausible course of action was presented. That is all completely relevant to your thread.

You simply chose to discard it as plausible and argue about it... so long that you may have missed an opportunity to gather some more useful information on the situation. But at least you did finally start the process, which is good. Now more people are aware of the players involved, and where to look if/when they investigate this further. Let's hope that it eventually leads to some progress towards resolution.

[Marishi-Ten]

Your jumping on every minute detail and using that to deflect attention from the true issue here. All I am seeing is either a shill, or a fan boy spending a mega amount of time running around the forums defending SE.

Also since maintainence this morning everything has been fine.

So the issue I was having up until this point were down 100% to SE as they obv fixed some issue they were having with their data centre this morning.

GTFO my thread ^^

I don't believe he's jumping down your throat. He's actually providing accurate advice. You can't judge network stability on a couple tracert runs. You have to run it constantly over the course of a few hours on peak times. You also were timing out and dropping packets which would give you a MD5 flag error and the rubber banding issue.

The issue isn't with the SE data center. It's with the backbone and hops that you are routing through dropping packets due to them seeing so much traffic it's overloading their ports.

You're routing through 6sync.net. That's a virtual server. Are you behind a VPN? Also, you're being routed through Level 3. That's a T1 backbone in the US. Ask your ISP to route you though a different path. I doubt the problem is on them though. T1 backbones don't normally experience node issues as they have so much hardware to back up the traffic.

Check this site out: http://www.internetpulse.net/

This shows Level 3 currently having issues with Cogent/TATA nodes (A KNOWN troublemaker that can't seem to keep anything stable for longer than 30 minutes that about 90% of users route through to get to Montreal). This is more than likely the cause of your latency issues. Request a trouble ticket from your ISP so you can be re routed away from Level 3 until they are able to stabilize the connections.

I've provided some data of trace routes showing the issue on a remote server, not the remote host or client:

4 boid-agw1.inet.qwest.net (184.99.65.65) 20.875 ms 18.362 ms 27.125 ms
5 sea-brdr-02.inet.qwest.net (67.14.41.18) 31.322 ms 44.643 ms 55.797 ms
6 ix-1-0-0-0.tcore1.00s-seattle.as6453.net (64.86.123.77) 31.431 ms 30.914 ms 31.687 ms
7 if-11-0-0-5.core1.00s-seattle.as6453.net (64.86.124.25) 192.185 ms
if-13-0-0-4.core1.00s-seattle.as6453.net (64.86.124.13) 315.271 ms 54.614 ms
8 if-4-1-0-0.tcore2.ct8-chicago.as6453.net (64.86.124.10) 104.565 ms 96.403 ms 95.589 ms
9 if-3-2.tcore1.w6c-montreal.as6453.net (66.198.96.45) 106.126 ms 157.243 ms 97.227 ms
10 66.198.96.50 (66.198.96.50) 99.638 ms 99.754 ms 101.073 ms
11 192.34.76.2 (192.34.76.2) 102.590 ms 103.997 ms 100.751 ms

sudo ping neolobby02.ffxiv.com
PING neolobby02.ffxiv.com (199.91.189.74): 56 data bytes
Request timeout for icmp_seq 0
64 bytes from 199.91.189.74: icmp_seq=1 ttl=54 time=537.147 ms
64 bytes from 199.91.189.74: icmp_seq=2 ttl=54 time=458.225 ms
64 bytes from 199.91.189.74: icmp_seq=3 ttl=54 time=379.185 ms
64 bytes from 199.91.189.74: icmp_seq=4 ttl=54 time=386.048 ms
64 bytes from 199.91.189.74: icmp_seq=5 ttl=54 time=169.980 ms
64 bytes from 199.91.189.74: icmp_seq=6 ttl=54 time=134.348 ms
64 bytes from 199.91.189.74: icmp_seq=7 ttl=54 time=115.387 ms
64 bytes from 199.91.189.74: icmp_seq=8 ttl=54 time=108.769 ms
64 bytes from 199.91.189.74: icmp_seq=9 ttl=54 time=104.653 ms
64 bytes from 199.91.189.74: icmp_seq=10 ttl=54 time=103.875 ms

--- neolobby02.ffxiv.com ping statistics ---
457 packets transmitted, 454 packets received, 0.7% packet loss
round-trip min/avg/max/stddev = 99.605/113.363/664.401/51.532 ms

boid-agw1.inet.qwest.net (184.99.65.65) 17.779 ms 18.350 ms 17.408 ms
5 sea-brdr-02.inet.qwest.net (67.14.41.18) 30.822 ms 30.159 ms 30.602 ms
6 ix-1-0-0-0.tcore1.00s-seattle.as6453.net (64.86.123.77) 31.615 ms 32.681 ms 30.775 ms
7 if-0-0-0-2.core1.00s-seattle.as6453.net (64.86.123.2) 30.830 ms
if-1-0-0-3.core1.00s-seattle.as6453.net (64.86.123.6) 31.310 ms
if-0-0-0-2.core1.00s-seattle.as6453.net (64.86.123.2) 31.403 ms
8 if-4-1-0-0.tcore2.ct8-chicago.as6453.net (64.86.124.10) 96.160 ms 516.145 ms 699.067 ms
9 if-3-2.tcore1.w6c-montreal.as6453.net (66.198.96.45) 330.758 ms 222.031 ms 96.910 ms
10 66.198.96.50 (66.198.96.50) 100.557 ms 101.032 ms 100.031 ms

[Raist]

oooh... nice app there Marishi-Ten! Almost couldn't pull myself away from it... hehehe. Looks like there may be a little wonkiness coming through the North East corridors too (it registered some packet loss and stuff around Boston a few times). Man... seems like some people just can't win these days. Wish I could find a looking glass through the Midwest from the SouthEast. Seem to recall I was coming up through Milwaukee or something at one time and it was pretty good--was definitely breaking in at Toronto then, do recall that much.

Edit:
ewe... scratch that thought about Milwaukee... found a path from Atlanta through there --nearly 20% packet loss registered on one. Man this bites.