This has gotta be fixed

Quote:

Originally Posted by kkdubz

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

Code:

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:

Code:

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:

Code:

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:

Code:

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:

Code:

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.

Quote:

Originally Posted by kkdubz

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.