Error code 2002 and 90000

[TendoFg]

Having similar issues. I've been playing since 1.0 and have had absolutely no connectivity problems from then, right up until a month or so ago. The problem intensified when they disabled the auto d/c function.

My 90002 errors started off as an infrequent annoyance but have recently increased in frequency to a point where i can't play for more than an hour or two without disconnecting.

I've gone into my router settings and forwarded the ports outlined in various guides and they have had little to no effect.

People seem nearly 50 % divided on whether it's an ISP issue or a server side issue with the game but I'm pretty sure(although can't be 100 % certain) that it's not ISP related because surely these problems would have occurred a lot sooner than they have and I play a lot of other games online without problem. The fact I've never had these issues before a month ago with FF XIV leads me to believe it's something that's been implemented server side recently.

Regardless, many many people are having these problems now and the number of people complaining over the past couple of weeks has risen substantially. I really don't want to stop playing FF XIV as i play it nearly daily but with these connection issues, i just can't get myself motivated to do anything worthwhile in game for fear of 90k.

[Wyvrex]

I've seen this issue everywhere online, from people on PC and consoles, all over the world - this is definitely not the problem of individual people's internet, not when the issue is so widespread (one or two maybe, but not thousands, just check out how many threads there are on this one topic just on this forum's support pages, there is one on the 'looking into' section of over 200 pages!). If it were an ISP thing, there would be loads of people offering a working solution, but nothing people have tried has seemed to make it stop. Basically, there are hundreds of threads about this one issue with no answers in sight

I thought yesterday's maintenance would fix it, but it seems to have made it worse as now I'm getting thrown out every few minutes instead of every 30 mins or longer. Just now was the last straw - got thrown out at the end of a long single player duty for my level 60 class quest and there is no way I'm going back in for fear of 90002 error - also means I can't do the dungeons .

It's looking like I'm gonna have to give up on doing anything significant on this game until it's fixed which sucks coz I was planning on doing an eternal bond in the next few weeks - no way the server is gonna hold for that length of time!

I've been playing the game for over 6 months with no previous error - seems to have been since 3.05 was installed :S my husband is also playing on PS4 and gets d/c'd.

Please fix this squeenix, I love playing this game too much to give it up now!

[Lisburn]

I am also having 90002 errors constantly which is annoying as I have pretty limited time to play due to long work hours. These started roughly the 23rd July and have started to be more frequent each day since. I love this game so some guidance or fixes would be awesome.

It is most definitely not my ISP as that has been checked thoroughly.

[Raist]

I've seen this issue everywhere online, from people on PC and consoles, all over the world - this is definitely not the problem of individual people's internet, not when the issue is so widespread (one or two maybe, but not thousands, just check out how many threads there are on this one topic just on this forum's support pages, there is one on the 'looking into' section of over 200 pages!). If it were an ISP thing, there would be loads of people offering a working solution, but nothing people have tried has seemed to make it stop. Basically, there are hundreds of threads about this one issue with no answers in sight

I thought yesterday's maintenance would fix it, but it seems to have made it worse as now I'm getting thrown out every few minutes instead of every 30 mins or longer. Just now was the last straw - got thrown out at the end of a long single player duty for my level 60 class quest and there is no way I'm going back in for fear of 90002 error - also means I can't do the dungeons .

It's looking like I'm gonna have to give up on doing anything significant on this game until it's fixed which sucks coz I was planning on doing an eternal bond in the next few weeks - no way the server is gonna hold for that length of time!

I've been playing the game for over 6 months with no previous error - seems to have been since 3.05 was installed :S my husband is also playing on PS4 and gets d/c'd.

Please fix this squeenix, I love playing this game too much to give it up now!

Must be new here... or at least new to this issue on these forums.

It has been repeatedly demonstrated how people have resolved the issues by getting a more stable route established--be that via VPN, working with their ISP, or from the congestion subsiding over time. There was even a thread here in recent weeks where it was disclosed there were downed nodes in the south east affecting scores of players--it was the exact same symptoms. People reported resolving the matter in the short-term by using a VPN service to route away from the failing hops until services were restored.

The issues frequently show up in multiple forums for games and other services. The last mile ISP's routinely get taken to task over it on their own forums. It shows up regularly at composite sites like the dslreports forums and tracking sites like downdetector.com and such. There have been filings with the FCC over the issues. It was a major point brought up in the net neutrality debates. It was also brought up frequently in the TWC/Comcast merger discussions as well. There have been studies and blog posts done on the matter for years. The threat of the congestive failures have been there for decades--there were even checks and balances built into the TCP/IP protocol to fight the issue.

It is nothing new. Perhaps new to you, but not to the community and certainly not to the industry. The problem is that the public has not been properly informed on the matter...and the ISP's get away with overselling bandwidth (not to mention overpricing it in many cases). Most people don't even understand that they mistakenly are calling their bandwidth plan their speed...they've all been duped by their ISP's for far too long.

I and others have posted scores of information on the matter from various sources. Gonna copy/paste a previous post from another thread in hopes it might lead to a better understanding of what may actually be causing these connectivity/stability problems for many of you guys:

http://forum.square-enix.com/ffxiv/t...=1#post3149203

Knowledge is empowering....


“Chicken” | A Game Played as a Child and by some ISPs with the Internet
Observations of an Internet Middleman
When the Middleman and ISP are Aligned
Heads ISPs Win, Tails You Lose (And a way to fix it)
Verizon’s Accidental Mea Culpa
“Not” Neutrality?

Running a Trace Route (a how-to from Blizzard for investigating problems)

Lobby server addresses in Canada that can be used for testing in case you don't have the actual IP address you use when playing the game:

neolobby02.ffxiv.com (this is Aether, unsure which of the other two is on what address)
neolobby04.ffxiv.com
neolobby06.ffxiv.com

A site that tracks the status of lots of services---major ISP's and services like Hulu, PSN, XBL, etc., along with links to a couple ISP's pages for convenience

https://downdetector.com/companies
https://downdetector.com/status/comcast-xfinity
https://downdetector.com/status/att
https://downdetector.com/status/time-warner-cable



Site with internet usage statistics. Note, this is the company that mirrors our patches for SE. They are really big on network optimization, and track all kinds of stats on the web.

http://www.akamai.com/html/technolog...try/index.html
http://www.akamai.com/html/technolog...b-monitor.html
http://www.akamai.com/html/technolog...b-metrics.html


Now go forth minions... take your ISP's to task and demand they fix your broken internet!


All kidding aside. There are known issues with North America's infrastructure that lead to the very issues you guys are constantly complaining about. Those who are in the know understand the pitfalls, and have been able to go after their ISP's and get things cleaned up. The only thing separating them from you is a little better understanding of how things work, how to spot the signs of the known problems, and how to best go about seeking help. Hopefully the links up near the top will serve as a means to that end in providing you a basic understanding of the problem, and how you can track/document the signs so you can forward good information to the proper people at your ISP to get a proper assessment that <hopefully> will result in them getting the problems addressed.


Alternatively... you could just try some VPN services (most have some manner of free trial or free use policy you can use for testing---is a good way to demonstrate the issue to your ISP as well). Most will allow you to tunnel to different locations, allowing you to select alternate routes on demand to find a more stable path.

[Alexika]

Raist, at first I was really thinking you may be right, but I don't think our ISP is to blame at all. I have done numerous long term pings now to my server and the problem does not arise until it leaves my ISPs network. In fact, the majority of my packet loss is actually once it hits SEs network. I am starting to believe that SE is not paying for enough bandwidth.

[Raist]

Raist, at first I was really thinking you may be right, but I don't think our ISP is to blame at all. I have done numerous long term pings now to my server and the problem does not arise until it leaves my ISPs network. In fact, the majority of my packet loss is actually once it hits SEs network. I am starting to believe that SE is not paying for enough bandwidth.

Didn't you previously state you were seeing issues at an alter.net hop? More specifically, I think it was alter.net and LEvel3 if I remember correctly. Alter.net is Verizon. More specifically, Verizon Business. They are the ones opting to put you on Level3 and not someone else. It is all on your ISP's routing policies making that happen...and they have the power to change it if they aren't going to work with Level3 to track down/address the issues with that peering partner.

It is well within your ISP's power to find you a better route.

Edit: let's see if I can find some examples of what I'm talking about...going back a over a year (03/2014), we have this, where I was wrangling with a localized issue with a TWC gateway (problem was an outdated CMTS):

http://forum.square-enix.com/ffxiv/t...=1#post1918510

Tracing route to 199.91.189.25 over a maximum of 30 hops

1 2 ms <1 ms 1 ms LPTSRV [10.10.100.1]
2 296 ms 65 ms 25 ms cpe-098-025-064-001.sc.res.rr.com [98.25.64.1]
3 11 ms 11 ms 17 ms cpe-024-031-198-005.sc.res.rr.com [24.31.198.5]
4 33 ms 30 ms 24 ms xe-7-0-0.rlghncpop-rtr1.southeast.rr.com [24.93.64.40]
5 33 ms 34 ms 32 ms 107.14.19.44
6 28 ms 40 ms 30 ms ae-2-0.pr0.dca10.tbone.rr.com [66.109.6.169]
7 33 ms 43 ms 35 ms te0-16-0-23.ccr41.iad02.atlas.cogentco.com [154.54.10.209]
8 36 ms 32 ms 34 ms be2177.ccr22.dca01.atlas.cogentco.com [154.54.41.206]
9 45 ms 42 ms 44 ms be2148.ccr21.jfk02.atlas.cogentco.com [154.54.31.118]
10 42 ms 43 ms 61 ms be2106.ccr21.alb02.atlas.cogentco.com [154.54.3.50]
11 66 ms 67 ms 71 ms be2088.ccr21.ymq02.atlas.cogentco.com [154.54.43.17]
12 62 ms 61 ms 60 ms 38.122.42.34
13 46 ms 45 ms 46 ms 192.34.76.10
14 42 ms 43 ms 43 ms 199.91.189.242
15 43 ms 44 ms 46 ms 199.91.189.25

Trace complete.

I continued to work with them for quite a while...eventually started working more directly with engineering on it (Tier3), as noted in this post:
http://forum.square-enix.com/ffxiv/t...RV#post2044489

Tracing route to 199.91.189.31 over a maximum of 30 hops

1 2 ms <1 ms 1 ms LPTSRV [10.10.100.1]
2 * * * Request timed out. (98.25.64.1, engineering investigating for residential in Florence, SC--seen 1000ms+ lag spikes at times)
3 12 ms 14 ms 12 ms cpe-024-031-198-005.sc.res.rr.com [24.31.198.5] (Summerville, SC... was previously Raleigh)
4 25 ms 22 ms 32 ms 24.93.64.128 (Charlotte, NC--new Gbit fiber rolled out for Central Charlotte in the last year)
5 31 ms 31 ms 29 ms 107.14.19.42 (Cary, NC-- new Gbit market opening up, AT&T awaiting local boards to approve Residential services)
6 28 ms 32 ms 30 ms ae-2-0.pr0.dca10.tbone.rr.com [66.109.6.169]
7 37 ms 33 ms 35 ms te0-16-0-23.ccr41.iad02.atlas.cogentco.com [154.54.10.209]
8 34 ms 34 ms 36 ms be2112.mpd22.dca01.atlas.cogentco.com [154.54.5.234]
9 39 ms 40 ms 42 ms be2149.ccr22.jfk02.atlas.cogentco.com [154.54.31.126]
10 44 ms 44 ms 42 ms be2106.ccr21.alb02.atlas.cogentco.com [154.54.3.50]
11 65 ms 66 ms 65 ms be2088.ccr21.ymq02.atlas.cogentco.com [154.54.43.17]
12 59 ms 57 ms 62 ms 38.122.42.34
13 50 ms 44 ms 47 ms 192.34.76.10
14 47 ms 48 ms 46 ms 199.91.189.242
15 44 ms 44 ms 47 ms 199.91.189.31

Trace complete.

Eventually, they managed to reign things in a bit at that gateway as shown in the trace in this post:
http://forum.square-enix.com/ffxiv/t...=1#post2066209

Tracing route to www.google.com [74.125.131.105]
over a maximum of 30 hops:

1 1 ms <1 ms <1 ms LPTSRV [10.10.100.1]
2 34 ms 20 ms 26 ms cpe-098-025-064-001.sc.res.rr.com [98.25.64.1]
3 13 ms 12 ms 10 ms cpe-024-031-198-005.sc.res.rr.com [24.31.198.5]
4 27 ms 28 ms 26 ms 24.93.64.124
5 33 ms 35 ms 30 ms 107.14.19.20
6 31 ms 31 ms 30 ms ae-0-0.pr0.dca20.tbone.rr.com [66.109.6.183]
7 29 ms 30 ms 61 ms 74.125.49.181
8 30 ms 46 ms 32 ms 209.85.252.46
9 32 ms 30 ms 30 ms 72.14.236.148
10 41 ms 44 ms 49 ms 72.14.234.168
11 43 ms 45 ms 43 ms 209.85.251.228
12 * * * Request timed out.
13 44 ms 43 ms 43 ms vc-in-f105.1e100.net [74.125.131.105]

Trace complete.

but... it eventually came back a couple months later, as shown in this trace here:
http://forum.square-enix.com/ffxiv/t...=1#post2194801

Tracing route to 199.91.189.25 over a maximum of 30 hops

1 1 ms <1 ms <1 ms LPTSRV [10.10.100.1]
2 49 ms 23 ms 253 ms cpe-098-025-064-001.sc.res.rr.com [98.25.64.1]
3 28 ms 11 ms 15 ms cpe-024-031-198-005.sc.res.rr.com [24.31.198.5]
4 25 ms 26 ms 28 ms xe-7-0-0.rlghncpop-rtr1.southeast.rr.com [24.93.64.40]
5 43 ms 30 ms 32 ms 107.14.19.44
6 31 ms 32 ms 34 ms ae1.pr1.dca10.tbone.rr.com [107.14.17.202]
7 31 ms 31 ms 32 ms ix-17-0.tcore2.AEQ-Ashburn.as6453.net [216.6.87.149]
8 71 ms 54 ms 65 ms if-2-2.tcore1.AEQ-Ashburn.as6453.net [216.6.87.2]
9 60 ms 55 ms 57 ms 64.86.85.1
10 54 ms 54 ms 57 ms if-10-2.tcore1.TTT-Toronto.as6453.net [64.86.32.33]
11 53 ms 53 ms 54 ms if-9-9.tcore1.TNK-Toronto.as6453.net [64.86.33.25]
12 55 ms 64 ms 55 ms if-7-2.tcore1.W6C-Montreal.as6453.net [66.198.96.61]
13 60 ms 52 ms 54 ms 66.198.96.50
14 55 ms 52 ms 57 ms 192.34.76.2
15 54 ms 57 ms 56 ms 199.91.189.234
16 51 ms 54 ms 56 ms 199.91.189.25

Trace complete.

***note something that changed here---my peering was switched from Cogentco to TATA (as6453). that was done by TWC, because the Cogentco lines had gone to pot on us. SE didn't do that--Time Warner did.

And then , just a short while later.. it changed again. But this time there were significant changes:
http://forum.square-enix.com/ffxiv/t...=1#post2224866

0 G75VXLAP [10.10.100.10]
1 LPTSRV [10.10.100.1]
2 cpe-066-026-112-001.sc.res.rr.com [66.26.112.1]
3 cpe-024-031-198-009.sc.res.rr.com [24.31.198.9]
4 24.93.64.134
5 bu-ether34.atlngamq46w-bcr00.tbone.rr.com [107.14.19.48]
6 107.14.19.99
7 te0-0-0-10.ccr21.atl02.atlas.cogentco.com [154.54.12.109]
8 be2050.ccr41.atl01.atlas.cogentco.com [154.54.0.165]
9 be2170.mpd21.dca01.atlas.cogentco.com [154.54.31.106]
10 be2150.mpd21.jfk02.atlas.cogentco.com [154.54.31.130]
11 be2108.ccr21.alb02.atlas.cogentco.com [154.54.3.134]
12 be2088.ccr21.ymq02.atlas.cogentco.com [154.54.43.17]
13 38.122.42.34
14 10.2.2.1
15 192.34.76.2
16 199.91.189.234
17 199.91.189.25

In case you missed it...aside from the switch back to Cogentco for peering, I also had a new gateway. TWC-SC finally gave up on the failing CMTS. I forget exactly...but I think they had moved me to Hilton Head's gateway at that time (I live in Florence).

But... we were far from being out of the woods. While things were generally good, it still had it's WTF moments, like this one here in August:
http://forum.square-enix.com/ffxiv/t...=1#post2359091

Tracing route to 199.91.189.30 over a maximum of 30 hops

0 MJ14336 [10.10.100.2]
1 LPTSRV [10.10.100.1]
2 cpe-066-026-112-001.sc.res.rr.com [66.26.112.1]
3 cpe-024-031-198-005.sc.res.rr.com [24.31.198.5]
4 clmasoutheastmyr-rtr2.sc.rr.com [24.31.196.210]
5 be33.drhmncev01r.southeast.rr.com [24.93.64.180]
6 107.14.19.20
7 * ae-4-0.a0.lax91.tbone.rr.com [66.109.1.113]
8 ix-17-0.tcore2.AEQ-Ashburn.as6453.net [216.6.87.149]
9 if-2-2.tcore1.AEQ-Ashburn.as6453.net [216.6.87.2]
10 64.86.85.1
11 if-10-2.tcore1.TTT-Toronto.as6453.net [64.86.32.33]
12 if-9-9.tcore1.TNK-Toronto.as6453.net [64.86.33.25]
13 if-7-2.tcore1.W6C-Montreal.as6453.net [66.198.96.61]
14 66.198.96.50
15 192.34.76.2
16 199.91.189.234
17 199.91.189.30

Yes... that is right... I was getting shot over to Southern California from South Carolina trying to get to Montreal. It wasn't perfect... but was better than dealing with some downed nodes here on the Eastern Seaboard at the time. Again, Time Warner was making this decision...in an effort to stay ahead of the congested corridors they were finding.

Yes... it's been a long road, and we still weren't there yet---but it was getting progressively better. Eventually, we hit pay-dirt, as demonstrated with the trace in this post in October:
http://forum.square-enix.com/ffxiv/t...=1#post2499951

Tracing route to 199.91.189.30 over a maximum of 30 hops

1 2 ms 1 ms <1 ms LPTSRV [10.10.100.1]
2 37 ms 26 ms 28 ms cpe-066-026-112-001.sc.res.rr.com [66.26.112.1]
3 17 ms 24 ms 29 ms cpe-024-031-198-005.sc.res.rr.com [24.31.198.5]
4 13 ms 16 ms 14 ms clmasoutheastmyr-rtr2.sc.rr.com [24.31.196.210]
5 28 ms 25 ms 27 ms be33.drhmncev01r.southeast.rr.com [24.93.64.180]
6 32 ms 34 ms 35 ms 107.14.19.20
7 33 ms 43 ms 33 ms so-1-1-1.c1.buf00.tbone.rr.com [66.109.1.113]
8 32 ms 31 ms 32 ms ix-17-0.tcore2.AEQ-Ashburn.as6453.net [216.6.87.149]
9 62 ms 64 ms 61 ms if-11-2.tcore2.NJY-Newark.as6453.net [216.6.87.138]
10 62 ms 76 ms 62 ms if-4-4.tcore2.NYY-New-York.as6453.net [66.198.111.18]
11 59 ms 60 ms 62 ms if-12-6.tcore1.CT8-Chicago.as6453.net [216.6.99.46]
12 58 ms 61 ms 60 ms if-22-2.tcore2.CT8-Chicago.as6453.net [64.86.79.1]
13 60 ms 69 ms 61 ms if-3-2.tcore1.W6C-Montreal.as6453.net [66.198.96.45]
14 59 ms 73 ms 61 ms 66.198.96.50
15 62 ms 62 ms 64 ms 192.34.76.2
16 58 ms 59 ms 60 ms 199.91.189.234
17 62 ms 62 ms 59 ms 199.91.189.30

Trace complete.

It still has it's questionable responses...and eventually some of them evened out. They continued to actively monitor the routes for a while. Periodically my modem would reboot and the route would change between Level3, Cogent, and TATA. Sometimes it would change up 2 or 3 times in the same week, sometimes it would be 3 weeks before a change. But it was ALWAYS Time Warner working on my behalf...and always them resolving my problems with the game. The ONLY time we involved SE with the process is when we captured a problem at one of Ormuco's VLAN's, and that was just to include them with the communications to Ormuco about the problem just in case we needed the extra push to get Ormuco to take action in resolving the 250ms+ spikes we had detected at that point in the route after we had cleaned up everything else in between. That issue was handled within a few days and never reared it's head again. Since then, it has ben 100% on Time Warner fixing any issues I have. Most times automatically, but once in a while I would catch the signs first and forward them a snapshot--sometimes it was handled the same night, or if it was the weekend it might take until Monday night when I came home from work before I saw improvement.

Barring the few times it was in fact announced to be server side issues by SE, it has ALWAYS been a change in how I was routed that resolved my connectivity/stability issues with the game. And that was ALWAYS handled by going through my ISP's Tier3 support team first--and NOT SE.

[Alexika]

Raist, at first I was really thinking you may be right, but I don't think our ISP is to blame at all. I have done numerous long term pings now to my server and the problem does not arise until it leaves my ISPs network. In fact, the majority of my packet loss is actually once it hits SEs network. I am starting to believe that SE is not paying for enough bandwidth.

I thought I was seeing issues there, but it turns out it is just an anti-DDoS feature. Want the MTR I am running right now?

|------------------------------------------------------------------------------------------|

|                                      WinMTR statistics                                   |

|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |

|------------------------------------------------|------|------|------|------|------|------|

|          Wireless_Broadband_Router.home -    1 | 1060 | 1058 |    0 |    4 |  473 |    2 |

|lo0-100.PRVDRI-VFTTP-306.verizon-gni.net -    0 | 1068 | 1068 |    4 |   10 |  428 |    6 |

|  T0-2-0-9.PRVDRI-LCR-22.verizon-gni.net -    0 | 1068 | 1068 |    4 |   10 |  422 |    8 |

|  xe-1-0-8-0.BOS-BB-RTR2.verizon-gni.net -    0 | 1068 | 1068 |    6 |   24 |  428 |    7 |

|xe-4-1-0-0.NY325-BB-RTR2.verizon-gni.net -    0 | 1068 | 1068 |   17 |   27 |  461 |   21 |

|                0.ae7.BR1.NYC1.ALTER.NET -    0 | 1068 | 1068 |   15 |   21 |  410 |   17 |

|                   No response from host -  100 |  213 |    0 |    0 |    0 |    0 |    0 |

|      ae-11-11.car2.Montreal2.Level3.net -    1 | 1053 | 1049 |   56 |   89 |  652 |  108 |

|      ae-11-11.car2.Montreal2.Level3.net -    1 | 1052 | 1048 |   56 |   89 |  620 |  270 |

|   ORMUCO-COMM.car2.Montreal2.Level3.net -    1 | 1041 | 1034 |   56 |   63 |  534 |   60 |

|                            192.34.76.10 -   13 |  719 |  632 |   68 |   78 |  534 |   72 |

|                          199.91.189.242 -   15 |  682 |  585 |    0 |   78 |  492 |   74 |

|                           199.91.189.33 -   17 |  645 |  539 |    0 |   81 |  503 |   75 |

|________________________________________________|______|______|______|______|______|______|

   WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

[Raist]

I thought I was seeing issues there, but it turns out it is just an anti-DDoS feature. Want the MTR I am running right now?

|------------------------------------------------------------------------------------------|

|                                      WinMTR statistics                                   |

|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |

|------------------------------------------------|------|------|------|------|------|------|

|          Wireless_Broadband_Router.home -    1 | 1060 | 1058 |    0 |    4 |  473 |    2 |

|lo0-100.PRVDRI-VFTTP-306.verizon-gni.net -    0 | 1068 | 1068 |    4 |   10 |  428 |    6 |

|  T0-2-0-9.PRVDRI-LCR-22.verizon-gni.net -    0 | 1068 | 1068 |    4 |   10 |  422 |    8 |

|  xe-1-0-8-0.BOS-BB-RTR2.verizon-gni.net -    0 | 1068 | 1068 |    6 |   24 |  428 |    7 |

|xe-4-1-0-0.NY325-BB-RTR2.verizon-gni.net -    0 | 1068 | 1068 |   17 |   27 |  461 |   21 |

|                0.ae7.BR1.NYC1.ALTER.NET -    0 | 1068 | 1068 |   15 |   21 |  410 |   17 |

|                   No response from host -  100 |  213 |    0 |    0 |    0 |    0 |    0 |

|      ae-11-11.car2.Montreal2.Level3.net -    1 | 1053 | 1049 |   56 |   89 |  652 |  108 |

|      ae-11-11.car2.Montreal2.Level3.net -    1 | 1052 | 1048 |   56 |   89 |  620 |  270 |

|   ORMUCO-COMM.car2.Montreal2.Level3.net -    1 | 1041 | 1034 |   56 |   63 |  534 |   60 |

|                            192.34.76.10 -   13 |  719 |  632 |   68 |   78 |  534 |   72 |

|                          199.91.189.242 -   15 |  682 |  585 |    0 |   78 |  492 |   74 |

|                           199.91.189.33 -   17 |  645 |  539 |    0 |   81 |  503 |   75 |

|________________________________________________|______|______|______|______|______|______|

   WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

O M G.

It is staring us right in the face. Practically screaming at you.

Even if you want to write off the massive lag spike and lost packets on your local network (which you shouldn't--it is after all the first link in the chain and can affect everything after)...it looks like jitter may be on the high side with Verizon. Then it goes bonkers at Level3.

Based on the data you have presented, you appear to have networking issues that would have an impact on the most perfectly tuned server.

Even if the 600+ spikes were a once-only fluke spike at each of those hops, Level3 is running 56 to 108 with an average of 89 on one hop, and then 56 to 27-0 with an average of 89 at another. That is NOT acceptable. And imagine that... it is LEvel3's car2 hops in Montreal---notorious for being flakey as all get out. They get reported continuously all over the place for a variety of service issues.

Verizon is keeping you on that troubled route. They can take you off of it, just like Time Warner does for me on a regular basis... as demonstrated in the edit I made in my previous post.

[Alexika]

O M G.

It is staring us right in the face. Practically screaming at you.

Even if you want to write off the massive lag spike and lost packets on your local network (which you shouldn't--it is after all the first link in the chain and can affect everything after)...it looks like jitter may be on the high side with Verizon. Then it goes bonkers at Level3.

Based on the data you have presented, you appear to have networking issues that would have an impact on the most perfectly tuned server.

I fix cars not networks. You might as well speak in Egyptian, because that would mean more to me than anything you just said. Who has networking issues? What kind of issues? How did you determine that? What the heck is jitter? How do I get that fixed? What do I say to the monkey on the phone at Verizon to get them to stop blowing me off?

[Raist]

As noted in Blizzard's tracert guide that I keep referring people to, the response times should be tight. There should not be a massive variance between the times at the same hop. That is a big warning sign that something is going bad around that point of the route--could be signalling issue, or over-utilization...congestion is on the rise and their is potential for lost/delayed/retransmitted packets because of it. If you see intermittent * events at one hop, that means you lost packets. Again...often a sign of an overloaded network segment or other technical difficulties are negatively impacting the session. That is part of the problem with using some tools like WinMTR... you aren't able to get a better picture of just where the numbers actually stand. Tracert and ping are the more popular tools--simple, quick snapshots that allow you to better track the numbers to see just what/where the anomalies are rearing their ugly heads.

Basically, you should NOT see a swing of even 50% across the response times at one hop. Granted, depending on what the norm is you can still manage with a high variance, but if it jumps by 100% you are pretty much looking at trouble...and in your example you go beyond even that point.

Think of it like reading your O2 sensor data. If you see the downstream sensor bouncing all over the map from extremely low to extremely high in an erratic fashion...it sets off a red flag for you to take a closer look at your exhaust system and such.

Just for some recent examples, using tracert as described in that blogpost:

This is a trace from the other night when Time Warner, TATA, Level3, Verizon and others were reporting problems in NY/NJ, Atlanta, Ashburn, Nashville, Memphis, and Austin. Things were getting choppy in the game for me, but it was still playable because I am in SC and was only mildly affected by Ashburn, but it was frustrating when you are used to smooth gameplay--for others it was completely debilitating because they were getting a double/triple whammy along the way:

Tracing route to neolobby02.ffxiv.com [199.91.189.74]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  LPTSRV [10.10.100.1]
  2    40 ms    13 ms    18 ms  cpe-75-176-160-1.sc.res.rr.com [75.176.160.1]
  3    23 ms    31 ms    33 ms  cpe-024-031-198-005.sc.res.rr.com [24.31.198.5]
  4    14 ms    15 ms    14 ms  clmasoutheastmyr-rtr2.sc.rr.com [24.31.196.210]
  5    26 ms    26 ms    26 ms  be33.drhmncev01r.southeast.rr.com [24.93.64.180]
  6    33 ms    34 ms    90 ms  bu-ether35.asbnva1611w-bcr00.tbone.rr.com [107.14.19.42]
  7    31 ms    29 ms    62 ms  0.ae2.pr1.dca10.tbone.rr.com [107.14.17.204]
  8    53 ms    48 ms    51 ms  ix-17-0.tcore2.AEQ-Ashburn.as6453.net [216.6.87.149]
  9   133 ms   155 ms    74 ms  if-2-2.tcore1.AEQ-Ashburn.as6453.net [216.6.87.2]
 10    62 ms    62 ms    70 ms  64.86.85.1
 11   175 ms   147 ms   173 ms  if-10-2.tcore1.TTT-Toronto.as6453.net [64.86.32.33]
 12    66 ms    73 ms    70 ms  if-9-9.tcore1.TNK-Toronto.as6453.net [64.86.33.25]
 13    65 ms    75 ms    80 ms  if-7-2.tcore1.W6C-Montreal.as6453.net [66.198.96.61]
 14    75 ms    76 ms    78 ms  66.198.96.50
 15    79 ms    82 ms    80 ms  192.34.76.2
 16    79 ms    78 ms    78 ms  199.91.189.234
 17    75 ms    79 ms    78 ms  199.91.189.74

Trace complete.

Now look at it tonight, where things are running considerably more smoothly (detected a slight stutter once in a while, but no rubberbanding or big skips):

Tracing route to neolobby02.ffxiv.com [199.91.189.74]
over a maximum of 30 hops:

  1     1 ms     1 ms    <1 ms  LPTSRV [10.10.100.1]
  2    29 ms    23 ms    24 ms  cpe-75-176-160-1.sc.res.rr.com [75.176.160.1]
  3    25 ms    31 ms    31 ms  cpe-024-031-198-005.sc.res.rr.com [24.31.198.5]
  4    12 ms    14 ms    15 ms  clmasoutheastmyr-rtr2.sc.rr.com [24.31.196.210]
  5    26 ms    26 ms    26 ms  be33.drhmncev01r.southeast.rr.com [24.93.64.180]
  6    31 ms    31 ms    35 ms  bu-ether35.asbnva1611w-bcr00.tbone.rr.com [107.14.19.42]
  7    31 ms    30 ms    44 ms  0.ae2.pr1.dca10.tbone.rr.com [107.14.17.204]
  8    60 ms    55 ms    72 ms  ix-17-0.tcore2.AEQ-Ashburn.as6453.net [216.6.87.149]
  9    70 ms    74 ms    71 ms  if-2-2.tcore1.AEQ-Ashburn.as6453.net [216.6.87.2]
 10    67 ms    69 ms    67 ms  64.86.85.1
 11    71 ms    78 ms    79 ms  if-10-2.tcore1.TTT-Toronto.as6453.net [64.86.32.33]
 12    68 ms    75 ms    82 ms  if-9-9.tcore1.TNK-Toronto.as6453.net [64.86.33.25]
 13    74 ms    75 ms    72 ms  if-7-2.tcore1.W6C-Montreal.as6453.net [66.198.96.61]
 14    77 ms    73 ms    66 ms  66.198.96.50
 15    72 ms    69 ms    68 ms  192.34.76.2
 16    65 ms    70 ms    70 ms  199.91.189.234
 17    58 ms    60 ms    69 ms  199.91.189.74

Trace complete.