they know we care because we keep paying them our subs lol
they will fix it soon just give them time
they are a Jap based company and its hard to work for the NA/EU servers
they know we care because we keep paying them our subs lol
they will fix it soon just give them time
they are a Jap based company and its hard to work for the NA/EU servers
you are joking right?
just because they are Japanese company doesn't mean they can offer this kind of crappy service to other countries, if they want to expand business over seas they need to be prepared, instead us NA/EU players are treated like second class citizens, this issue has been going on for a month for some, and not one word from SE, their tech support close tickets without answering or redirect players to these forums where they want you to seek help from other players lol
all players are paying the same sub, NA/EU players should NEVER have been treated this way, not to mention the silence from SE about this issue, there is no excuse.
You guys need to double check the IP you are tracing to to make sure it is the one your game is actually using. I've been seeing an IP out there touted as the datacenter, but that is NOT what your client is using when you are playing. Chasing the wrong tail there.
Also, the problem with the routing is happening on a third party's segment. As has been documented in other threads, there are groups that keep popping up with dramatically increased delays--at times even complete timeouts (not just one star, but * * * and a full retry at times). Three very common providers in those traces: Cogent, i-Web, and TATA. Do a whois lookup on the IP's of your most problematic hops and check who is listed for ownership/administration in ARIN. There is a pretty strong chances that at least one of these 3 names will show up. These segments are NOT managed by SE, nor Ormuco (who manages the IPS that SE's servers are on)--these are completely outside the scope of SE's power, and likely your ISP as well. About all they can do is lean on them to clean up their act, or alter routes to avoid the offensive segments (the latter would be your ISP's responsibility, by the way... not SE's).
Note also, that these hops are physically located either near the US/CA border, or are stationed around Montreal. So, it simply appears to be in large part a regional routing/congestion issue first, potentially compounded by server congestion. If you look closely at your tracerts to your actual world servers, you will notice a specific pattern where the delays are reduced when you get to the SE endpoint---it goes "tits up" (to quote some AU players) when you are entering or cutting across Canada. Even if SE were to pinpoint and resolve congestion and such at the server level--you will STILL be having packet loss and high latency issues because it is a problem in the third party routing.
In order to hopefully better illustrate the issues with the traces, I will paste in two I just took from my laptop. First is to the 184 IP, the second is to the actual IP that XIV uses when I play on Midgard.
Note the IP's where things get worst in BOTH of those traces:Tracing route to 184.107.107.176 over a maximum of 30 hops
<local hops removed for security>
4 24 ms 24 ms 24 ms ge-3-0-0.chrlncpop-rtr1.southeast.rr.com [24.93.64.62]
5 30 ms 30 ms 31 ms bu-ether44.atlngamq46w-bcr00.tbone.rr.com [107.14.19.46]
6 38 ms 30 ms 27 ms ae-0-0.pr0.atl20.tbone.rr.com [66.109.6.171]
7 78 ms 76 ms 72 ms te0-0-0-10.ccr21.atl02.atlas.cogentco.com [154.54.12.109]
8 76 ms 76 ms 80 ms be2052.mpd21.atl01.atlas.cogentco.com [154.54.40.249]
9 89 ms 90 ms 90 ms te0-1-0-6.mpd21.dca01.atlas.cogentco.com [154.54.1.226]
10 97 ms 92 ms 95 ms te0-0-0-14.mpd21.jfk02.atlas.cogentco.com [154.54.42.34]
11 118 ms 112 ms * be2108.ccr21.ymq02.atlas.cogentco.com [154.54.3.134]
12 69 ms 69 ms 69 ms 38.122.42.122
13 68 ms 69 ms 68 ms te7-3.dr9.mtl.iweb.com [67.205.127.214]
14 69 ms 68 ms 69 ms 72.55.128.44
15 71 ms 69 ms 68 ms 184.107.107.176
Trace complete.
Tracing route to 199.91.189.74 over a maximum of 30 hops
<local hops removed for security>
4 23 ms 20 ms 24 ms xe-7-0-0.chrlncpop-rtr1.southeast.rr.com [24.93.64.42]
5 31 ms 31 ms 29 ms bu-ether14.atlngamq46w-bcr00.tbone.rr.com [66.109.6.82]
6 27 ms 27 ms 27 ms ae-0-0.pr0.atl20.tbone.rr.com [66.109.6.171]
7 80 ms 89 ms 77 ms te0-0-0-10.ccr21.atl02.atlas.cogentco.com [154.54.12.109]
8 80 ms 78 ms 79 ms be2052.mpd21.atl01.atlas.cogentco.com [154.54.40.249]
9 92 ms 91 ms 87 ms te0-0-0-7.mpd21.dca01.atlas.cogentco.com [154.54.28.197]
10 94 ms 94 ms 98 ms te0-7-0-14.ccr21.jfk02.atlas.cogentco.com [154.54.41.6]
11 114 ms 112 ms 113 ms be2108.ccr21.ymq02.atlas.cogentco.com [154.54.3.134]
12 69 ms 69 ms 78 ms 38.122.42.34
13 69 ms 78 ms 68 ms 10.2.2.1
14 116 ms 67 ms 68 ms 192.34.76.2
15 70 ms 68 ms 67 ms 199.91.189.234
16 69 ms 68 ms 79 ms 199.91.189.74
Trace complete.
154.54.12.109 (Washington, DC: http://myip.ms/info/whois/154.54.12.109)
154.54.3.134 (Washington, DC: http://myip.ms/info/whois/154.54.3.134
Interesting to note that both traces to different servers both had issues in the same subnet, that happen to fall under the same goup. Here's the ARIN info for the entire subnet (154.54.0.0 - 154.54.255.255)--and it is NOT Square-Enix at fault here:
http://whois.arin.net/rest/net/NET-154-54-0-0-1/pft
It's under Cogent Communications, and PSINet, Inc., out of WASHINGTON... NOTHING to do with Square-Enix.
I myself have already forwarded tracerts and such to the Tech and Admin emails I have found for some of their IP's that have been posted in other threads, but have not received a response (didn't really expect to, but I had to try), as well as forwarded details to TWC's NOC and others. A handful of others have taken up this fight as well, and started submitting traces to their ISP's and documented offenders.
But, just a handful of people isn't going to cut it. EVERYBODY needs to get pro-active with this fight.
Load resmon, expand the TCP Connections section to get the actual active IP of your Canadian server (the 124 address is JP, and is idle for the most part once in game). Run traces to it, noting the failing segment and forward the details it to your ISP, noting the name of the group that is responsible for your troubled segments (you can go to www.arin.net and search the IP address to get the report I linked above). You can also go one step further and submit a ticket to SE with the trace and deatils of the failing segment as well, just in case. But, your ISP is the one who may actually have the power to ultimately change your routing, or at the very least perhaps to lean on the ones actually responsible for correcting the problems occurring in route. This may seem like only half the battle, but it is a MAJOR problem that needs to be addressed... not to mention it takes SE's stance of blaming the ISP's off the table if we can clean up the routing problems.
the amount of subs lost because of this should give SE something to think about lol
I appreciate the informative post you made there Raist thank you. Thing is I made a computer (not cheap) and bought an online ce mmo 2 years ago. I pay for the best internet service I can get (once again, not cheap) and paid for 90 service ahead of time, next couple of days after that gameplay goes titsup on me. Once again thanks for the info but I've already done my part and paid my price, I won't be doing SE's and my ISP's job too so I guess I will be waiting and letting my money go to waste /shrug
Hi Raist, thank you again for the info about this, you keep saying it is not SE's fault, I can understand that, but is it really not their fault? plenty of players have no such issue playing other MMOs with the very same ISP they have at home/work, ONLY happen with ARR, why is that?? is it because that SE placed their data center that is handling both NA and EU player base in Montreal? If so, how is this not their fault?? do you think if they had put one data center inside US, and one in EU, would people have the same routing issue?
The problem is, if everyone relies on someone else to contact the people who can actually effect a solution to the problem and just gripes and complains to those who can't do anything to fix it.... it may never get resolved.
It's almost like the non-voter complaining about what their elected officials are doing...
If there is a problem with my motorcycle I will fix it myself because I know how to do it. If there is a problem with my internet I pay someone else to fix it because I know nothing about network stuff. I'm not complaining, I said I would wait, I am patient. I would be glad to pay someone that know how to fix this or wait until someone on these forums for instance figures out exactly what to do. So I'm sorry to dissapoint you sir.
Yes, and no. They could have been provided the same assurances in the US as they were in CA, and run into the same problems. Did you not notice that the problematic segments in those traces are actually in the US?
It should also be noted that these Ormuco IP's the world servers are using were formerly registered to EIDOS, which is now owned by SE. So, they more or less set this up in-house, of sorts.
http://whois.arin.net/rest/net/NET-199-91-189-0-1/pft
The thing is, once it is on SE's side, the connection appears sound---it is a group of hops between your ISP and SE's provider that is failing.
Note, that it is also affected by where you are coming from and how your ISP is routing. To date, I have had issues only ONCE since beta4 at my house. But, when I tried to hit it from a TWC Business class line only 8 minutes from my house, it went to crap. I'm in SC and on TWC Residential, routed through Charlotte, while the Business Class made a b-line for Atlanta.
These kinds of things are completely out of SE's hands, and they have no way of predicting such problems. When these problem come up outside of their network or their contracted providers, it pretty much is not SE's responsibility to resolve it. If it was something on their end, or with whom they contracted with---that's a different story. But, this particular issue does not actually fall in their court--if anything, it's on your ISP to negotiate with their routing partners to resolve it.
While it's not unreasonable to ask SE to help put pressure on the third parties once we've identified them---it's not entirely fair to outright demand they themselves fix it. The problem is... not enough people are working to actually identify where the problems are, and who is actually at fault. Everyone wants to blame SE for something for which a completely unrelated company is responsible.
We need to finger the right people to get this issue resolved.
That's just it... we have figured out what needs to be done to get it resolved. Unfortunately, it requires player participation to get the ball rolling.
In the scenario of your motorcycle, if it was something you could not fix yourself and you needed to take it to someone to fix it... just what is your course of action? Do you just call someone and say it's broke, fix it... or do you arrange to get the motorcycle to a mechanic, and describe your problems in detail, perhaps giving specific details on how to reproduce your problem?
That is what we need to do here. The tracert clearly details the problem, where it lies, and in and of itself provides clues for courses of action for your ISP to take. Without that important piece of information, all you are telling them otherwise is "my internet doesn't work right for a certain program". That does NOTHING to effectively troubleshoot/fix your problem. Providing a tracert DOES.
All I'm saying is if you aren't willing/able to participate/contribute to that solution, don't go crying foul when SE does not fix something for which they are not responsible, and also has no power to fix.
|
![]() |
![]() |
![]() |
|