Players Rubberbanding

Hey guys;

I been getting this rubberbanding issue since 3 days ago. never had this problem before.

Things I have font to try fix the issue: Factory reset my pc, re-installed the game, updated nvidia drivers, replaced my etheral cable, reset router and modem and called my ISP. So far nothing seems to help with the issue. Anyone else having this problem?

Any help would be appreciated or any suggestion :( been 4 days now.

Quote:

---

Originally Posted by Uxi

Any help would be appreciated or any suggestion :( been 4 days now.

---

Network related. Try Enable/Disable UPnP on the router, open the ports required for FFXIV on the router's firewall.

I've played with some players who were rubber banding on my screen while other players weren't, usually about a minute before they disconnect.
One person posted earlier that they had installed the leatrix latency fix, which is just a script that turns off the Nagle Algorithm. If you've ever turned off Nagle in the past that could be a reason for this to happen in FFXIV, but then again, disabling Nagle should do nothing for you unless you already had less than 200ms of latency.

I have had this too where everything freezes and the speeds up. I didn't have it in beta, early launch, and didn't have it for three weeks into official launch. It started about two weeks ago. I have tried 3 different modems, opening up xiv ports, using a vpn, calling my isp numerous times, having isp technician out to replace anything he could find that might cause the problem, and changing all my internet cables to new ones.

I still get the freezing and fastforwarding. Rubberbanding. I don't know what happened two weeks ago but it makes my game play badly. It started after one of the maintenances.

Quote:

---

Originally Posted by KisaiTenshi

Network related. Try Enable/Disable UPnP on the router, open the ports required for FFXIV on the router's firewall.

I've played with some players who were rubber banding on my screen while other players weren't, usually about a minute before they disconnect.
One person posted earlier that they had installed the leatrix latency fix, which is just a script that turns off the Nagle Algorithm. If you've ever turned off Nagle in the past that could be a reason for this to happen in FFXIV, but then again, disabling Nagle should do nothing for you unless you already had less than 200ms of latency.

---

I already Installed leatrix latency and still no improvement. Also I try the UPnP and check my ports and nothing seems to fix this problem. Its seems the way my character is connecting to the servers but not sure.

Quote:

---

Originally Posted by Niko_Kishiko

I have had this too where everything freezes and the speeds up. I didn't have it in beta, early launch, and didn't have it for three weeks into official launch. It started about two weeks ago. I have tried 3 different modems, opening up xiv ports, using a vpn, calling my isp numerous times, having isp technician out to replace anything he could find that might cause the problem, and changing all my internet cables to new ones.

I still get the freezing and fastforwarding. Rubberbanding. I don't know what happened two weeks ago but it makes my game play badly. It started after one of the maintenances.

---

I also didnt have any issues at launch and in beta all started 4 days ago and is been horrible to play.

This is a video describing my issue is very very close for what I am experiencing. game Freeze for few secs then resume at super speed and keep doing it constantly.

http://www.youtube.com/watch?v=wnlaGgh6N2Q

definately looks like networking issues in route. From your accent, I'm going out on a limb and guessing you aren't actually in NA, maybe AU or EU? If so, you're fighting an uphill battle already with the ~200ms or so lag you have just getting across NA to CA, and then the high congestion and packet loss we've been seeing with a few circuits around Montreal are just amplifying it.

It may be out of your comfort zones, but if you guys can pull up resmon to get the IP's that XIV is using while in game and run some tracerts to the CA ones, then forward those traces to both your ISP and SE, we might one day actually get the right people talking to who is utlimately responsible for fixing these problems in routing. If you are unsure which ones are the CA IP's, the ones starting with 124 are the JP ones (usually only keeps two open regularly, one to CA and the other to JP).

I already check my ping to the NA server and got 83ms. Also, my partner that is next to me in hes PC (that is the exact same pc I have) is not getting any type of lag, latancy or rubberband issue. So if is connection it should affect hes, so I am very confuse of what is cousin the issue.

Quote:

---

Originally Posted by Uxi

I already check my ping to the NA server and got 83ms. Also, my partner that is next to me in hes PC (that is the exact same pc I have) is not getting any type of lag, latancy or rubberband issue. So if is connection it should affect hes, so I am very confuse of what is cousin the issue.

---

depends on just what is going on with your particular packets though. For example, Store and Forward style mechanics can wreak havoc on streamed content because of the stop and go bursting. This is a common problem with Cable subscribers. Upstream and Downstream is sort of pooled and sent in bursts at higher speeds than you are sold, paused, then sent again in bursts--in the end it averages out to the promised speeds, but it may actually be running in short, staggered bursts at 3x the average speed. When you compound this with what is known to be an off and on issue with overloaded network segments and packet loss issues, it just makes it a big mess. You can visualize this as watching a video online, and it constantly skips/stutters or frequently stops to buffer the video. A similar thing happens all the time with your connection in a game like this, but is usually not noticeable under good conditions. When they take a nose dive in quality like we've seen and documented to be happening in the last couple of weeks, it is much more noticeable and becomes more like a long pause to buffer the video every 40 seconds.

To see the signs better, you need to be running a trace and not a ping. This stands a better chance of you seeing where the problem may be cropping up in route. For instance, look at this trace:

Quote:

---

Tracing route to 199.91.189.74 over a maximum of 30 hops

<early hops removed for security>

4 24 ms 23 ms 21 ms xe-7-0-0.chrlncpop-rtr1.southeast.rr.com [24.93.64.42]
5 31 ms 31 ms 30 ms bu-ether14.atlngamq46w-bcr00.tbone.rr.com [66.109.6.82]
6 37 ms 27 ms 27 ms ae-0-0.pr0.atl20.tbone.rr.com [66.109.6.171]
7 78 ms 77 ms 80 ms te0-0-0-10.ccr21.atl02.atlas.cogentco.com [154.54.12.109]
8 80 ms 81 ms 77 ms be2050.ccr21.atl01.atlas.cogentco.com [154.54.0.165]
9 91 ms 86 ms 84 ms te0-3-0-2.ccr21.dca01.atlas.cogentco.com [154.54.2.46]
10 95 ms 91 ms 96 ms te0-7-0-14.ccr21.jfk02.atlas.cogentco.com [154.54.41.6]
11 113 ms 112 ms 114 ms be2108.ccr21.ymq02.atlas.cogentco.com [154.54.3.134]
12 77 ms 68 ms 69 ms 38.122.42.34
13 70 ms 68 ms 69 ms 10.2.2.1
14 68 ms 68 ms 69 ms 192.34.76.2
15 70 ms 69 ms 69 ms 199.91.189.234
16 70 ms 70 ms 68 ms 199.91.189.74

Trace complete.

---

That is actually a GOOD trace... one that some would kill to be getting these days during the week, much less on a Saturday afternoon. But notice the ramped up delays in the middle in the cogentco segments, and the peak at hop 11, and then how it drops back down afterwards as it gets to towards the Ormuco endpoint (SE's segments). When the connection is in trouble, these cogentco legs might triple or even break 400ms (nearly 1/2 a second)--or flat out time out. Earlier this week, some people actually experienced a triple-star event---where hops completely timed out and had to be retried completely.

What we have been seeing is when the connection gets up around the CA/US border, or up into the Montreal area, the delays either shoot through the roof or they get starred out because of time-outs. Three names have shown up most frequently as having these problems. While Congent and i-Web often actually have their group names in the router's published names, TATA doesn't typically have it published in the name. Some of the i-web ones will be "masked"like this sometimes as well. In order to find out who manages them, we sometimes have to run a whois and find the owners registered with ARIN and such.

The point is, we have been able to document and report to administrators at the endpoints (our ISP and SE) that there are segments managed by certain groups that are indeed exhibiting dramatic increased lag and packet loss in our routing paths. This is not the be-all-end-all fix, but it is an important part of the puzzle. Unfortunately, it is not something that SE can research--they can't trace what is happening between each and every one of us and their servers (well, not realistically, that is). They need someone to provide that information for them--best way to get that is for the players to run a trace and pass it along.

That is about all we can do to help remedy this particular aspect of our communication problem--SE can't fix the routing (your ISP may be able to nudge you around a different way though, depending on various elements in play). But one thing that can be done, is either SE or your ISP (or both) can try to put pressure on the admin's for those segments to clean up their acts and provide more stable transmission for us. In order to do that though, they need to know where they need to focus such pressure... hence we need the trace logs.

The more traces we can provide, the better our chance at getting at least this part of our problems resolved.

I too have been getting lag issues I've never noticed before. I started noticing it on mon/tuesday. Waiting for ISP guy to come out and see if it fixes anything.

Lag issues seem to be server side. The problem only crops up during high traffic times of the day for me. It's a shame really, because I'm going to need to quit the game if it isn't resolved.

Tracing route to 184.107.107.176 over a maximum of 30 hops

4 * * * Request timed out.
5 10 ms 12 ms 10 ms 12.87.224.46
6 69 ms 41 ms 65 ms 12.87.224.45
7 54 ms 67 ms 55 ms 12.122.157.142
8 61 ms 59 ms 67 ms 12.122.157.129
9 57 ms 58 ms 88 ms attga04jt.ip.att.net [12.122.84.149]
10 108 ms 52 ms 52 ms 192.205.36.218
11 97 ms 87 ms 88 ms if-25-2.tcore1.aeq-ashburn.as6453.net [64.86.113
.2]
12 * 92 ms 91 ms if-2-2.tcore2.aeq-ashburn.as6453.net [216.6.87.1
]
13 89 ms 92 ms 103 ms if-11-2.tcore2.njy-newark.as6453.net [216.6.87.1
38]
14 77 ms 79 ms 81 ms if-4-4.tcore2.nyy-newyork.as6453.net [66.198.111
.18]
15 97 ms 95 ms 94 ms if-5-2.tcore2.mtt-montreal.as6453.net [216.6.99.
30]
16 90 ms 98 ms 93 ms if-0-2.tcore1.mtt-montreal.as6453.net [216.6.115
.89]
17 117 ms 130 ms 90 ms 64.86.31.42
18 89 ms 86 ms 89 ms te8-3.dr10.mtl.iweb.com [67.205.127.238]
19 107 ms 96 ms 91 ms 72.55.128.44
20 104 ms 93 ms 106 ms 184.107.107.176

Trace complete.

Heres my trace for NA datacenter, idk if this will help to help my issue btu I do hope so.

Quote:

---

12 * 92 ms 91 ms if-2-2.tcore2.aeq-ashburn.as6453.net [216.6.87.1]

---

Looks like you're routing through TATA segments, and like others who are having issues with them, it's getting flaky when you get up around Montreal:

http://216.6.87.1.ipaddress.com/

Keep in mind, this is only a part of the problem. There are things SE needs to address in their local networking and server infrastructures, but this is another element that is combining with them to make things potentially much worse, and can and should be addressed by the parties responsible for the failing segments---we just need an advocate to lean on them to fix things (be that our ISP's collectively pressuring them, or SE).