Request for information: ISPs and P2P throttling

Quote:

---

Originally Posted by june23

This issue went away for 3 days after the major patch. It then came back. Unplayable. Connection is still unstable at all time of the day. Now I am getting more 90000 error than before.

http://i271.photobucket.com/albums/j...nine/ffxiv.png

---

Having the same results as you, but with Brighthouse

ISP: Xfinity/Comcast
Location: Washington, United States
Frequency/Time: Constantly

- Comcast
- Shreveport, LA
- Lately (since Saturday) all times
Thought the problem was fixed after the update. However, problems with 90000 (constant problems) suggest otherwise

ISP: Telmex
Country: Mèxico
Time of occurrence: Always
Modem reset and no throttling advise from isp

SE give a specific response to this. People stop playing this game with them and demand action, it's not the ISP's, it's them.

ISP: TeliaSonera
Location: Finland
Frequency: after 30 minutes to 1 hour the game stops responding.

I've been working with my ISP (Time Warner Cable) since FFXIV release. I get disconnected usually about 30min to 1hr (some days it is worse, like today).

One of the tests I did was to tracert to the FFXIV server. I then ping'd the first IP past my gateway (a TWC internal IP). Whenever I disconnect from the game (90000) I see about 1-4 "request timed out" in the command log. Which makes me think it is an ISP issue. But! I ran this test while connected to the game server for about 12 hours. I lost about 1.5% of packets. However, after I shut down the game, I lose about 0.2% of packets. Not sure what is up with that...

Another thing, in FFXI, when your connection was spotty, you'd go "LD/redball" for 60 seconds before the game server would kick you. Here in FFXIV? Seems like it is 1-2 seconds before disconnect. Quick patch on their end would be to extend the "disconnect timer."

- Name of ISP
- Country of Residence
- When does the problem occur (always, only during specific times?)
- Reference number from your ISP, if you raised this matter with them

NBS Maxiis (Contact: 888-994-8823 :: http://www.nbson.com/contact.html )
United States
During Instanced Duties - 90k - Somewhat random, but always during duties (time range of 1-20 minutes typically I get DCed)
No Ticket number from ISP.

Time Warner Cable
Ohio, US
Always

Charter Communications
United States
Intermittently (Especially in heavily congested areas such as the Odin and Behemoth FATES)

Name of ISP - Telstra Bigpond
Character name: Jin Marlfox
Country of Residence - Australia
When does the problem occur (always, only during specific times?) - Always
Reference number from your ISP, if you raised this matter with them - Was not given one.

ISP - Telmex
Country - Mexico
When does the problem occur - Everyday after 5p.m.

I ran a traceroute and several pings (getting a 20% loss on peak hours) and i found that the packets get lost on the Tata Comunications segment


1 79 ms 99 ms 98 ms dsldevice.lan [192.168.1.254]
2 60 ms 12 ms 12 ms dsl-servicio-l200.uninet.net.mx [200.38.193.226]

3 47 ms 47 ms 48 ms bb-dallas-bryan-10-tge0-14-0-9.uninet.net.mx [20
1.125.112.158]
4 58 ms * 57 ms ix-7-3-0-0.tcore2.DT8-Dallas.as6453.net [206.82.
142.25]
5 * * * Tiempo de espera agotado para esta solicitud.
6 146 ms * 154 ms if-3-2.tcore1.PDI-PaloAlto.as6453.net [66.198.12
7.25]
7 162 ms 145 ms 145 ms if-1-2.tcore1.NYY-NewYork.as6453.net [66.198.127
.6]
8 146 ms 145 ms 146 ms if-11-2.tcore2.NYY-NewYork.as6453.net [216.6.99.
1]
9 146 ms 145 ms 145 ms if-2-2.tcore2.MTT-Montreal.as6453.net [64.86.226
.13]
10 179 ms 146 ms 145 ms if-0-2.tcore1.MTT-Montreal.as6453.net [216.6.115
.89]
11 145 ms 145 ms 144 ms if-5-2.tcore1.W6C-Montreal.as6453.net [64.86.31.
6]
12 144 ms 144 ms 146 ms 66.198.96.50
13 * 148 ms 145 ms 192.34.76.2
14 * 145 ms * 199.91.189.234
15 144 ms 145 ms 144 ms 199.91.189.74

It's hard to say where their instance servers are actually located. I've done some snooping around and I have found some information. Looking over the data I was able to acquire, it looks like Square rents its server space. There seems to be massive latency originating on the Seattle, Chicago, and Montreal (end point) hops owned by as6453.net, which are owned by Tata Communications. Their switches are showing quite of bit of slow down, (220ms+ latency) which in turn is causing more slow down and bottlenecking at the Montreal hops.

Tata Communications are a T1 telecomm in India, but they are at best a T3 in the US. I can't seem to find what T1 is hosting them in the US. If we can find who the backbone they are running through (AT&T, Century Link, Cogent, Level3, NTT, Savvis, SBC, Sprint, Verizon, XO) we can either field our own trouble tickets with them or we can contact our ISP's and request they avoid routing through their hubs.

If servers are being rented though Tata, then we can't reroute around them. We essentially have to deal with the latency until they redistribute their I/O paths or upgrade their switches.

Alternately, it could also be a problem with their MPLS circuits (hosted through Ormuco) reaching maximum bandwidth and causing latency.

The root issue more than likely lies between the two making it difficult to field any fix in a timely manner.

In short, it looks like Square doesn’t own the servers that are housing the North American and European worlds. This combined with the amount of traffic that their host is seeing is causing the latency issues.

3 184.99.64.201 (184.99.64.201) 18.925 ms 17.211 ms 17.251 ms
4 boid-agw1.inet.qwest.net (184.99.65.65) 23.503 ms 17.396 ms 36.997 ms
5 sea-brdr-02.inet.qwest.net (67.14.41.18) 44.756 ms 31.634 ms 37.997 ms
6 ix-1-0-0-0.tcore1.00s-seattle.as6453.net (64.86.123.77) 52.807 ms 304.980 ms 293.516 ms
7 if-0-0-0-2.core1.00s-seattle.as6453.net (64.86.123.2) 463.000 ms 294.448 ms 256.501 ms
8 if-9-3-3-0.tcore2.ct8-chicago.as6453.net (64.86.124.34) 323.445 ms 142.922 ms 96.168 ms
9 if-3-2.tcore1.w6c-montreal.as6453.net (66.198.96.45) 95.991 ms 96.259 ms 95.309 ms
10 66.198.96.50 (66.198.96.50) 99.636 ms 99.195 ms 99.700 ms
11 192.34.76.2 (192.34.76.2) 99.474 ms 98.574 ms 99.333 ms

whois 199.91.189.38
Ormuco ORMUCO-FIBER-NETWORK (NET-199-91-184-0-1) 199.91.184.0 - 199.91.191.255
Eidos ORMUC-SE (NET-199-91-189-0-1) 199.91.189.0 - 199.91.189.255

64 bytes from 199.91.189.38: icmp_seq=290 ttl=243 time=101.808 ms
64 bytes from 199.91.189.38: icmp_seq=291 ttl=243 time=101.363 ms
64 bytes from 199.91.189.38: icmp_seq=292 ttl=243 time=320.852 ms
64 bytes from 199.91.189.38: icmp_seq=293 ttl=243 time=422.690 ms
64 bytes from 199.91.189.38: icmp_seq=294 ttl=243 time=422.983 ms
64 bytes from 199.91.189.38: icmp_seq=295 ttl=243 time=484.630 ms
64 bytes from 199.91.189.38: icmp_seq=296 ttl=243 time=424.351 ms
64 bytes from 199.91.189.38: icmp_seq=297 ttl=243 time=445.440 ms
64 bytes from 199.91.189.38: icmp_seq=298 ttl=243 time=101.748 ms
64 bytes from 199.91.189.38: icmp_seq=299 ttl=243 time=101.246 ms

64 bytes from 199.91.189.38: icmp_seq=15 ttl=243 time=101.559 ms
64 bytes from 199.91.189.38: icmp_seq=16 ttl=243 time=100.622 ms
64 bytes from 199.91.189.38: icmp_seq=17 ttl=243 time=451.749 ms
64 bytes from 199.91.189.38: icmp_seq=18 ttl=243 time=104.527 ms
64 bytes from 199.91.189.38: icmp_seq=19 ttl=243 time=101.387 ms

64 bytes from 199.91.189.38: icmp_seq=25 ttl=243 time=101.613 ms
64 bytes from 199.91.189.38: icmp_seq=26 ttl=243 time=102.453 ms
64 bytes from 199.91.189.38: icmp_seq=27 ttl=243 time=402.926 ms
64 bytes from 199.91.189.38: icmp_seq=28 ttl=243 time=102.158 ms
64 bytes from 199.91.189.38: icmp_seq=29 ttl=243 time=101.519 ms

64 bytes from 199.91.189.38: icmp_seq=60 ttl=243 time=103.801 ms
64 bytes from 199.91.189.38: icmp_seq=61 ttl=243 time=100.424 ms
64 bytes from 199.91.189.38: icmp_seq=62 ttl=243 time=547.119 ms
64 bytes from 199.91.189.38: icmp_seq=63 ttl=243 time=467.761 ms
64 bytes from 199.91.189.38: icmp_seq=64 ttl=243 time=388.406 ms
64 bytes from 199.91.189.38: icmp_seq=65 ttl=243 time=557.122 ms
64 bytes from 199.91.189.38: icmp_seq=66 ttl=243 time=537.825 ms
64 bytes from 199.91.189.38: icmp_seq=67 ttl=243 time=102.962 ms
64 bytes from 199.91.189.38: icmp_seq=68 ttl=243 time=103.227 ms

http://www.as6453.net/

http://www.tatacommunications.com/

http://www.tatacommunications.com/ab...ontact_offices

http://en.wikipedia.org/wiki/Tata_Communications

http://www.ormuco.com/telecom-solutions/mpls/

Credit to Marishi-Ten




Now that you have a place to start investigating SE

After a week of lag and 90k, yesterday was the first day I could play.
There is hope guys, hang in there.

Slingshot
New Zealand
Error 90000 disconnect after 2-3 minutes in an instance, either group or solo

Error 2002 when trying to get back into the character selection screen

Tethered with a mobile phone works no problem.

Quote:

---

Originally Posted by gigi_frana

After a week of lag and 90k, yesterday was the first day I could play.
There is hope guys, hang in there.

---

same Gigi, maybe they fixed videotron, all day yesterday no problem

- Tiscali/Talk Talk
- England,UK
- During peak times it seems. The connection cuts out once every 20-30mins.

UK - Sky broadband

4pm till around 11pm my icon flicks offline/online

GJ with the trace route ^^

Charter Communications
Alabama, US
Always
----NPC appearance lag, major lag in cities with a lot of congestion. Even during off periods like 6a-10a still have 3-5 sec combat lag and quest NPC appearance. It will clear up for maybe 10 mins or so then back to the norm.

Time Warner Cable

New York City, NY

Always - I have 5,000+ Ping and rubber banding 100% of the time I've played. It translates into around 1.5 - 2 second skill lag, and massive rubber banding.

Side note - I pinged the IP address of the server where the game is run and it came back with 23ms.

ISP: True Internet

City/Country: Bangkok, Thailand

I get significantly more latency than I should get. This problem doesn't occur with any other online games, just FF14. It occurs during all hours.

Optimum wireless.
New Jersey, US of A
always
makes me so mad I cant enjoy the damn game properly.

I can't believe this is still an issue.

You run server mait and it destroys any credibility of me participating in groups, because I rubberband and throttle lag during everything. It's hard not to be frustrated because what does it limit me to? I chop wood as a botanist because me throttle lagging won't get anyone killed or delay a boss fight. You have banished me to chopping wood for the rest of whenever. I suppose I will be the #1 Botanist since I can't DPS with all the delay lag I receive.

It's hard not to rage about this, so fix your god damned servers because I ping 20ms.

Hate to say it but the problem isn't primarily with their Servers. The problem relates to how data is transferred from Client - Server, and Client - Client. Due to this method of communications, several ISPs Quality of Service filtering thinks its "Peer to Peer" (P2P) traffic and reduces it to the lowest priority. IF you are having this issue, I HIGHLY RECOMMEND you contact your ISP and make them aware of the situation, additionally post it here so Square-Enix can contact them as well and give them additional details to try to remedy it completely.

Myself I can play fine until I get into an instance, sometimes I'm stable, sometimes I DC. Contacted my ISP and SE now its in their hands.

I'm also getting lag that's making the game unplayable. Quest NPC's can take a minute plus to load on screen. There's a delay of several seconds between pressing a button and the action occurring on screen.
ISP: BrightHouse
Location: St. Petersburg, FL

- Verizon Fios
- USA, Florida
- Everyday all day

Didn't have any problem playing during phase 4 or early access. Haven't been able to play once since release day. I'm playing (or trying to play) on PC.

Note: My fiance plays on PS3 on this same connection (FIOS in Tampa), and he has absolutely no issues with connection. I really don't understand why HE can play and I can't if the issue is supposedly the ISPs. Get it together, SQEX.

name of ISP: Cox at home
residence: Arizona ,usa
Occurance: all day long until jp players go to bed. I play on Masamune sevier . where the guild im in is at.

- Telia - http://www.oktv.se
- Sweden
- Pretty much on and off every day.

Mediacom
Iowa, USA
I have random occurrences of complete 0 FR lag that lasts for 30seconds up to a complete lock of my comp, forcing a ctrl-alt-del force quit from Task Manager. It seems to happen more during instances/FATES, but has happened when soloing in low congestion areas multiple times.

For Verizon FiOS users the issue seems to be worst in Northern Virginia.
http://www.reddit.com/r/ffxiv/commen...e_you_lagging/

I posted this in another thread, but it was requested that I post here as well:

It's hard to say where their instance servers are actually located. I've done some snooping around and I have found some information. Looking over the data I was able to acquire, it looks like Square rents its server space. There seems to be massive latency originating on the Seattle, Chicago, and Montreal (end point) hops owned by as6453.net, which are owned by Tata Communications. Their switches are showing quite of bit of slow down, (220ms+ latency) which in turn is causing more slow down and bottlenecking at the Montreal hops.

Tata Communications are a T1 telecomm in India, but they are at best a T3 in the US. I can't seem to find what T1 is hosting them in the US. If we can find who the backbone they are running through (AT&T, Century Link, Cogent, Level3, NTT, Savvis, SBC, Sprint, Verizon, XO) we can either field our own trouble tickets with them or we can contact our ISP's and request they avoid routing through their hubs.

If servers are being rented though Tata, then we can't reroute around them. We essentially have to deal with the latency until they redistribute their I/O paths or upgrade their switches.

Alternately, it could also be a problem with their MPLS circuits (hosted through Ormuco) reaching maximum bandwidth and causing latency.

The root issue more than likely lies between the two making it difficult to field any fix in a timely manner.

In short, it looks like Square doesn’t own the servers that are housing the North American and European worlds. This combined with the amount of traffic that their host is seeing is causing the latency issues.

3 184.99.64.201 (184.99.64.201) 18.925 ms 17.211 ms 17.251 ms
4 boid-agw1.inet.qwest.net (184.99.65.65) 23.503 ms 17.396 ms 36.997 ms
5 sea-brdr-02.inet.qwest.net (67.14.41.18) 44.756 ms 31.634 ms 37.997 ms
6 ix-1-0-0-0.tcore1.00s-seattle.as6453.net (64.86.123.77) 52.807 ms 304.980 ms 293.516 ms
7 if-0-0-0-2.core1.00s-seattle.as6453.net (64.86.123.2) 463.000 ms 294.448 ms 256.501 ms
8 if-9-3-3-0.tcore2.ct8-chicago.as6453.net (64.86.124.34) 323.445 ms 142.922 ms 96.168 ms
9 if-3-2.tcore1.w6c-montreal.as6453.net (66.198.96.45) 95.991 ms 96.259 ms 95.309 ms
10 66.198.96.50 (66.198.96.50) 99.636 ms 99.195 ms 99.700 ms
11 192.34.76.2 (192.34.76.2) 99.474 ms 98.574 ms 99.333 ms

whois 199.91.189.38
Ormuco ORMUCO-FIBER-NETWORK (NET-199-91-184-0-1) 199.91.184.0 - 199.91.191.255
Eidos ORMUC-SE (NET-199-91-189-0-1) 199.91.189.0 - 199.91.189.255

64 bytes from 199.91.189.38: icmp_seq=290 ttl=243 time=101.808 ms
64 bytes from 199.91.189.38: icmp_seq=291 ttl=243 time=101.363 ms
64 bytes from 199.91.189.38: icmp_seq=292 ttl=243 time=320.852 ms
64 bytes from 199.91.189.38: icmp_seq=293 ttl=243 time=422.690 ms
64 bytes from 199.91.189.38: icmp_seq=294 ttl=243 time=422.983 ms
64 bytes from 199.91.189.38: icmp_seq=295 ttl=243 time=484.630 ms
64 bytes from 199.91.189.38: icmp_seq=296 ttl=243 time=424.351 ms
64 bytes from 199.91.189.38: icmp_seq=297 ttl=243 time=445.440 ms
64 bytes from 199.91.189.38: icmp_seq=298 ttl=243 time=101.748 ms
64 bytes from 199.91.189.38: icmp_seq=299 ttl=243 time=101.246 ms

64 bytes from 199.91.189.38: icmp_seq=15 ttl=243 time=101.559 ms
64 bytes from 199.91.189.38: icmp_seq=16 ttl=243 time=100.622 ms
64 bytes from 199.91.189.38: icmp_seq=17 ttl=243 time=451.749 ms
64 bytes from 199.91.189.38: icmp_seq=18 ttl=243 time=104.527 ms
64 bytes from 199.91.189.38: icmp_seq=19 ttl=243 time=101.387 ms

64 bytes from 199.91.189.38: icmp_seq=25 ttl=243 time=101.613 ms
64 bytes from 199.91.189.38: icmp_seq=26 ttl=243 time=102.453 ms
64 bytes from 199.91.189.38: icmp_seq=27 ttl=243 time=402.926 ms
64 bytes from 199.91.189.38: icmp_seq=28 ttl=243 time=102.158 ms
64 bytes from 199.91.189.38: icmp_seq=29 ttl=243 time=101.519 ms

64 bytes from 199.91.189.38: icmp_seq=60 ttl=243 time=103.801 ms
64 bytes from 199.91.189.38: icmp_seq=61 ttl=243 time=100.424 ms
64 bytes from 199.91.189.38: icmp_seq=62 ttl=243 time=547.119 ms
64 bytes from 199.91.189.38: icmp_seq=63 ttl=243 time=467.761 ms
64 bytes from 199.91.189.38: icmp_seq=64 ttl=243 time=388.406 ms
64 bytes from 199.91.189.38: icmp_seq=65 ttl=243 time=557.122 ms
64 bytes from 199.91.189.38: icmp_seq=66 ttl=243 time=537.825 ms
64 bytes from 199.91.189.38: icmp_seq=67 ttl=243 time=102.962 ms
64 bytes from 199.91.189.38: icmp_seq=68 ttl=243 time=103.227 ms

http://www.as6453.net/

http://www.tatacommunications.com/

http://www.tatacommunications.com/ab...ontact_offices

http://en.wikipedia.org/wiki/Tata_Communications

http://www.ormuco.com/telecom-solutions/mpls/

Virgin Media are currently investigating the issue on their end and have asked that people here who are experiencing problems go to their forum and respond to help them understand the problem:
http://community.virginmedia.com/t5/...1981482#M14867

Virgin Media - UK
GMT Evenings only, for the last few days

- Name of ISP : Cox Communications

- Country of Residence : Nevada, USA

- Occurance : Problems with high latency all of the time (400-1200ms+) and spikes of 2500ms or more when in instances and during peak NA times (5PM to 1AM).

- Reference : Of course my ISP makes no claim to throttle or de-prioritize connections to the game and have not heard of anyone else having this issue.

- Name of ISP : Cable TV of East Alabama
- Country : United States
- Occurance : Everyday, Starts around 8 PM and last up until around 3-5 am constant disconnects
- Reference: Contacted ISP they seem to be clueless as to what is going on. They say the connection isn't dropping.

- Name of ISP : AT&T U-verse
- Country : United States
- Occurance : After 5pm

- Name of ISP : Verizon FIOs

- Location: Northern Virginia

- Occurance : Problems with high latency all of the time (400-1200ms+) and spikes of 2500ms or more when in instances and during peak NA times (5PM to 1AM). Nearly unplayable lag.

- Name of ISP: Cablevision
- Country of Residence: México
- When does the problem occur (always, only during specific times?): Between 7 and 12 pm

ISP: BrightHouse
Where: St. Petersburg, FL
When: Always

Game is unplayable. Lag of several seconds after pressing a hotkey and NPCs take over a minute to appear on screen.

- Comcast Xfinity
- USA
- I noticed it yesterday. Had massive lag spikes and was kicked off the internet several times.
- I didn't think it was an ISP issue so I did not contact anyone. I will now if it happens again.

Can we get a Support rep response to this... and an update to see that something is being done... its starting to get ridiculous.