For Those with Time Warner Cable( Lag Issue)

[MogVII]

If a VPN doesn't fix anything that means that your ISP isn't able to give you a decent connection since the early nodes. I would start looking for a way to change your ISP.

That's entirely possible but I've never had a problem with them in 14 years of gaming. Squenix rep did a tracert to my public IP and said they have a problem at 4.34.69.66.

VPN or not, the problem is in the same place every trace:

8 35 ms 36 ms 36 ms ae-10-10.car2.Montreal2.Level3.net [4.69.153.86]
9 36 ms 35 ms 34 ms ORMUCO-COMM.car2.Montreal2.Level3.net [4.59.178.74]
10 * * * Request timed out.
11 36 ms 37 ms 35 ms 192.34.76.2
12 47 ms 38 ms 35 ms 199.91.189.234

[ninesunz]

That's entirely possible but I've never had a problem with them in 14 years of gaming. Squenix rep did a tracert to my public IP and said they have a problem at 4.34.69.66.

VPN or not, the problem is in the same place every trace:

8 35 ms 36 ms 36 ms ae-10-10.car2.Montreal2.Level3.net [4.69.153.86]
9 36 ms 35 ms 34 ms ORMUCO-COMM.car2.Montreal2.Level3.net [4.59.178.74]
10 * * * Request timed out.
11 36 ms 37 ms 35 ms 192.34.76.2
12 47 ms 38 ms 35 ms 199.91.189.234

Where's your problem? you have super good latency to SE, that node 10 just doesn't reply to ping requests, everyone gets that.
Try ping plotter, it will do constant tracert for you and keep a log.

[DSN]

The Sqenix rep said their issue was my hop 5 (which was their hop 16 to me) to them which at the time was 4.34.69.66

Hop Sent Err PL% Min Max Avg Host Name / [IP]
1 100 0 0.0 0 0 0 bogon [192.168.1.1]
2 100 0 0.0 5 19 7 [10.139.0.1]
3 100 0 0.0 7 35 14 crr01euclwi-tge-0-4-0-6.eucl.wi.charter.com [96.34.22.76]
4 100 0 0.0 8 20 11 bbr01euclwi-bue-4.eucl.wi.charter.com [96.34.2.4]
5 100 0 0.0 13 56 18 [4.34.69.69]
6 100 0 0.0 34 52 36 vl-3504-ve-118.ebr1.Chicago2.Level3.net [4.69.158.14]
7 100 0 0.0 34 49 37 ae-6-6.ebr1.Chicago1.Level3.net [4.69.140.189]
8 100 7 7.0 34 246 56 ae-10-10.car2.Montreal2.Level3.net [4.69.153.86]
9 100 0 0.0 34 52 36 ORMUCO-COMM.car2.Montreal2.Level3.net [4.59.178.74]
10 100 100 100.0 0 0 0 [-]
11 100 0 0.0 34 86 38 [192.34.76.2]
12 100 0 0.0 34 45 36 [199.91.189.234]
13 100 0 0.0 34 46 36 [199.91.189.58]

... sounds like asymmetrical or non-optimal routing problems on the return path (from Squenix to you)

[MogVII]

... sounds like asymmetrical or non-optimal routing problems on the return path (from Squenix to you)

Thank you for confirming my suspicions! I later realized ICMP was probably disabled on the router at hop 10. It has to be something from Sqenix/their hosting. I've had the same ISP for 14 years and they have honestly been great. I created some chars on JP servers and ran around. Ping spikes to 480 at the most but pretty much stayed between 30-120.

I've seen hundreds to thousands of posts from people experiencing the same thing. No response from Sqenix that I've seen to even acknowledge that it's an issue, but please correct me if I'm wrong. I've reached a point in end game where I'm no longer contributing, but am a burden. I don't want to quit service but it doesn't appear as though they're going to admit this is a problem, much less fix for quite some time.

[Raist]

Thank you for confirming my suspicions! I later realized ICMP was probably disabled on the router at hop 10. It has to be something from Sqenix/their hosting. I've had the same ISP for 14 years and they have honestly been great. I created some chars on JP servers and ran around. Ping spikes to 480 at the most but pretty much stayed between 30-120.

I've seen hundreds to thousands of posts from people experiencing the same thing. No response from Sqenix that I've seen to even acknowledge that it's an issue, but please correct me if I'm wrong. I've reached a point in end game where I'm no longer contributing, but am a burden. I don't want to quit service but it doesn't appear as though they're going to admit this is a problem, much less fix for quite some time.

Your problem may very well be closer to home for you. Shortly after the game launched, we did some digging with some looking glasses in different regions, and both the Seatle and the Chicago/Milwaukee corridors were having problems with packet loss breaking the 25% mark. Seeing as 4.34.69.66 looks to be in Colorado....chances are you may be running through one of those troubled sections as well? Hard to say without seeing more of your connection before it hits the Montreal area. Here's the details on that IP:
http://myip.ms/info/whois/4.34.69.66

That hop you are seeing the timeouts at is probably the 10.2.2.1 IP, which is in the reserved private IP subnet. IDK why my systems keep showing results from that hop most of the time... might be because we use the same top level subnet, who knows.

If you run a pathping instead of tracert, it will give you a list of all the IP's it hits in the route first, before it runs the actual traces to each hop. This will actually give more useful data, as it hits each hop 100 times and gives a sent/return stat with % loss, as well as gives some hint if there are issues with forwarding between hops as well and not just the straight pings to each hop. It takes a while to run though, just be patient with it...even though it isn't spitting any info on the screen for 7 or 8 minutes, it is running the tests.

Here's a sample of a pathping result:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\DarrenBoyd>pathping 199.91.189.74

Tracing route to 199.91.189.74 over a maximum of 30 hops

  <initial hops removed for security>

  4  xe-7-0-0.chrlncpop-rtr1.southeast.rr.com [24.93.64.42]
  5  bu-ether34.atlngamq46w-bcr00.tbone.rr.com [107.14.19.48]
  6  ae-0-0.pr0.atl20.tbone.rr.com [66.109.6.171]
  7  te0-0-0-10.ccr21.atl02.atlas.cogentco.com [154.54.12.109]
  8  be2052.mpd21.atl01.atlas.cogentco.com [154.54.40.249]
  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.ymq02.atlas.cogentco.com [154.54.3.134]
 12  38.122.42.34
 13  10.2.2.1
 14  192.34.76.2
 15  199.91.189.234
 16  199.91.189.74

Computing statistics for 400 seconds...
            Source to Here   This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address
                                0/ 100 =  0%   |
  3   21ms     0/ 100 =  0%     0/ 100 =  0%  cpe-024-031-198-009.sc.res.rr.com[24.31.198.9]
                                0/ 100 =  0%   |
  4   26ms     0/ 100 =  0%     0/ 100 =  0%  xe-7-0-0.chrlncpop-rtr1.southeast.rr.com [24.93.64.42]
                                0/ 100 =  0%   |
  5   31ms     0/ 100 =  0%     0/ 100 =  0%  bu-ether34.atlngamq46w-bcr00.tbone.rr.com [107.14.19.48]
                                0/ 100 =  0%   |
  6   31ms     0/ 100 =  0%     0/ 100 =  0%  ae-0-0.pr0.atl20.tbone.rr.com [66.109.6.171]
                                0/ 100 =  0%   |
  7   81ms     2/ 100 =  2%     2/ 100 =  2%  te0-0-0-10.ccr21.atl02.atlas.cogentco.com [154.54.12.109]
                                0/ 100 =  0%   |
  8   79ms     4/ 100 =  4%     4/ 100 =  4%  be2052.mpd21.atl01.atlas.cogentco.com [154.54.40.249]
                                0/ 100 =  0%   |
  9   90ms     3/ 100 =  3%     3/ 100 =  3%  be2170.mpd21.dca01.atlas.cogentco.com [154.54.31.106]
                                0/ 100 =  0%   |
 10   99ms     2/ 100 =  2%     2/ 100 =  2%  be2150.mpd21.jfk02.atlas.cogentco.com [154.54.31.130]
                                0/ 100 =  0%   |
 11  ---     100/ 100 =100%   100/ 100 =100%  be2108.ccr21.ymq02.atlas.cogentco.com [154.54.3.134]
                                0/ 100 =  0%   |
 12   51ms     0/ 100 =  0%     0/ 100 =  0%  38.122.42.34
                                4/ 100 =  4%   |
 13  ---     100/ 100 =100%    96/ 100 = 96%  10.2.2.1
                                0/ 100 =  0%   |
 14   68ms     4/ 100 =  4%     0/ 100 =  0%  192.34.76.2
                                1/ 100 =  1%   |
 15   67ms     7/ 100 =  7%     2/ 100 =  2%  199.91.189.234
                                0/ 100 =  0%   |
 16   66ms     5/ 100 =  5%     0/ 100 =  0%  199.91.189.74

Trace complete.

The stats on left in each line with the IP's show details on pings to each hop in turn, while the stats in between each hop (with the "|" character between each row) show details about the quality of forwarding between each hop. So basically, you get two reports in one: about 33 tracerts in the left two columns (100 pings per hop from you to each IP in the route, versus 3 in a tracert), and another report in the right two columns about what is happening between each router along the route (A to B, then B to C... not you to A, you to B, and you to C). For instance, at hops 12 and 13, I had good pings at 12 (100%), but a 4% variance was detected in the forwarding between 12 and 13:

12   51ms     0/ 100 =  0%     0/ 100 =  0%  38.122.42.34
                                4/ 100 =  4%   |
13  ---     100/ 100 =100%    96/ 100 = 96%  10.2.2.1

You can also see that there is some slight jitter within the Ormuco/SE end between each hop, in addition to what you see when they are pinged independently:
(the 1% and 2% losses in the right columns are losses between their hops, while the 4, 7, and 5% losses are from me pinging to each hop--their "internal" jitter is effecting my pings as it goes deeper into their network)

 14   68ms     4/ 100 =  4%     0/ 100 =  0%  192.34.76.2
                                1/ 100 =  1%   |
 15   67ms     7/ 100 =  7%     2/ 100 =  2%  199.91.189.234
                                0/ 100 =  0%   |
 16   66ms     5/ 100 =  5%     0/ 100 =  0%  199.91.189.74

More evidence that there are problems in multiple areas that need to be addressed--it's not just SE, and it's not just your ISP (even though each is quick to blame the other)--they BOTH need to get involved. So, when reporting your data, it would be a good idea to also go to SE's support portal and submit the data there in an official support ticket (NOT HERE--this is NOT a support forum for users to contact SE for help... it is for users to help users).


Sorry.. I imagine some of these tools may be a bit intimidating to some of you that may not be used to looking at this stuff, makes my head swim sometimes and I used to work with this crap for a living 10 years ago troubleshooting implementations and integrations. But, this is VERY useful information to help the T3 techs diagnose what is going on with your routing. Even if you don't want to diagnose things yourself or even want to learn more about the issue... it's worth the time to just run the report and copy/paste the results into an email to your ISP's techs (and SE to forward to Ormuco's techs) to give them a better roadmap of what to look for.