Request for information: ISPs and P2P throttling

[Desmond]

- Name of ISP: Virgin Media
- Country of Residence: United Kingdom
- When does the problem occur: Pretty much all the time unless the servers are almost empty but It's far worse from around 5-6pm untill around 1am.

[Marishi-Ten]

I am definitely experiencing the 2nd issue more than the 1st. Is there a viable fix and is it something on the end of the user or is it something that SE needs to fix?

I can only speculate as to what the issue is as I don't have root access to Tata racks and Ormucos fiber.

I have no doubt that the Square is aware of the issue and that the servers going down for maintenance is, in part, to alleviate the latency spikes. Though the client is owned by Square, their servers and their fiber nodes are run by another company. The bonus to this is that Square doesn't have to field or staff techs to monitor and maintain servers. Square also doesn't have to buy servers so they save money. The drawback is when something goes wrong, they are helpless to actually correct the issue. All they can do is field master tickets on Tata and Ormuco CRM databases.

The maintenance scheduled for 9/11/13 is quite long. This actually tells us that there is going to be hardware changes and upgrades. 2-3 hour maintenance are more software (client) side. 8-12 hours signifies that hardware on the MPLS and servers are being modified.

If the fix today doesn't correct the issues users are seeing, there are a couple of things to try:

1.) If using wifi, attempt to hardline the connection. Does the congestion clear up?

2.) Be sure to open and forward the ports Square has detailed in a stickied thread in the tech support Forums.

3.) You may clear the issue using a third party program such as PingZapper or the like. I prefer to not use this method. Using a third party program leaves you at the mercy of the program and the company who services it. This is a band aid for the root problem. You would essentially be treating the symptom, not curing the disease.

4.) VPN's have been reported to help clear the issue. This is a gamble as VPN's work just like Tata does. Multiple users and the connection slows down and lags. The VPN may be able to re route you on a different route path essentially avoiding the high traffic data centers and ports.

Verizon DSL, Baltimore, Maryland

I had posted in here previously, reposting to add some ping and tracert info.

Lag started Friday, has continued since then. I can be all by myself with no one in visual range, I can be solo questing and fighting a mob, sitting in town, or in the Duty Finder and I will lag. At all times during the day. Got 90000'd a couple of times Friday in addition to the lag, but no disconnects since then, just strange inconsistent lagging. *VERY* small periods of normal gameplay, and then BAM.

Microsoft Windows [Version 6.2.9200]
(c) 2012 Microsoft Corporation. All rights reserved.

C:\Users\Jason>ping 184.107.107.176

Pinging 184.107.107.176 with 32 bytes of data:
Reply from 184.107.107.176: bytes=32 time=60ms TTL=53
Reply from 184.107.107.176: bytes=32 time=138ms TTL=53
Reply from 184.107.107.176: bytes=32 time=77ms TTL=53
Reply from 184.107.107.176: bytes=32 time=63ms TTL=53

Ping statistics for 184.107.107.176:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 60ms, Maximum = 138ms, Average = 84ms

C:\Users\Jason>ping 184.107.107.176

Pinging 184.107.107.176 with 32 bytes of data:
Reply from 184.107.107.176: bytes=32 time=60ms TTL=53
Reply from 184.107.107.176: bytes=32 time=61ms TTL=53
Reply from 184.107.107.176: bytes=32 time=61ms TTL=53
Reply from 184.107.107.176: bytes=32 time=61ms TTL=53

Ping statistics for 184.107.107.176:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 60ms, Maximum = 61ms, Average = 60ms

C:\Users\Jason>tracert 184.107.107.176

Tracing route to 184.107.107.176 over a maximum of 30 hops

1 <1 ms <1 ms <1 ms dslrouter.westell.com [192.168.1.1]
2 33 ms 34 ms 31 ms 10.4.42.1
3 32 ms 64 ms 34 ms G0-9-4-0.DLLSTX-LCR-22.verizon-gni.net [130.81.1
94.190]
4 33 ms 33 ms 33 ms so-1-1-0-0.RES-BB-RTR1.verizon-gni.net [130.81.1
99.2]
5 72 ms 34 ms 33 ms 0.ae1.BR3.IAD8.ALTER.NET [152.63.7.81]
6 50 ms 50 ms 50 ms ix-20-0.tcore1.AEQ-Ashburn.as6453.net [66.198.15
4.53]
7 60 ms * 67 ms if-2-2.tcore2.AEQ-Ashburn.as6453.net [216.6.87.1
]
8 66 ms 67 ms 61 ms if-11-2.tcore2.NJY-Newark.as6453.net [216.6.87.1
38]
9 59 ms 62 ms 60 ms if-4-4.tcore2.NYY-NewYork.as6453.net [66.198.111
.18]
10 60 ms 61 ms 67 ms if-2-2.tcore2.MTT-Montreal.as6453.net [64.86.226
.13]
11 62 ms 82 ms 62 ms if-0-2.tcore1.MTT-Montreal.as6453.net [216.6.115
.89]
12 63 ms 228 ms 153 ms 64.86.31.42
13 61 ms 62 ms 109 ms te8-3.dr10.mtl.iweb.com [67.205.127.238]
14 62 ms 60 ms 60 ms 72.55.128.44
15 64 ms 63 ms 62 ms 184.107.107.176

Trace complete.

EDIT: Saw mention of a program called Ping Zapper in a locked lag thread, tried it, and it does indeed work (at least for me). Downloaded, installed, and set up. 30 mins straight of lag-free playing. Logged off and closed Ping Zapper, and then logged back on. Immediate lag. Ran Ping Zapper again, launched XIV, lag-free. It's on a trial account at the moment, which limits you to 1 hour of game time before it stops working. I don't know if that's "1 hour, stops working, close program and reopen and it works fine", or "1 hour every 24 hours". I'd assume the latter, but I don't know. Don't have the time to test the trial account limit because I need to get some sleep before I go to work. But Hallelujah, it works flawlessly. If I lagged during my time using it, I could not tell. I'll see if tonight's maintenance fixes the problem, and if not, I'll be buying some prepaid Ping Zapper time tomorrow. My RAAAAAAAAAGE at having to possibly pay for a 3rd party tunneling program to make this game playable is mostly tempered by the fact that it's pretty damned cheap, and I'm still on my free time. Of course, tomorrow, if the lag persists outside of using it, I'll be dropping the four bucks for 30 days of Ping Zapper time; however, I can't say that I'll be completely happy doing it.

I had a few questions about your data. Are these polls before or after PingZapper? The reason I ask is that you have an extra hop through a data center that I haven't seen on any trace routes I've found on the Forums:

13 61 ms 62 ms 109 ms te8-3.dr10.mtl.iweb.com [67.205.127.238]

This data center is run by iweb: http://iweb.com/about/vision

I haven't seen this hop on either my own, or others trace routes. I've also noticed that your ping times are relatively low and are pretty close together (60-120ms). I wonder if this is because of the scrubber, or if you're routing through another data center that Square may have picked up.

Name of ISP: Verizon FiOS
Character name: Yuengling Light
Country of Residence: Fairfax County, Northern Virginia, United States

Same issue. Constant 5 second freezes.

I've isolated the issue down to one of these hops:

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

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


I tried getting Verizon to look into it, but they are blaming the "game provider". (0)

Verizon, though meaning well, is inaccurate in stating the issue is with the Game Provider. Looking over your parsing data, I see that you have low ping times. I don't see a whole lot of fluctuation. What I do see is the glaring time out requests. Your connection to the server port (Tata) is either congested or is dropping due to load. Yours is an excellent example of how the server you're connecting to behaves when congested or not specd to handle the amount of volume it's seeing.

Your issue unfortunately cannot be corrected by any via client side means. This is an issue with the actual server load and shows that the racks are congested and cannot negotiate with the amount of users it sees at this time. Until the server provider expands the servers (partition/addition) and redistributes the port assignments, the issue will persist.

Apologies for the long post!

[TyrsofFayt]

ISP: TalkTalk
Country of Residence: UK
Occurrence: At random times through out the day, everyone else disappears and I'm left waiting for anything from 5 secs to 5 mins for it to return to normal

[Hestern_Nestern]

I believe I am also experiencing these issues.

- Name of ISP: At&t
- Country of Residence: United States
- When does the problem occur: Always (but, I suspect, to a lesser degree than some).

[XxSlyfox]

- ISP = Frontier Communications
- Washington State USA
- Every hour i get the 90000 error.

[NeoJason]

- ISP = AT&T
- Texas, USA
- every hour or two I disconnect with 90000, and constant lag in the instances

[Eshin]

- ISP = Verizon Fios
- Virginia, USA
- Always

Edit: No reference number since last time I called, I was met with a rude, aggressive representative. Didn't sound like he did anything besides throw information I already knew back at me. Gotta love customer service.

This issue is making me look like a less fantastic tank. :S Been going on since launch.

[Abrasumente]

- ISP = Comcast Cable
- Washington, USA (Seattle / Tacoma area)
- Every 6 or so hours
- Extent of problem: Every 6 or so hours I am receiving error 90,000. This is especially inexcusable during dungeons and HM primals. Currently: I have been getting disconnected during HM primal fights and during duty finder dungeons as well as random disconnects in the middle of FATE fights.

-Reference number: Haven't bothered, as I called and they can confirm their end is satisfactory multiple times.

Other information: I am running a mumble server hosted off of my machine. I frequently receive the error 90,000 and continually, people are connected to mumble no problem whatsoever and continue to talk while I am disconnected from FFXIV. I have contacted SE support at least 3 times with this issue and am still receiving the blatently obvious bs about "oh its your ISP." Hate to tell you SE, it sure as hell isn't.

If I'm still connected to the net, with a mumble server running, users connected, and able to browse / download files such as brushes for photoshop, etc with no problem... It's not my net. It's your service. Figure it out please. It's frequent and obnoxious.

[Yuengling]

Verizon, though meaning well, is inaccurate in stating the issue is with the Game Provider. Looking over your parsing data, I see that you have low ping times. I don't see a whole lot of fluctuation. What I do see is the glaring time out requests. Your connection to the server port (Tata) is either congested or is dropping due to load. Yours is an excellent example of how the server you're connecting to behaves when congested or not specd to handle the amount of volume it's seeing.

Your issue unfortunately cannot be corrected by any via client side means. This is an issue with the actual server load and shows that the racks are congested and cannot negotiate with the amount of users it sees at this time. Until the server provider expands the servers (partition/addition) and redistributes the port assignments, the issue will persist.

Apologies for the long post!

Verizon, though meaning well, is inaccurate in stating the issue is with the Game Provider. Looking over your parsing data, I see that you have low ping times. I don't see a whole lot of fluctuation. What I do see is the glaring time out requests. Your connection to the server port (Tata) is either congested or is dropping due to load. Yours is an excellent example of how the server you're connecting to behaves when congested or not specd to handle the amount of volume it's seeing.

Your issue unfortunately cannot be corrected by any via client side means. This is an issue with the actual server load and shows that the racks are congested and cannot negotiate with the amount of users it sees at this time. Until the server provider expands the servers (partition/addition) and redistributes the port assignments, the issue will persist.

Apologies for the long post!

Thanks for recognizing what I was actually trying to communicate. The issue isn't with Square-Enix at all, it's with an ISP someplace inbetween us and them. I dealt with this kind of crap in Iraq for a year, it's a bad cable or a overloaded device someplace no one really pays attention that has any interest in the game.

I haven't been able to isolate it, but from what I can tell, BOTH of these hops have issues. Both are TINET.net.

I've seen multiple other posts where people blame the ormuco-gw server IP, which is the same one I mention. They ARE NOT in Northern Virginia.

Logic would tell me that the tinet.net run systems are the problem.

I've had the same packet loss to both of these hops...

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]

[AndyFLHX]

http://forums.verizon.com/t5/FiOS-In...ia/td-p/622913