Random Disconnects on All Realms (WinMRT Results Inside)

"

SlippyCheeze wrote:

All I can really say is that the first poster had no signs of network problems (eg: they should talk to GGG), and yours shows signs of packet loss starting inside your network and carrying on.

"

| po1.fcr01.sr01.ams01.networklayer.com - 4 | 357 | 346 | 34 | 39 | 277 | 34 |

"

jormaerik wrote:

From the OP:

"

| po1.fcr01.sr01.ams01.networklayer.com - 4 | 357 | 346 | 34 | 39 | 277 | 34 |

Now I'm not an expert at looking through WinMTR logs, but I would say that line struck my eye as he seems to have packetloss exactly at the same hop as I did. Or what does the first number (4) in this case mean? Mind you, you can play the game uninterrupted for minutes to half an hour, and then you get a sudden freeze (most likely when the packet loss occurs.) and nothing but exiting the game helps at that point.

"

SlippyCheeze wrote:

"

jormaerik wrote:

From the OP:

"

| po1.fcr01.sr01.ams01.networklayer.com - 4 | 357 | 346 | 34 | 39 | 277 | 34 |

Now I'm not an expert at looking through WinMTR logs, but I would say that line struck my eye as he seems to have packetloss exactly at the same hop as I did. Or what does the first number (4) in this case mean? Mind you, you can play the game uninterrupted for minutes to half an hour, and then you get a sudden freeze (most likely when the packet loss occurs.) and nothing but exiting the game helps at that point.

Up front: you turn out to be wrong, but your assumptions are very reasonable, and sensible. Also, let me know if I over-explain or under-explain any of this, because it is hard to get the exact level right when I don't know you well. :)

So, the way that this diagnostic is done is that a set of packets are set out with a set of incrementing "TTL", or "time to live", fields. When you forward a packet to another host, you decrement the TTL, and when it hits zero, you throw away the packet. You also send back an error message to the original host, telling them about it.

WinMTR basically counts "packets sent with TTL N, and where the error messages come from", and uses that to build the list of hops - and to estimate packet loss, by counting the number of "missing" error messages.

Some routers, meanwhile, will throw away some or all of the TTL expired packets but *not* send back an error message. It takes time, and CPU, to generate the messages, and we "know" that they are almost always generated either in a serious error (where the message won't help much) or because someone is doing a WinMTR style test.

Because of that, we sometimes see a trace that looks like this:

| ae6.dar01.sr01.ams01.networklayer.com - 0 | 400 | 400 | 33 | 33 | 53 | 53 |
| po1.fcr01.sr01.ams01.networklayer.com - 4 | 357 | 346 | 34 | 39 | 277 | 34 |
| f0.4a.3a25.ip4.static.sl-reverse.com - 0 | 400 | 400 | 34 | 34 | 37 | 34 |

That is, your cited hop above, but with the one before and one after, for context.

Now, when we see no packet loss at the hop before, a sudden jump on a hop, and then the packet loss go back down to zero afterwards we can assume - and it is just an assumption, like the rest of this - that it is a router behaving as described above. It isn't responding to all packets sent to itself, but it passes every single packet for the next hop through correctly.

If it wasn't passing them through we would see the next hop is (statistically) the same or greater level of packet loss, because both packets "to" po1, and packets going "past" po1, would be equally hit by the drops. (packet loss drops are statistically random, so they should hit everything equally, in the common case. very occasionally you will see a slightly lower number of drops at a host after the packet loss, just because statistics and low sample counts, but they should follow the general rule.)

So: po1 looks like a busy router, which doesn't respond to all TTL expirations with ICMP error messages. This will be consistent across tests, because it is a property of the individual machine, but it also consistently returns to the standard level of packet loss at the next hop.

For the OP that was a return to zero, for you, a return to 0.4 percent packet loss. So, we can say that the traces show strong evidence that:

A) po1 is a router that discards some ICMP errors instead of sending them out, which is "vaguely wicked" according to the standards that define the Internet, but not actually real-world significant.

B) the original trace shows no evidence of network path related packet loss or latency jumps during the period sampled, so it *probably* isn't caused by network issues in their case. (ie: GGG should investigate further for latency within their servers.)

C) your trace shows some packet loss, and while 0.4 percent sounds very small, it is enough that it can cause notable problems, especially if they are clustered together in time. (eg: you lost 0.4 percent of 400 packets or whatever, but you lost them all in the same chunk of time, so it delayed stuff more significantly.)

One reason I personally recommend PingPlotter vs WinMTR to people, incidentally, is that it shows a time-oriented graph with packet loss and latency, which can make that time relationship very obvious, while WinMTR just gives us the "statistically, over the whole time tested" results.