40% packet loss on Frankfurt server with a good 16ms ping, traceroute data included

"

jikang2000 wrote:

I play with a Ethernet connection(ISP is O2 Germany) on Frankfurt server. This morning, the game seems very irresponsible that my character has a weird action delay/lag while the ping is still very good, constantly 16ms

I ran the WinMTR at 9:33 CET, it seems that there are huge packet loss on the server side.

Here is the data
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| FRITZ-NAS - 0 | 472 | 472 | 0 | 0 | 0 | 0 |
|loopback1.0001.acln.02.fra.de.net.telefonica.de - 0 | 471 | 471 | 6 | 8 | 48 | 6 |
|bundle-ether28.0001.dbrx.02.fra.de.net.telefonica.de - 0 | 471 | 471 | 6 | 7 | 9 | 7 |
|bundle-ether1.0005.prrx.02.fra.de.net.telefonica.de - 0 | 471 | 471 | 6 | 6 | 10 | 7 |
| ae-10.r03.frnkge03.de.bb.gin.ntt.net - 0 | 471 | 471 | 7 | 7 | 12 | 7 |
| ae-2.r21.frnkge13.de.bb.gin.ntt.net - 3 | 436 | 427 | 7 | 7 | 15 | 7 |
| ae-0.a01.frnkge13.de.bb.gin.ntt.net - 1 | 467 | 466 | 6 | 7 | 19 | 7 |
|xe-1-0-0.bbr01.xn01.fra01.networklayer.com - 0 | 469 | 469 | 12 | 12 | 27 | 12 |
| ae5.cbs01.xn01.fra01.networklayer.com - 41 | 182 | 109 | 12 | 12 | 16 | 13 |
| f.10.35a9.ip4.static.sl-reverse.com - 0 | 469 | 469 | 12 | 12 | 33 | 12 |
| 8f.76.5195.ip4.static.sl-reverse.com - 0 | 469 | 469 | 12 | 13 | 21 | 14 |
| a3.76.5195.ip4.static.sl-reverse.com - 0 | 469 | 469 | 12 | 12 | 15 | 13 |
| fa.56.5195.ip4.static.sl-reverse.com - 0 | 469 | 469 | 12 | 12 | 13 | 12 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

"

HanSoloDK wrote:

If you are talking about this node -->
ae5.cbs01.xn01.fra01.networklayer.com - 41 | 182 | 109 | 12 | 12 | 16 | 13 |
Then that is NOT packet loss but a device with icmp prioritization policy active. If it really was packet loss and 41% of the packet was gone, then all the other nodes after that node should show the same. Since they doesn't, then icmp prioritization policy is confirmed.