This has gotta be fixed

[RealBadAtNaming]

Spend a lot of money every month and I'm giving up. Like everyone else can't play without getting kicked and its gotten worse instead of bette .

[Keeper Riff]

using my screenshot at an example, where should the numbers be higher and where should the numbers be lower, in general, as there's no point in sending these in if they all turn out to be my isp

Ok, I think I can explain this one.

Example 1

1 low time <your router>
2 low time node2
3 *  *  *  node3
4 low time node4
5 low time node5

Node 3 is not configured to answer PING requests, but transfers the information just fine. Nothing to worry about.

Similar to that, Example 2:

1 low  time <your router>
2 low  time node2
3 high time node3
4 low  time node4
5 low  time node5

Node 3 has the reply to PING requests set to low priority to avoid DDOS, but transfers the information just fine. Nothing to worry about.

Example 3:

1 low  time <your router>
2 low  time node2
3 high time node3
4 high time node4
5 high time node5

Node 3 takes long to respond AND causes a significant delay to the information which passes to all subsequent nodes. If the domain name of Node 3 does not show its owner clearly, search its IP through whois databases to know who owns the faulty gateway.

Example 4:

1 low  time <your router>
2 low  time node2
3 low  time node3
4 low  time node4
5 high time node5

Only the final gateway takes long to respond and it's clearly on Trion's side, BUT there's a possibility that the high response time was caused by the gateway being configured to put PING requests on a back-burner, like it was shown in Example 2. So the high response time on the last gateway does not automatically mean you'll get poor performance when your client connects to Trion's server.

Same way, having low response time throughout the whole route does not guarantee there will be no lags. The server can quickly respond to the PING, but it still may be slow to send actual information to the client OR it'll have to wait for other servers' response in the Trion local network (e.g. billing base, zone server, exchange server, etc.)

As a live example, here's my trace:

  1    <1 мs    <1 мs    <1 мs  <my router>
  2     1 ms     1 ms     1 ms  95.31.0.1
  3     1 ms     1 ms     1 ms  zubov-bng1-local.msk.corbina.net [85.21.0.240]
  4     1 ms     1 ms     1 ms  10.2.247.0
  5    19 ms    19 ms    19 ms  m9-crs-2-be9.corbina.net [195.14.62.88]
  6    19 ms    19 ms    19 ms  195.14.62.67
  7    19 ms    20 ms    19 ms  xe-9-1-2.bar1.Stockholm1.Level3.net [213.242.110.105]
  8   127 ms   127 ms   127 ms  ae-1-51.edge1.NewYork2.Level3.net [4.69.138.194]
  9   127 ms   127 ms   127 ms  ae-1-51.edge1.NewYork2.Level3.net [4.69.138.194]
 10   130 ms   128 ms   128 ms  comcast-level3.NewYork2.level3.net [4.68.127.2]
 11   135 ms   135 ms   135 ms  be-10103-cr02.ashburn.va.ibone.comcast.net [68.86.85.161]
 12   148 ms   149 ms   149 ms  be-10114-cr02.56marietta.ga.ibone.comcast.net [68.86.85.10]
 13   167 ms   166 ms   167 ms  be-11424-cr02.dallas.tx.ibone.comcast.net [68.86.85.22]
 14   167 ms   167 ms   166 ms  be-17-pe02.1950stemmons.tx.ibone.comcast.net [68.86.83.122]
 15   166 ms   166 ms   184 ms  66.208.216.210
 16   166 ms   166 ms   166 ms  dal-r09-fcp.dal.triongames.com [208.94.26.5]

My most limiting factor is the Stockholm — New York line which is understandable knowing the distance.

Side question: Let's say my isp was running fine, and my pc detected latency issues, would my results still be useful (in your opinion) even though I play on a console? Or would there be too much of a difference?

Depending on how the network play for consoles is organized, this may spread from "what you see on PC is what you get on console" if the console connects to trion servers using the same route as PC and the server IP is the same or at least they share the same subnet, to "you can only test the part of the route passing through your ISP" if the console connects to Microsoft network and Microsoft server works as a proxy to pass the data to Trion servers.