Originally Posted by
Ervin
@Raist: All other games work perfectly fine with zero lag for most of us that have XIV lag issues. Why should we have to try and fix this on our own when we pay SE monthly to keep things like this is check. This isnt some F2P game where the company can do it at their own pace. This is a sub-fee game where customer service aswell an a smoothly working product is a must. Still both of those things are clearly lacking here.
1. Engine isnt optimized, some zones have terrible issues.
2. EU dont have their own servers, but we pay just as much each month as the JP and US but we get worse preformance. Even without the nighttime lag, we still have delay compared to JP/US players.
3. Lack of CSR communication, both in-game and on forums.
There is nothing to justify SE ignoring these issues since they get our money to solve these things. Currently this game works worse than some F2P or B2P MMOs out there and still they want 11 Euro per month... SE should just man up and give the EU their own Datacenter. It would take the stress off the NA datacenter and solve many lag issues for the EU playerbase.
I'm currently at the edge myself, thinking strongly about quitting. When you pick an sub-fee game you expect it to have a sub-fee game prefomrance like EQ/WoW/DaoC etc had and not be below the current F2P level of preformance.
<and other posters here and in other threads that may not fully understand what I was talking about>
Not sure some of you are grasping just how much routing can vary, and why it may very well be affecting only your FFXIV play (or maybe just a handful of games), but not all games and/or other internet activity. Your routing changes based on the routing policies/agreements amongst all the various ISP's across the regions you must cross to get to your requested endpoint. Perhaps this may help illustrate it better:
I am located in South Carolina, roughly an hour from the the East Coast (about 70 Minutes inland from North Myrtle Beach)
Trace to the server I connect with when I play on Midgard: 199.91.189.74, based in Montreal Canada
http://myip.ms/info/whois/199.91.189.74
Code:
Tracing route to 199.91.189.74 over a maximum of 30 hops
<Initial hops removed for security>
4 28 ms 27 ms 27 ms xe-7-0-0.rlghncpop-rtr1.southeast.rr.com [24.93.64.40]
5 35 ms 36 ms 32 ms 107.14.19.44
6 31 ms 31 ms * so-1-1-1.c1.buf00.tbone.rr.com [66.109.1.113]
7 33 ms 31 ms 52 ms ix-17-0.tcore2.AEQ-Ashburn.as6453.net [216.6.87.149]
8 84 ms 84 ms 83 ms if-2-2.tcore1.AEQ-Ashburn.as6453.net [216.6.87.2]
9 82 ms 81 ms 140 ms 64.86.85.1
10 87 ms 85 ms 84 ms if-10-2.tcore1.TTT-Scarborough.as6453.net [64.86.32.33]
11 82 ms 83 ms 84 ms if-9-9.tcore1.TNK-Toronto.as6453.net [64.86.33.25]
12 132 ms 117 ms 80 ms if-7-2.tcore1.W6C-Montreal.as6453.net [66.198.96.61]
13 92 ms 83 ms 89 ms 66.198.96.50
14 80 ms 78 ms 79 ms 192.34.76.2
15 86 ms 86 ms 85 ms 199.91.189.234
16 87 ms 85 ms 81 ms 199.91.189.74
Trace complete.
***Note that this routing has recently changed for me. We have been reporting issues to both our ISP's, and the ISP's we've detected having problems in routes. I used to be using Cogent in the middle of my routes, but am now on TATA. Just this weekend, I was shooting all the way to LA and going up, a couple weeks ago it was Seattle, before that, DC. The ISP's, NOT Square Enix, have been experimenting a lot trying to resolve the issues for us. Others have also noticed changes in their paths recently too.***
Now, here's another sample trace to another IP in that SAME subnet, that I've seen others use for testing against their FFXIV Connection: 199.91.189.58
http://myip.ms/info/whois/199.91.189.58
Code:
Tracing route to 199.91.189.58 over a maximum of 30 hops
<initial hops removed for security>
4 26 ms 27 ms 27 ms 24.93.64.128
5 37 ms 31 ms 31 ms 107.14.19.42
6 46 ms 31 ms 41 ms ae-4-0.a0.lax91.tbone.rr.com [66.109.1.113]
7 30 ms 32 ms 31 ms ix-17-0.tcore2.AEQ-Ashburn.as6453.net [216.6.87.149]
8 99 ms 85 ms 86 ms if-2-2.tcore1.AEQ-Ashburn.as6453.net [216.6.87.2]
9 95 ms 94 ms 86 ms 64.86.85.1
10 86 ms 87 ms 86 ms if-10-2.tcore1.TTT-Scarborough.as6453.net [64.86.32.33]
11 87 ms 96 ms 109 ms if-9-9.tcore1.TNK-Toronto.as6453.net [64.86.33.25]
12 87 ms 84 ms 83 ms if-7-2.tcore1.W6C-Montreal.as6453.net [66.198.96.61]
13 86 ms 86 ms 84 ms 66.198.96.50
14 87 ms 85 ms 85 ms 192.34.76.2
15 107 ms 86 ms 88 ms 199.91.189.234
16 85 ms 95 ms 85 ms 199.91.189.58
Trace complete.
Noticed what happened to my path right out the gate through hops 4,5, and 6. That is right after leaving my local segment, still under my ISP's control. I am being routed to the same exact TATA router, but I am taking a slightly different path from my modem to that point in Virginia. Something in my ISP's policies is causing that to happen--NOT SE.
Note also there was an intermittent time out at one of the TWC/RR hops. There may be a congestion issue closer to home than to SE.
Now, lets look at the routing from this same system to a couple of Blizzard's servers used for WoW and D3. I am not playing these games. The IP's are pulled from one of their own support articles I got a hit on when I googled for them:
https://us.battle.net/support/en/art...g-a-traceroute
Only using them as examples to further illustrate how easily routing can vary.
WoW IP in Sandiego, CA: 63.240.161.189
http://myip.ms/info/whois/63.240.161.189
Code:
Tracing route to 63.240.161.189 over a maximum of 30 hops
<initial hops removed for security>
4 29 ms 27 ms 27 ms ge-3-0-0.rlghncpop-rtr1.southeast.rr.com [24.93.64.60]
5 36 ms 35 ms 43 ms ae-3-0.cr0.dca10.tbone.rr.com [66.109.6.80]
6 33 ms 31 ms 31 ms ae0.pr1.dca10.tbone.rr.com [107.14.17.200]
7 33 ms 36 ms 39 ms ix-17-0.tcore2.AEQ-Ashburn.as6453.net [216.6.87.149]
8 34 ms 32 ms 35 ms 192.205.34.245
9 77 ms 75 ms 77 ms cr2.wswdc.ip.att.net [12.122.134.186]
10 75 ms 75 ms 79 ms cr1.cgcil.ip.att.net [12.122.18.21]
11 72 ms 71 ms 70 ms gar18.cgcil.ip.att.net [12.122.99.21]
12 75 ms 76 ms 74 ms 12.122.251.14
13 69 ms 81 ms 71 ms 63.240.130.202
14 * * * Request timed out.
15 * * * Request timed out.
<stopped the trace, as it appears the final IP may be set to not respond to ICMP echo request>
WoW and D3 IP in Long Beach, CA: 12.129.209.68
http://myip.ms/info/whois/12.129.209.68
Code:
Tracing route to 12.129.209.68 over a maximum of 30 hops
<Initial hops removed for security>
4 24 ms 27 ms 27 ms 24.93.64.128
5 34 ms 31 ms 31 ms 107.14.19.44
6 31 ms 35 ms 30 ms ae1.pr1.dca10.tbone.rr.com [107.14.17.202]
7 32 ms 66 ms 32 ms ix-17-0.tcore2.AEQ-Ashburn.as6453.net [216.6.87.149]
8 36 ms 35 ms 32 ms 192.205.34.245
9 93 ms 95 ms 104 ms cr2.wswdc.ip.att.net [12.122.134.186]
10 93 ms 96 ms 95 ms cr1.cgcil.ip.att.net [12.122.18.21]
11 92 ms 96 ms 96 ms cr2.dvmco.ip.att.net [12.122.31.85]
12 95 ms 95 ms 95 ms cr1.slkut.ip.att.net [12.122.30.25]
13 97 ms 96 ms 95 ms cr2.la2ca.ip.att.net [12.122.30.30]
14 90 ms 92 ms 92 ms gar20.la2ca.ip.att.net [12.122.128.181]
15 93 ms 92 ms 92 ms 12.122.251.190
16 93 ms 92 ms 92 ms 206.16.68.46
17 * * * Request timed out.
18 * * * Request timed out.
<again, stopped trace as the final IP may be set to not respond to ICMP echo request>
Notice, how once again, my initial routing at my ISP's level was adjusted slightly at the start--right after leaving my local segment.
Again, that is MY ISP making that election, NOT Blizzard.
Note how long the FFXIV trace stays within TATA's control all the way up into Montreal, while the Blizzard traces quickly get handed off to AT&T's networks after just a couple hops on TATA's segments. The FFXIV trace stayed in TATA's control for a space of 6 hops versus 2. In contrast, the Blizzard one was in ATT's control for the last 5 or more hops to Blizzard's network, compared to the last 2 or 3 segments that the SE traces are on Ormuco and/or SE's segments.
As noted at those links with detailed info on the traces IP's... the ISP managing SE's service is Ormuco, while Blizzard is using AT&T.
That extra ISP in the middle, TATA, with the as6453.net addresses is one of the groups where we have been seeing a LOT of problems crop up in route. It's not just XIV either. They are known offenders going back several years for many online games. My routing for XIV is using considerably more TATA segments then the ones for Blizzard. Considering TATA is one of the groups identified for having packet loss issues during high traffic, that means there is a much higher chance for me to hit a troubled segment with them. It should be noted also that it's not just TATA at fault here, they are just one of many that are having issues, and not isolated to one area either. But, it does however seem to be limited to a small group of ISP's having the most trouble keeping things stable.
All of this differs simply because of the routing policies/agreements in place amongst the different ISP's involved. The ISP's are altering the routing in between as they try to shape the traffic to avoid high congestion or other potential failures. The problem is that we are seeing some of these groups appearing to flat out fail at that task, and we are seeing high packet loss or delays on their segments. This has a profound impact on the game's performance because of how error detection/correction is working on the networks. High packet loss and/or extensive delays causes a high retransmit rate, which severely delays the delivery of data. Keep in mind those errors/retransmits can happen in both directions too (client>server as well as server>client).
The higher concentration of the use of these flaky routers simply causes us to be at greater risk for problems.
THAT is why it is important to report the specifics on this issue when it is detected. We don't readily have a line of communication to these third parties (have to know where to dig it up). However, your ISP and/or SE's ISP may not only have contact info, but might have contracts with them. Have to understand that those third parties profit from their agreements with other ISP's--like your ISP and SE's ISP. Your ISP (as well as SE's) might be profiting as well because they are cheap to use. But, if it is impacting QoS and by extension Customer Satisfaction, then the affected ISP (again, yours and/or SE's) may gain the power to lean on groups like TATA and Cogent to clean up their act or risk loosing business. That can make this a very actionable situation IF you report the right info to the right people.
Again, even if everything were running perfect at SE's end, you can still have massive lag and such because of these issues that are occuring in route. It actually creates a problem for SE to properly diagnose the problem, as they can't verify for sure if any adjustments made on their end fix a problem when testing is so negatively affected by these problems in route to their servers and/or back to your client.
Now, as to the issue of whether users should bother gathering a quick trace and submitting it in a bug report to your ISP and SE, here's a real world example for you to consider:
Take your car to a dealership, hand a service adviser your keys and simply say "It's broke, fix it.", then turn around, walk off, get in your friends car and ride off. Don't say anything else--don't answer any questions, don't give any details on just what is wrong, don't even give them your cell phone number to contact you once they find something. Just drop off the car, the keys, say "it's broke, fix it", and leave.
Now, what is your reaction if you return a few hours later and they haven't done anything to your car? Or maybe they were so bold as to replace your cracked CV boots, but haven't fixed your particular problem?
That is more or less what is happening in a lot of these threads.
The proper way to get your car fixed is to provide as specific a description as you can on what is wrong. Things like when you notice it, specifically what you notice--you may even be able to tell them how to duplicate it so they can more effectively diagnose your specific problem.
That is what providing something like a simple tracert does. It can potentially finger the who, what, when, where of the situation, and might even capture an actual point of failure for them to start from.
Simply coming into a user forum and crying about it being broke and how SE needs to fix it really may not get you anywhere unless it's something the users can advise you on how to correct it. In the scope of these problems, if you provide some useful information on your problem, it MIGHT get forwarded up the chain, but ultimately you really need to file a proper bug report if you truly expect some action to be taken on this specific problem.
Reply With Quote
