TATA Communications - the reason we're lagging

[Lumerein]

I've noticed a similar issue from Virginia in the US on Gilgamesh (NA/EU). The past few times my latency has become particularly bad (sometimes coupled with Error 90000) I've done a pathping to the server IP shown by Resource Monitor. Each time I notice 5 - 20% or so packet loss at hops starting with those owned by Global Telecom & Technology (which apparently bought Tinet, the network showing in hops 7 - 9 below).

An example:

            Source to Here   This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address

  1    1ms     0/ 100 =  0%     0/ 100 =  0%  192.168.1.1
                                0/ 100 =  0%   |
  2   10ms     0/ 100 =  0%     0/ 100 =  0%  96.120.18.41
                                0/ 100 =  0%   |
  3   11ms     0/ 100 =  0%     0/ 100 =  0%  te-1-4-ur01.frontroyal.va.richmond.comcast.net [68.86.126.41]
                                0/ 100 =  0%   |
  4   17ms     0/ 100 =  0%     0/ 100 =  0%  xe-5-0-2-0-ar02.charlvilleco.va.richmond.comcast.net [69.139.165.165]
                                0/ 100 =  0%   |
  5   18ms     0/ 100 =  0%     0/ 100 =  0%  pos-1-4-0-0-cr01.ashburn.va.ibone.comcast.net [68.86.95.21]
                                0/ 100 =  0%   |
  6   16ms     0/ 100 =  0%     0/ 100 =  0%  be-10-pe04.ashburn.va.ibone.comcast.net [68.86.84.202]
                                0/ 100 =  0%   |
  7   17ms     0/ 100 =  0%     0/ 100 =  0%  xe-7-0-2.was10.ip4.tinet.net [77.67.71.193]
                                0/ 100 =  0%   |
  8  113ms     5/ 100 =  5%     5/ 100 =  5%  xe-1-3-0.mtl10.ip4.tinet.net [89.149.184.74]
                                0/ 100 =  0%   |
  9  109ms    14/ 100 = 14%    14/ 100 = 14%  ormuco-gw.ip4.tinet.net [216.221.156.110]
                                0/ 100 =  0%   |
 10  113ms     3/ 100 =  3%     3/ 100 =  3%  192.34.76.2
                                0/ 100 =  0%   |
 11   35ms     0/ 100 =  0%     0/ 100 =  0%  199.91.189.234
                                1/ 100 =  1%   |
 12   34ms     1/ 100 =  1%     0/ 100 =  0%  199.91.189.24

This trace wasn't as bad as some of the others I've seen. I've seen 15 - 30% loss on three different hops before, usually starting at hop 8 or 9.

Tracing route to traceip.ffxiv.com [202.67.52.81]

Are you sure that's your server IP? Judging by your forum info, you play on Leviathan, which should be in the NA datacenter and probably have an IP in a similar range to Gilgamesh. However, there are .jp domains along the route, not to mention the traceip.ffxiv.com domain name there. While logged into the game on your character, open Resource Monitor, go to the Network tab, and check ffxiv.exe as a filter in the top panel. You should see two connections listed in the second panel, showing the IP address of your server in the Remote Address column. Try running a pathping to that IP.

[Noshpan]

Are you sure that's your server IP? Judging by your forum info, you play on Leviathan, which should be in the NA datacenter and probably have an IP in a similar range to Gilgamesh. However, there are .jp domains along the route, not to mention the traceip.ffxiv.com domain name there. While logged into the game on your character, open Resource Monitor, go to the Network tab, and check ffxiv.exe as a filter in the top panel. You should see two connections listed in the second panel, showing the IP address of your server in the Remote Address column. Try running a pathping to that IP.

I copied the wrong one and didn't realize it until now. ;^_^ Thanks for pointing that out. I ran it again to be more current.

Pathping

Tracing route to 199.91.189.46 over a maximum of 30 hops

  1  192.168.1.1
  2  98.192.180.1
  3  te-7-2-ur01.hanford.ca.ccal.comcast.net [68.85.105.177]
  4  te-8-1-ur01.vanness.ca.ccal.comcast.net [68.87.200.41]
  5  68.86.92.181
  6  pos-0-1-0-0-pe01.529bryant.ca.ibone.comcast.net [68.86.87.2]
  7  ix-2-3-0-0.tcore1.PDI-PaloAlto.as6453.net [66.198.127.17]
  8     *     if-2-2.tcore2.PDI-PaloAlto.as6453.net [66.198.127.2]
  9  if-11-3.tcore2.CT8-Chicago.as6453.net [66.198.144.58]
 10  if-3-2.tcore1.W6C-Montreal.as6453.net [66.198.96.45]
 11  66.198.96.50
 12  192.34.76.2
 13  199.91.189.234
 14  199.91.189.46

Computing statistics for 350 seconds...

Tracert

Tracing route to 199.91.189.46 over a maximum of 30 hops

  1     1 ms     2 ms     2 ms  192.168.1.1
  2    22 ms    29 ms    30 ms  98.192.180.1
  3    12 ms    11 ms    13 ms  te-7-2-ur01.hanford.ca.ccal.comcast.net [68.85.105.177]
  4    18 ms    17 ms    20 ms  te-8-1-ur01.vanness.ca.ccal.comcast.net [68.87.200.41]
  5    25 ms    23 ms    23 ms  68.86.90.21
  6    41 ms    27 ms    26 ms  pos-0-1-0-0-pe01.529bryant.ca.ibone.comcast.net
[68.86.87.2]
  7    23 ms    22 ms    22 ms  ix-2-3-0-0.tcore1.PDI-PaloAlto.as6453.net [66.198.127.17]
  8     *      110 ms     *     if-2-2.tcore2.PDI-PaloAlto.as6453.net [66.198.127.2]
  9   123 ms   109 ms   114 ms  if-11-3.tcore2.CT8-Chicago.as6453.net [66.198.144.58]
 10   117 ms   110 ms   109 ms  if-3-2.tcore1.W6C-Montreal.as6453.net [66.198.96.45]
 11    96 ms    96 ms    98 ms  66.198.96.50
 12    97 ms    96 ms    97 ms  192.34.76.2
 13    95 ms    97 ms    96 ms  199.91.189.234
 14    97 ms    96 ms    96 ms  199.91.189.46

Trace complete.

It's like once it leaves California, everything goes down the crapper. Mind you, I do have Comcast business class.

[Lumerein]

Yup, looks like you're probably experiencing a similar problem with latency spikes and dropped packets.

Also, in the future you should let pathping finish to get the most useful results for what it's meant to do. The "Computing statistics for 350 seconds..." line indicates that pathping is running a set of ping tests to each hop along the route. That way you can see if there are intermittent packet loss issues in certain places that a tracert or a short ping may not find. After that finishes, you'll get a table like the one I posted in my reply above, where you can see "x/100" dropped packets and a loss percentage for each hop.

[Noshpan]

Yup, looks like you're probably experiencing a similar problem with latency spikes and dropped packets.

Also, in the future you should let pathping finish to get the most useful results for what it's meant to do. The "Computing statistics for 350 seconds..." line indicates that pathping is running a set of ping tests to each hop along the route. That way you can see if there are intermittent packet loss issues in certain places that a tracert or a short ping may not find. After that finishes, you'll get a table like the one I posted in my reply above, where you can see "x/100" dropped packets and a loss percentage for each hop.

I waited 45 minutes for that to finish. It never did. I was like "Wellp, I'll just copy what I've been able to get since it's just gonna sit there with it's thumb up its backside."