...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?
Square, your NA/EU data centre has serious issues...
Printable View
-
10-01-2013, 06:49 AMIstymSquare, your NA/EU data centre has serious issues...
-
10-01-2013, 07:45 AMRaist
Run a trace to your world server, and lookup the details on the IP's where the trace derails. Pretty confident you will find it is either Cogent, i-Web, or TATA at fault--- not SE. Need to be in contact with your ISP to see if they can help resolve your routing issues.
-
10-01-2013, 12:42 PMIstym
No no no been there done that max hop i ever saw was 110ms.
-
10-01-2013, 12:57 PMIstym
199.91.189.74
Tracing route to 199.91.189.74 over a maximum of 30 hops
1 1 ms 3 ms 2 ms <removed>
2 21 ms 27 ms 23 ms sr11.enncl.isp.sky.com []
3 25 ms 32 ms 29 ms 02780812.bb.sky.com [2.120.8.18]
4 29 ms 31 ms 32 ms ip-84-38-37-94.easynet.co.uk [84.38.37.94]
5 29 ms 28 ms 27 ms ae3.lon10.ip4.tinet.net [77.67.74.93]
6 114 ms 146 ms 105 ms xe-4-2-0.mtl10.ip4.tinet.net [141.136.107.125]
7 105 ms 105 ms 107 ms ormuco-gw.ip4.tinet.net [216.221.156.110]
8 110 ms 106 ms 107 ms 192.34.76.2
9 106 ms 105 ms 105 ms 199.91.189.234
10 131 ms 105 ms 110 ms 199.91.189.74
Trace complete.
tracert 199.91.189.21
Tracing route to 199.91.189.21 over a maximum of 30 hops
1 4 ms 5 ms 3 ms
2 15 ms 23 ms 15 ms sr11.enncl.isp.sky.com []
3 34 ms 33 ms 29 ms 02780812.bb.sky.com [2.120.8.18]
4 27 ms 27 ms 31 ms ip-84-38-37-96.easynet.co.uk [84.38.37.96]
5 29 ms 57 ms 43 ms ae3.lon10.ip4.tinet.net [77.67.74.93]
6 105 ms 114 ms 141 ms xe-4-2-0.mtl10.ip4.tinet.net [141.136.107.125]
7 108 ms 109 ms 109 ms ormuco-gw.ip4.tinet.net [216.221.156.110]
8 111 ms 111 ms 113 ms 192.34.76.2
9 105 ms 106 ms 107 ms 199.91.189.234
10 133 ms 107 ms 109 ms 199.91.189.21
Trace complete.
tracert 204.62.14.156
Tracing route to 204-62-14-156.static.6sync.net [204.62.14.156]
over a maximum of 30 hops:
1 6 ms 1 ms 2 ms
2 20 ms 17 ms 24 ms sr11.enncl.isp.sky.com []
3 35 ms 29 ms 34 ms 02780812.bb.sky.com [2.120.8.18]
4 32 ms 27 ms 32 ms te0-1-0-5.er10.thlon.ov.easynet.net [89.200.134.
127]
5 26 ms 24 ms 27 ms 195.50.122.113
6 97 ms 98 ms 95 ms vl-3606-ve-230.csw2.London1.Level3.net [4.69.166
.22]
7 94 ms 95 ms 94 ms ae-56-221.ebr2.London1.Level3.net [4.69.153.129]
8 93 ms 96 ms 99 ms ae-42-42.ebr1.NewYork1.Level3.net [4.69.137.70]
9 99 ms 96 ms 93 ms ae-2-2.ebr1.Newark1.Level3.net [4.69.132.98]
10 93 ms 94 ms 96 ms ae-12-51.car2.Newark1.Level3.net [4.69.156.6]
11 98 ms 92 ms 103 ms GIGLINX-INC.car2.Newark1.Level3.net [4.28.188.13
0]
12 95 ms 98 ms 98 ms 204-62-14-156.static.6sync.net [204.62.14.156]
Trace complete.
Although its currently off peak, again tracing whatever IP's Netstat shows I do not see any of the entries you mention, nor do I when I run this during peak times and the hop times do not increase overly much during peak times.
What I do see however is a company that actually stopped selling their product (digital sales) because their servers could not cope, and I see a situation where by their servers still cannot cope.
Its not rocket science as much as some may try make it so.
Also how many of these tracert reports are lying around the forums with peoples actual IPs left in them. Could that be a contributing factor with all the stolen accounts we are seeing spamming RMT links like its open season. -
10-02-2013, 03:38 AMIstym
And here are the outputs from tracert during peak time.
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\Istym>tracert 199.91.189.21
Tracing route to 199.91.189.21 over a maximum of 30 hops
1 2 ms 4 ms 1 ms
2 16 ms 15 ms 16 ms sr11.enncl.isp.sky.com []
3 27 ms 36 ms 27 ms 02780812.bb.sky.com [2.120.8.18]
4 33 ms 43 ms 34 ms ip-84-38-37-96.easynet.co.uk [84.38.37.96]
5 37 ms 31 ms 28 ms ae3.lon10.ip4.tinet.net [77.67.74.93]
6 111 ms 138 ms 105 ms xe-4-2-0.mtl10.ip4.tinet.net [141.136.107.125]
7 105 ms 113 ms 105 ms ormuco-gw.ip4.tinet.net [216.221.156.110]
8 106 ms 104 ms 109 ms 192.34.76.2
9 106 ms 106 ms 112 ms 199.91.189.234
10 106 ms 109 ms 180 ms 199.91.189.21
Trace complete.
tracert 204.62.14.156
Tracing route to 204-62-14-156.static.6sync.net [204.62.14.156]
over a maximum of 30 hops:
1 2 ms 2 ms 2 ms
2 18 ms 15 ms 16 ms sr11.enncl.isp.sky.com []
3 28 ms 41 ms 28 ms 02780812.bb.sky.com [2.120.8.18]
4 29 ms 31 ms 31 ms te0-1-0-5.er10.thlon.ov.easynet.net [89.200.134.
127]
5 * 30 ms 23 ms 195.50.122.113
6 93 ms 101 ms 98 ms vl-3606-ve-230.csw2.London1.Level3.net [4.69.166
.22]
7 93 ms 94 ms 92 ms ae-56-221.ebr2.London1.Level3.net [4.69.153.129]
8 96 ms 93 ms 92 ms ae-42-42.ebr1.NewYork1.Level3.net [4.69.137.70]
9 95 ms 99 ms 93 ms ae-2-2.ebr1.Newark1.Level3.net [4.69.132.98]
10 98 ms 97 ms 104 ms ae-12-51.car2.Newark1.Level3.net [4.69.156.6]
11 101 ms 94 ms 102 ms GIGLINX-INC.car2.Newark1.Level3.net [4.28.188.13
0]
12 93 ms 97 ms 92 ms 204-62-14-156.static.6sync.net [204.62.14.156]
Trace complete.
tracert 199.91.189.74
Tracing route to 199.91.189.74 over a maximum of 30 hops
1 2 ms 1 ms 1 ms
2 24 ms 15 ms 15 ms sr11.enncl.isp.sky.com []
3 34 ms 31 ms 31 ms 02780812.bb.sky.com [2.120.8.18]
4 25 ms 31 ms 31 ms ip-84-38-37-94.easynet.co.uk [84.38.37.94]
5 28 ms 28 ms 29 ms ae3.lon10.ip4.tinet.net [77.67.74.93]
6 105 ms 105 ms 105 ms xe-4-2-0.mtl10.ip4.tinet.net [141.136.107.125]
7 104 ms 106 ms 105 ms ormuco-gw.ip4.tinet.net [216.221.156.110]
8 105 ms 105 ms 105 ms 192.34.76.2
9 105 ms 107 ms 105 ms 199.91.189.234
10 108 ms 106 ms 106 ms 199.91.189.74
Trace complete.
So as you can see your theories are incorrect and the issues I have are due to the Square Enix server quality @ its EU/NA datacentre. -
10-02-2013, 03:52 AMRaist
did you not notice you are getting intermittent time outs in your trace? Also the marked variances in your delays?
These are the signs people have been making note of in the other threads. Each trace you run is a snapshot at a fixed point in time--after taking multiple snapshots, you can start to see certain sections of your routing is unstable. For instance, take a closer look at what is going on when you come around easynet and into tinet. You sometimes experience a marked increase in typical delay, and in one of your sessions you actually experienced a time out. If more samples were taken, you may see more of this behavior occur--possibly in the same spots, maybe at other points. -
10-02-2013, 04:03 AMIstym
Yada yada yada post your SE employee number and be done with it
-
10-02-2013, 04:07 AMRaist
I'm employed by Honda.
Again, you don't seem to be getting the point. You are looking at only a few isolated points of time. And even though it is a limited sample set, in one of those runs a potential issue is clearly marked in your trace. For whatever reason, you just aren't seeing it. -
10-02-2013, 04:17 AMIstym
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 ^^ -
10-02-2013, 04:30 AMworldofneilSE don't reply to threads on this Technical Support forum, the only people that do are other players, like him. If you don't want these players to post their replies then I'm afraid you're going to get no replies at all.Quote:
Originally Posted by Istym
Unless you're only saying you don't want replies that you don't agree with? -
10-02-2013, 04:49 AMIstymYeah sure lets carry forward the points we want too and ignore those we don't.Quote:
Originally Posted by Istym
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. -
10-02-2013, 05:04 AMRaist
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.
Edit:Quote:
Originally Posted by Istym
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. -
10-02-2013, 05:31 AMworldofneilYou 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!).Quote:
Originally Posted by Kheni
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. -
10-02-2013, 05:52 AMRaistActually, 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.Quote:
Originally Posted by Kheni
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. -
10-02-2013, 07:03 AMIstym
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. -
10-02-2013, 07:32 AMRaistAt least you finally took the steps and contacted your ISP and provided data for them to look at.Quote:
Originally Posted by Istym
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
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?Quote:
Originally Posted by Yuengling
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. -
10-02-2013, 07:45 AMIstymPlease take you routing crap elsewhere, it is not, nor ever was relevant to my thread.Quote:
Originally Posted by Istym
-
10-02-2013, 09:33 AMRaistYou 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.Quote:
Originally Posted by Istym
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. -
10-02-2013, 10:30 AMMarishi-TenI 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.Quote:
Originally Posted by Istym
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 -
10-02-2013, 10:50 AMRaist
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. -
10-02-2013, 10:51 AMMarishi-Ten1.) Beta didn't incorporate the NA datacenter. Japan has more robust network protocols than NA can ever hope to achieve. You didn't experience problems because Japan's nodes and fiber destroy anything NA has.Quote:
Originally Posted by Istym
2.) Early Access you were routing to the NA data center. Fiber and node ports were overloading under the amount of traffic and stress leading up to the Montreal data center. This is expected.
3.) Traffic ebbs and flows. As Square increases port and IP availability on their racks, it creates more route paths to ease up on the fiber and remote nodes. This is cause and effect. This isn't fixing anything. It's treating a symptom. The main problem is still there. All Square can do is try to mask it.
4.) Square is tweaking the ports on their side and adding more racks. They are talking to their fiber provider and re routing traffic to try to clear the issues. This isn't exact science. It's change this and see what happens. You can't test a network unless it's under load.
5.) What should they communicate? That they know there is a problem but since another company hosts the hops and fiber they can't do anything about it essentially throwing them under the bus and being open to a possible libel case? This makes them look inept to people that don't know how networking and servers work.
It's not anyone defending Square. It's how the internet fundamentally works. -
10-02-2013, 10:57 AMGonzothegreat198
I love how when anyone posts something in any thread that's opposite to what that person "KNOWS" is whats happening that it automatically makes that person commenting a SE White Knight, heaven forbid the person commenting might know what the hell they are talking about, instead of being a stuck up 12 year old kid who knows jack about network infrastructure.
-
10-02-2013, 11:15 AMAndyFLHXI am a Network Security professional.Quote:
Originally Posted by Gonzothegreat198
http://forum.square-enix.com/ffxiv/t...%28Petition%29 -
10-02-2013, 11:32 AMMarishi-TenThat's awesome you took the time to compile the bigger threads into one. I played with the idea, but never got around to it.Quote:
Originally Posted by AndyFLHX
Square has to be careful announcing issues about latency. It's more of a PR/legal move than anything else. If they point the finger at a company and the fault isn't with or wholly on them, this leaves Square open to a libel suit. Square also has service agreements with their fiber provider. They may have a DNC with them about issues regarding their infrastructure that prohibits them from giving information. Also, why comment when nothing can be done? It doesn't do anyone any good and only shows the general public that something is wrong and Square isn't up to fixing it (even though they CAN'T, most people won't see it like that).
The sticky thread isn't so much a data mine for throttling (Some ISP's can and will do this though. I'm talking to you Verizon) but seems to be a mine for location and route information so they can show the backbone/fiber companies that there is indeed a problem and it needs to be addressed. They hid it to avoid any finger pointing and blaming. They essentially get what they need without pointing fingers.
On a final note, keep in mind that the US is operating on 60 year old technology and expects it to operate like a fiber drop to the host. It won't. It simply can't. The US will never have network infrastructure like Japan has. The US is too big and is too far behind the curve. I've seen some hubs that are in such sorry condition (AT&T) that it's amazing any traffic gets through at all. -
10-02-2013, 11:41 AMAndyFLHXVery respectable post and argument. But due to the random nature of this issue, the blame falls on the company that obviously chose this route. Experiencing a bit of lag, maybe even 150-200ms would be okay really, even in some small windows. But rapid packet loss, and a large spread of the same issue means only one true thing.Quote:
Originally Posted by Marishi-Ten
+1 -
10-02-2013, 11:45 AMGonzothegreat198Quote:
Originally Posted by Marishi-Ten
And that's only when you look at just the networking side. If you take a look at the telephone side of things its even worse. The one set of switches that we have access to at my job can only be accessed through telnet/dos, and they are newer than the mainline switches that the majority of the east coast runs over. -
10-02-2013, 11:57 AMMarishi-TenIt's not only relevant, it's the cause of the issues you're seeing. Plain and simple. Route paths are the most important aspect in networking. It gives you a reference point to an otherwise impossible to pin down issue. It's your compass when you're lost in the networking world.Quote:
Originally Posted by Istym
You're frustrated. I get it. I also sympathize with you. Techs at ISP companies aren't known for their intellect. They only have visibility into their own infrastructure (just like Square and EVERY other telecomms company).
I'll break it down:
You are in LA (CLIENT) and you are getting on a plane to NY (HOST). It should be a quick trip with minimal layovers (HOPS). However, there is a storm (PORT OVERLOADING) and you are delayed. You then have a layover in Chicago (BOTTLENECKING) increasing your time to NY (HOST). This adds time onto your total flight time (LATENCY/PACKETS). You took longer to get to NY (HOST) and now you've missed the grand gala inauguration ball (MD5 ERRORS/DESYNCHRONIZATION TO HOST) but you made it, you're just late (RUBBERBANDING/RUSH OF DATA).
The internet isn't a point A to point B. Ever. You have to route though major hubs to get to your destination. If the hub is having problems, you have problems. Though it may appear the issue is with Square, they do NOT own the hubs and as thus, cannot provide maintenance or support on them. Does this make it Square's fault? No, it doesn't. They are just the end point. Only by changing flight paths (MORE RACKS) can they service the amount of people passing through their terminals (SERVER/HOST).
Though this isn't the best analogy, it does show how the internet works and how many companies are involved and the MILLIONS of miles of copper/fiber you have to go through to get data I/O.
You're blaming the wrong people. -
10-02-2013, 12:10 PMMangI don't like you. You suck at arguing, your grammar is terrible as shit, and you at no point refuted a thing Raist said.Quote:
Originally Posted by Istym
-
10-02-2013, 12:21 PMAppleh4xActually the cause is entirely the game/data server. This is an email I got from SE support today:Quote:
Originally Posted by Marishi-Ten
"Dear Customer,
Regarding your request for account support. Please find your answer below.
If you are receiving an Error 90000 when attempting to access FINAL FANTASY XIV: A Realm Reborn, please try again later. This error simply means that the server is congested and you will need to keep trying until you are able to login. We apologize for any inconvenience this may cause you.
Thank you for contacting the SQUARE ENIX Support Center." -
10-02-2013, 01:10 PMHoroBoro
Raist, you're caught in a devil's proof. You can't establish that this issue is not SE's fault.
1. You have to prove that the reason this issue is occurring is because of infrastructure and not SE server configuration.
2. The only way to prove that is to get a massive amount of data/logs from each user who is having this problem (as 1 ping/trace does nothing)
3. You have no means of obtaining this massive amount of information. The reports you're doing here is like a grain of sand in the desert.
Thus you cannot prove that this is not SE's fault.
Likewise,we are caught in Hempel's Raven
1. If lag affects our game it's SE's fault
2. If we don't have lag, it's not SE's fault.
3. To qualify 1, in the past , when there was a lag, SE has been able to resolve it.
4. We have no lag SE is doing a good job.
By the same reasoning, the statement would be: If we have Lag, SE is not doing a good job. This is paradoxical - I can think of 100s of occasions where I can have lag and it's not SE's fault.
So what is the solution? The problem is that WE'RE LACKING IN INFORMATION. If SE would be so kind to provide us with more INFORMATION we can start finding a solution. It could very well be our fault. However, we don't know without INFORMATION. And there's literally nothing we can do. -
10-02-2013, 01:31 PMDesign
C:\Users\Wyse>ping 184.107.107.176
Pinging 184.107.107.176 with 32 bytes of data:
Reply from 184.107.107.176: bytes=32 time=55ms TTL=51
Reply from 184.107.107.176: bytes=32 time=56ms TTL=51
Reply from 184.107.107.176: bytes=32 time=55ms TTL=51
Reply from 184.107.107.176: bytes=32 time=56ms TTL=51
Ping statistics for 184.107.107.176:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 55ms, Maximum = 56ms, Average = 55ms
C:\Users\Wyse>ping 184.107.107.176
Pinging 184.107.107.176 with 32 bytes of data:
Reply from 184.107.107.176: bytes=32 time=55ms TTL=51
Reply from 184.107.107.176: bytes=32 time=55ms TTL=51
Reply from 184.107.107.176: bytes=32 time=55ms TTL=51
Reply from 184.107.107.176: bytes=32 time=55ms TTL=51
Ping statistics for 184.107.107.176:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 55ms, Maximum = 55ms, Average = 55ms
C:\Users\Wyse>ping 184.107.107.176
Pinging 184.107.107.176 with 32 bytes of data:
Reply from 184.107.107.176: bytes=32 time=54ms TTL=51
Reply from 184.107.107.176: bytes=32 time=55ms TTL=51
Reply from 184.107.107.176: bytes=32 time=54ms TTL=51
Reply from 184.107.107.176: bytes=32 time=55ms TTL=51
Ping statistics for 184.107.107.176:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 54ms, Maximum = 55ms, Average = 54ms
In game: sending 20-100, Receiving 200-5600
Both these tests were done one during 12PM CTR, the 2nd was at 5pm CTR. Please explain to me how this is an ISP problem when according to this test I am connecting to the server flawlessly, but in game I'm getting lag spikes out of the wazoo
PS: It's not just one place either. I've been hearing people complaining about this in game all day long from NYC to LA USA, and im in TX. So whatever the hell the problem is, this needs fixed and SE needs to stop ignoring us. -
10-02-2013, 01:33 PMDesign
http://www.change.org/petitions/squa...rottling-issue
If you sign this, it'll go to them and help. Petition started. -
10-02-2013, 01:46 PMGonzothegreat198And that statement is a load of bs and you know it. Will it go to them? Sure, will it help? Not bloody likely.Quote:
Originally Posted by Design
-
10-02-2013, 02:23 PMHighsidee
Let me tell you guys something I experienced personally today. I ran coil with a full party and we all lagged pretty bad. Had spikes here n there. Afterwards, I got into a Titan party and same thing happened for everybody. This happened on Gilgamesh, btw.
-
10-02-2013, 03:12 PMCythros
I live at the east coast and my friend lives in CA. My friend has been telling me about massive lag and disconnects from the game servers. He was blaming SE for these problems like many others was doing. I looked at his routing table from CA to SE servers. I found he was having servere packet loss and problems and other problems with a routing server in Palo Alto, CA (owned by Tata Communications). I researched this routing server and found out people playing WoW, GW2, and many other mmorpgs living in CA are having the same problems.
I told my friend to call Verizon (his ISP) and explain the problem and they need to reroute him. They blew him off at first that it was not a Verizon problem. I called Verizon on his behalf and made this a 3-way call between Verizon, my friend, and I. After the conversation, Verizon did reroute him and now my friend's connection to SE game servers is great. Today he tells me that he doesn't get disconnects and doesn't lag like he use too.
The people giving the advice are correct for solving these problems addressed in this thread.
I had login problems like everyone in early access and at launch. I understood the servers was being overloaded. After the 9/4 maintenance, I don't have anymore problems with the game. My ping is around 30-44ms on peak times.
I am a network administrator/engineer, web hosting engineer, and own a technology company. i have over 20 years XP. I figured on giving my some of my background before someone becomes critical on what I posted. -
10-02-2013, 03:20 PMKelenaeVSaddly posts like this is will be drowned out by rampant whining =\Quote:
Originally Posted by Cythros
-
10-02-2013, 03:27 PMCythros
Persona, I agree with ya. I got tired of reading these posts about there connection problems. The only thing people can do is blame SE for all there problems.
-
10-02-2013, 04:15 PMHoroBoro
Network admins coming out in doves defending SE. SE doesn't intend to do any investigation on their side.
I'm sick and tired of disagreeing with people. Forget that there are people who have traced and found no issues (timeout/packet loss/high ping), and yet still experience strange lag. Or that there are people who have no problems with any other games during prime time. Time to be negative, take the safe bet, and sound smart (hey 3 birds, 1 stone).
"Learn to call your ISP."
There: problem solved for thousands of people. I'm done keeping up with the lag issue. It doesn't even affect me. I can dodge just fine looking at circles.
Complainers are always wrong. The big company that doesn't even bother to give a response to a 72 page thread is doing it right.
Lol who cares about responsiveness anyways. -
10-02-2013, 04:37 PMMusouMugen
Well, no matter who's at fault (and it seems ISPs in NA are sucky heh) this issue would be alleviated if they made EU and NA datacenters. EU ppl would only deal with our EU connections, NA ppl would have much less traffic to their datacenters. I want my fucking 30-40ms that I have in every normal MMO with servers in Europe!
As is for me the game becomes unplayable after 8pm or so. Goes from no issues, to small lag spikes, to massive 1-10 sec game freezes (I can move, nothing else is moving, before someone smartasses about my PC). Oh, and it's getting worse with every maintenance. Yesterday I ate pretty much every Succubus AOE in AK...thank fuck I already did Titan. Coil? Hah. Yeh right. And do I care if it's fault of some random ISP in a land far far away? No. It's automatically fault of SE to make people have to connect over half the globe. Or not choosing better provider for their services. Or what-fucking-ever. Most annoying part is...some people have 0 problems, some have a lot and you always get ppl circle-jerking who's fault it is...SE, ISP or the user. -
10-02-2013, 04:43 PMNosiahk
Yo, I got spikes like yo everywhere yo! Fight titan, titan freeze, and BOOM yo I was dead like the yoyo. I click skill, and yo delay like yo shiet 2 seconds, freak me out yo! I gave up yo! Depressing, I can't even yolo dungeon. 50MBPS yo fast like a nascar.. but yo so confused!!! >..< But yo I gave up and started yolo crafting and gathering, and yo dammit! SPIKES! Yo delay in casting skills like 3-4 secs yolo delay!!!! OHHHHHMMMAAAAAIIIIIIGAWDDDDDD!?!?!? Yo very unhappy. I'm a very sad panda now yo.
Yo = Spikes
Yolo = Freezes
I would spike every 15-20 seconds, and then there would be freezes here and there. This is not even due to routing. Same situation happened with the league of legends community several months ago and it was "CONFIRMED" that it was RIOT's server conflicting with certain ISP. Just saying, its very comparable and I have faced the same similar situation.