WinMTR Traceroute does not reflect in-game ping

My in-game ping bar and personal experience shows me getting 200-400ms in many instances, but WinMTR tracerouts of those instances show 50-100ms. Here is an example pastebin. This instance was unplayable with 500-1000ms spikes and crazy rubberbanding. What could be the problem?

|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.0.1 - 0 | 560 | 560 | 0 | 0 | 6 | 0 |
| 10.43.0.1 - 0 | 560 | 560 | 3 | 6 | 19 | 6 |
| 192.168.145.185 - 0 | 560 | 560 | 3 | 10 | 253 | 3 |
| 1.249.20.217 - 0 | 560 | 560 | 3 | 8 | 172 | 5 |
| 10.105.0.210 - 0 | 560 | 560 | 3 | 8 | 32 | 3 |
| 10.222.12.234 - 0 | 560 | 560 | 10 | 17 | 34 | 13 |
| 175.124.54.85 - 0 | 560 | 560 | 10 | 15 | 31 | 15 |
| 10.222.6.92 - 0 | 560 | 560 | 11 | 15 | 28 | 13 |
| 210.180.97.13 - 0 | 560 | 560 | 42 | 47 | 69 | 46 |
|ix-xe-4-3-1-0.tcore2.tv2-tokyo.as6453.net - 0 | 560 | 560 | 44 | 51 | 97 | 47 |
| 180.87.181.167 - 0 | 560 | 560 | 42 | 47 | 64 | 46 |
| ae6.cbs02.eq01.tok01.networklayer.com - 66 | 155 | 53 | 0 | 100 | 137 | 100 |
| 38.10.35a9.ip4.static.sl-reverse.com - 16 | 347 | 293 | 96 | 99 | 139 | 103 |
| 83.76.c0a5.ip4.static.sl-reverse.com - 14 | 368 | 319 | 96 | 100 | 121 | 98 |
| a7.76.c0a5.ip4.static.sl-reverse.com - 10 | 403 | 363 | 94 | 98 | 115 | 100 |
| d9.4b.c0a5.ip4.static.sl-reverse.com - 18 | 332 | 275 | 93 | 96 | 104 | 94 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider
Last bumped on Aug 14, 2020, 9:31:11 AM
This is where the problem starts: ae6.cbs02.eq01.tok01.networklayer.com - 66 | 155 | 53 | 0 | 100 | 137 | 100 |

You are getting SEVERE packet loss. How the hell you even stay connected is beyond me.

Email techsupport@grindinggear.com and send them your MTR as well. Let them know that you're getting severe PL starting with their provider. This way, GGG can forward this on to their provider to get that fixed.
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning."

"Your mother was a hamster and your father smelt of elderberries!"
Last edited by Aragorn14 on Aug 13, 2020, 1:09:30 PM
"
Aragorn14 wrote:
This is where the problem starts: ae6.cbs02.eq01.tok01.networklayer.com - 66 | 155 | 53 | 0 | 100 | 137 | 100 |

You are getting SEVERE packet loss. How the hell you even stay connected is beyond me.

Email techsupport@grindinggear.com and send them your MTR as well. Let them know that you're getting severe PL starting with their provider. This way, GGG can forward this on to their provider to get that fixed.


Thanks for your advice. I don't understand how to identify whether or not packet loss from WinMTR is some server-side traffic-control strategy and sometimes it's real. I have several other WinMTRs with 40%+ packet loss at some nodes and I was told that it was not a real problem. How can I figure it out? Or was I being misled before?

|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.0.1 - 0 | 536 | 536 | 0 | 0 | 2 | 0 |
| 10.43.0.1 - 0 | 536 | 536 | 3 | 13 | 104 | 8 |
| 192.168.145.185 - 0 | 536 | 536 | 3 | 17 | 257 | 9 |
| 1.249.20.217 - 0 | 536 | 536 | 4 | 15 | 143 | 8 |
| 10.105.0.208 - 0 | 536 | 536 | 4 | 14 | 141 | 8 |
| 10.222.11.76 - 0 | 536 | 536 | 10 | 25 | 149 | 22 |
| 10.222.21.161 - 0 | 536 | 536 | 10 | 23 | 147 | 17 |
| 58.229.14.77 - 0 | 536 | 536 | 11 | 25 | 149 | 18 |
| 210.180.97.13 - 0 | 536 | 536 | 43 | 54 | 172 | 50 |
|ix-xe-4-3-1-0.tcore2.tv2-tokyo.as6453.net - 0 | 536 | 536 | 42 | 57 | 182 | 59 |
| 180.87.181.167 - 0 | 536 | 536 | 42 | 55 | 180 | 52 |
| ae6.cbs02.eq01.tok01.networklayer.com - 39 | 213 | 132 | 0 | 109 | 194 | 100 |
| 3a.10.35a9.ip4.static.sl-reverse.com - 11 | 373 | 332 | 0 | 104 | 224 | 98 |
| 8b.76.c0a5.ip4.static.sl-reverse.com - 11 | 377 | 337 | 95 | 105 | 188 | 97 |
| a7.76.c0a5.ip4.static.sl-reverse.com - 16 | 334 | 283 | 94 | 103 | 196 | 97 |
| 74.53.c0a5.ip4.static.sl-reverse.com - 16 | 328 | 276 | 95 | 104 | 188 | 97 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

Here's an example that I was told was not real packet loss.
Last edited by Arakura on Aug 14, 2020, 12:04:06 AM
|ix-xe-4-3-1-0.tcore2.tv2-tokyo.as6453.net - 0 | 536 | 536 | 42 | 57 | 182 | 59 <-- normal|
| 180.87.181.167 - 0 | 536 | 536 | 42 | 55 | 180 | 52 |<-- normal
| ae6.cbs02.eq01.tok01.networklayer.com - 39 | 213 | 132 | 0 | 109 | 194 | 100 |<-- SEVERE packet loss which continues in subsequent nodes
| 3a.10.35a9.ip4.static.sl-reverse.com - 11 | 373 | 332 | 0 | 104 | 224 | 98 |
| 8b.76.c0a5.ip4.static.sl-reverse.com - 11 | 377 | 337 | 95 | 105 | 188 | 97 |
| a7.76.c0a5.ip4.static.sl-reverse.com - 16 | 334 | 283 | 94 | 103 | 196 | 97 |
| 74.53.c0a5.ip4.static.sl-reverse.com - 16 | 328 | 276 | 95 | 104 | 188 | 97 |
𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣𓆣 SCARABS!
Last edited by xjjanie on Aug 14, 2020, 1:05:45 AM
"
Arakura wrote:
"
Aragorn14 wrote:
This is where the problem starts: ae6.cbs02.eq01.tok01.networklayer.com - 66 | 155 | 53 | 0 | 100 | 137 | 100 |

You are getting SEVERE packet loss. How the hell you even stay connected is beyond me.

Email techsupport@grindinggear.com and send them your MTR as well. Let them know that you're getting severe PL starting with their provider. This way, GGG can forward this on to their provider to get that fixed.


Thanks for your advice. I don't understand how to identify whether or not packet loss from WinMTR is some server-side traffic-control strategy and sometimes it's real. I have several other WinMTRs with 40%+ packet loss at some nodes and I was told that it was not a real problem. How can I figure it out? Or was I being misled before?

|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.0.1 - 0 | 536 | 536 | 0 | 0 | 2 | 0 |
| 10.43.0.1 - 0 | 536 | 536 | 3 | 13 | 104 | 8 |
| 192.168.145.185 - 0 | 536 | 536 | 3 | 17 | 257 | 9 |
| 1.249.20.217 - 0 | 536 | 536 | 4 | 15 | 143 | 8 |
| 10.105.0.208 - 0 | 536 | 536 | 4 | 14 | 141 | 8 |
| 10.222.11.76 - 0 | 536 | 536 | 10 | 25 | 149 | 22 |
| 10.222.21.161 - 0 | 536 | 536 | 10 | 23 | 147 | 17 |
| 58.229.14.77 - 0 | 536 | 536 | 11 | 25 | 149 | 18 |
| 210.180.97.13 - 0 | 536 | 536 | 43 | 54 | 172 | 50 |
|ix-xe-4-3-1-0.tcore2.tv2-tokyo.as6453.net - 0 | 536 | 536 | 42 | 57 | 182 | 59 |
| 180.87.181.167 - 0 | 536 | 536 | 42 | 55 | 180 | 52 |
| ae6.cbs02.eq01.tok01.networklayer.com - 39 | 213 | 132 | 0 | 109 | 194 | 100 |
| 3a.10.35a9.ip4.static.sl-reverse.com - 11 | 373 | 332 | 0 | 104 | 224 | 98 |
| 8b.76.c0a5.ip4.static.sl-reverse.com - 11 | 377 | 337 | 95 | 105 | 188 | 97 |
| a7.76.c0a5.ip4.static.sl-reverse.com - 16 | 334 | 283 | 94 | 103 | 196 | 97 |
| 74.53.c0a5.ip4.static.sl-reverse.com - 16 | 328 | 276 | 95 | 104 | 188 | 97 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

Here's an example that I was told was not real packet loss.


For it to be "real" packet loss and not a device running icmp prioritization policy, then the packets loss have to continue after that "device". If not, then it's just icmp prioritization policy.
"
HanSoloDK wrote:
"
Arakura wrote:
"
Aragorn14 wrote:
This is where the problem starts: ae6.cbs02.eq01.tok01.networklayer.com - 66 | 155 | 53 | 0 | 100 | 137 | 100 |

You are getting SEVERE packet loss. How the hell you even stay connected is beyond me.

Email techsupport@grindinggear.com and send them your MTR as well. Let them know that you're getting severe PL starting with their provider. This way, GGG can forward this on to their provider to get that fixed.


Thanks for your advice. I don't understand how to identify whether or not packet loss from WinMTR is some server-side traffic-control strategy and sometimes it's real. I have several other WinMTRs with 40%+ packet loss at some nodes and I was told that it was not a real problem. How can I figure it out? Or was I being misled before?

|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.0.1 - 0 | 536 | 536 | 0 | 0 | 2 | 0 |
| 10.43.0.1 - 0 | 536 | 536 | 3 | 13 | 104 | 8 |
| 192.168.145.185 - 0 | 536 | 536 | 3 | 17 | 257 | 9 |
| 1.249.20.217 - 0 | 536 | 536 | 4 | 15 | 143 | 8 |
| 10.105.0.208 - 0 | 536 | 536 | 4 | 14 | 141 | 8 |
| 10.222.11.76 - 0 | 536 | 536 | 10 | 25 | 149 | 22 |
| 10.222.21.161 - 0 | 536 | 536 | 10 | 23 | 147 | 17 |
| 58.229.14.77 - 0 | 536 | 536 | 11 | 25 | 149 | 18 |
| 210.180.97.13 - 0 | 536 | 536 | 43 | 54 | 172 | 50 |
|ix-xe-4-3-1-0.tcore2.tv2-tokyo.as6453.net - 0 | 536 | 536 | 42 | 57 | 182 | 59 |
| 180.87.181.167 - 0 | 536 | 536 | 42 | 55 | 180 | 52 |
| ae6.cbs02.eq01.tok01.networklayer.com - 39 | 213 | 132 | 0 | 109 | 194 | 100 |
| 3a.10.35a9.ip4.static.sl-reverse.com - 11 | 373 | 332 | 0 | 104 | 224 | 98 |
| 8b.76.c0a5.ip4.static.sl-reverse.com - 11 | 377 | 337 | 95 | 105 | 188 | 97 |
| a7.76.c0a5.ip4.static.sl-reverse.com - 16 | 334 | 283 | 94 | 103 | 196 | 97 |
| 74.53.c0a5.ip4.static.sl-reverse.com - 16 | 328 | 276 | 95 | 104 | 188 | 97 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

Here's an example that I was told was not real packet loss.


For it to be "real" packet loss and not a device running icmp prioritization policy, then the packets loss have to continue after that "device". If not, then it's just icmp prioritization policy.


Over 10% packet loss is maintained through to the end of that traceroute, though. Does that mean I was experiencing 16% packet loss while connecting to that instance?
In this case it has nothing to do with that particular instance. It starts at your 5th to last hop.
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning."

"Your mother was a hamster and your father smelt of elderberries!"

Report Forum Post

Report Account:

Report Type

Additional Info