Traceroute is a fundamental tool for troubleshooting internet. But it's not that sophisticated. What it does:
1. Creates an ICMP (protocol) echo request. This basically says to the receiver "send me back whatever I said"
2. It sets the TimeToLive (TTL) field of an IP (protocol) packet. Each router that unwraps the IP packet and reads the source and destination needs to reduce this counter by 1. This is necessary to ensure that there are no stray packets running around in circles on the internet. Now, optionally, the router that reduces this counter to 0 can respond with a time out packet to the sender including his IP. However, a router may choose not to do this because it's really busy or it doesn't want to get attacked by being forced to send many time out packets, or any other reason.
3. The traceroute tool will receive any time out packets and report the IP of the router that the packet died. By starting with the TTL field to 1 and increasing till the packet reaches its destination (without dying), it is able to report most of the middle routers (because they responded).
4. The receiver of an ICMP echo request can choose not to respond (just as the routers can choose not to send a time out packet). In that case, traceroute will keep sending packets with a TTL field up to a default value (30?) and then stop.
By the above description you can understand that there are a lot of flaws and things that this tool can't troubleshoot. But anyway, here's my traceroute:
Khyber:
Wayfinder:Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
>tracert 74.201.106.23
Tracing route to 74.201.106.23 over a maximum of 30 hops
...
8 75 ms 74 ms 74 ms be3020.rcr21.fra06.atlas.cogentco.com [130.117.1
5.193]
9 74 ms 74 ms 73 ms be2305.ccr42.fra03.atlas.cogentco.com [154.54.74
.77]
10 85 ms 84 ms 84 ms be2262.ccr42.ams03.atlas.cogentco.com [154.54.37
.33]
11 91 ms 91 ms 92 ms be2183.ccr22.lpl01.atlas.cogentco.com [154.54.58
.69]
12 168 ms 169 ms 168 ms be2387.ccr22.bos01.atlas.cogentco.com [154.54.44
.165]
13 169 ms 169 ms 168 ms te3-2.ccr01.bos06.atlas.cogentco.com [154.54.46.
130]
14 168 ms 167 ms 168 ms 38.104.252.70
15 157 ms 158 ms 158 ms border1.te7-1-bbnet1.bsn003.pnap.net [63.251.128
.43]
16 158 ms 158 ms 158 ms turbine-7.border1.bsn003.pnap.net [64.95.76.202]
17 159 ms 158 ms 158 ms 74.201.102.170
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.
21 * ^C
Seems like both are reaching their destination, Turbine servers. (I don't expect the game servers to respond to echo requests...)>tracert 74.201.106.53
Tracing route to 74.201.106.53 over a maximum of 30 hops
...
7 90 ms 89 ms 89 ms be3030.agr21.fra03.atlas.cogentco.com [130.117.1
4.217]
8 80 ms 79 ms 81 ms be2184.ccr41.fra03.atlas.cogentco.com [130.117.4
8.70]
9 85 ms 84 ms 84 ms be2261.ccr41.ams03.atlas.cogentco.com [154.54.37
.29]
10 98 ms 97 ms 98 ms be2182.ccr21.lpl01.atlas.cogentco.com [154.54.77
.246]
11 160 ms 158 ms 160 ms be2386.ccr21.bos01.atlas.cogentco.com [154.54.44
.161]
12 163 ms 161 ms 161 ms te3-4.ccr01.bos06.atlas.cogentco.com [154.54.46.
134]
13 171 ms 171 ms 171 ms 38.104.252.70
14 160 ms 159 ms 160 ms border1.te8-1-bbnet2.bsn003.pnap.net [63.251.128
.107]
15 159 ms 161 ms 159 ms turbine-7.border1.bsn003.pnap.net [64.95.76.202]
16 160 ms 161 ms 161 ms 74.201.102.170
17 * * * Request timed out.
18 * * ^C
But what does this prove? Absolutely nothing (except maybe the route my packets take). Maybe by playing the time I took this traceroute I wouldn't lag in Khyber server. Maybe the route changes from time to time. Maybe someone that is not answering behind this 74.201.102.170 is dropping packets.
He is absolutely right. Lag can be in:I had a discussion about lag with Cordovan many months ago.
My approach was to try and determine whether changing graphic settings would help the situation any.
He was interested, but reminded me not to think too binary on lag, that it is a complex issue with many variables.
- The user machine
- The network
- The server
We have ruled out user machines (hence all graphic settings, RAM, etc.) because people with various computers are experiencing this and also the same game played on another server runs just fine.
We haven't ruled out the network, but the network is large. We have certainly ruled out any ISPs close to the users. We can't do or say anything about Turbine networking.
And we suspect it's the server. Why?
- Because the lag is focused on one server.
- Because game objects that should never get their triggers from the network (by assuming good game design), are losing their triggers (chests not unlocking when the boss is killed while lagging, traps not activating while stepping on them while lagging, Area of Effect spells on mosters not going away when the monster moves out of the area while lagging, etc.).
- Because the in game tool for connection diagnosis does not show any packet drops but instead shows MUCH less incoming and outgoing traffic when lagging and massive traffic when getting out of lag
- Because the lag is not total. If something on Turbine's network is broken, then the whole Khyber server should be offline.
- Because the lag is starting to affect other servers too (could even affect LOTRO if they share computing resources).