Packet loss in Brazil server

The Sao Paulo server has been having issues very often now, for about a month, intermitently. Here's the WinMTR report for today at the time of this post.

"

Magritte wrote:

| as36351.saopaulo.sp.ix.br - 4 | 345 | 334 | 33 | 47 | 133 | 34 |

This is where the packet loss begins, and it isn't the server or GGG's ISP.

You can e-mail the WinMTR log to techsupport@grindinggear.com if you want, but they won't be able to help directly. The most they can probably do is forward your log on for you.

"

Fitzy_GGG wrote:

but have not had much lunch in garnering a reply from them.

:P i think someone is hungry

I have the same problem
Is it really so hard to fix this? I have died many times in HC becouse of lag spikes

"

garantivil wrote:

Is it really so hard to fix this?

Contact Núcleo de Informação e Coordenação do Ponto BR and ask.

They’re the ones who own the node.

"

Sarno wrote:

They’re the ones who own the node.

So, how can you tell that the problem is in their end? I've been trying to search some ways of helping GGG but I had no success.

I tried contacting some people from info shared in another thread, but also no success.


Edit: I see how did you get the info, Sarno. Thanks for helping!!

"

awterado wrote:

So, how can you tell that the problem is in their end?

Okay, so there's various rules of thumb when it comes to reading a WinMTR. Some stuff you just pick up over time; the more WinMTRs you see, the better your ability to recognise what is odd or different about one. And that's really what you look for in a WinMTR.

Latency is expected to gradually increase with distance - if you ping your internet modem, then ping a server in another country, the response from your modem should arrive before the other response (not least because the other ping goes through your modem to get to the server). So when judging latency, what is acceptable depends on the distance traveled.

One thing that is never okay is packet loss. That shouldn't exist, if it exists there's a problem, and the distance traveled before it emerges is irrelevant. Packet loss isn't like having a bad download speed or high latency - when a packet is lost, it simply never arrived. Packet loss, in a nutshell, is your internet connection not working. That is unacceptable.

If you look at Magritte's WinMTR, you'll see the following;

• 0% packet loss. 389 packets sent, 389 responses.
• 0% packet loss. 367 packets sent, 367 responses.
• 0% packet loss. 389 packets sent, 389 responses.
• 0% packet loss. 389 packets sent, 389 responses.
• 4% packet loss. 345 packets sent, 334 responses.

Sometimes you'll see packet loss reported, but it'll only be for one hop. The traffic to each hop goes through the previous hops to get there. If packet loss is shown on one hop, but later hops don't have any, that means your traffic is being forwarded normally. The "packet loss" is most likely traffic management, which is less likely to impact "legitimate" traffic. WinMTR uses ICMPs, which are sometimes treated differently than more commonly used protocols.

In Magritte's WinMTR we see (approximately) 4% packet loss reported for every subsequent hop, so we can conclude the first hop with packet loss is probably responsible.

You might point at hop 2 and ask why I didn't blame that hop. A ping of 4,087 ms?! An average ping of 168 ms? Only on hop 2, with minimal distance traveled? Well, perhaps I should have and not doing so was a mistake. These things are largely a matter of judgement. I saw that the packet loss persisted through the rest of the file, and that the high latency on hop 2 did not. Maybe it's traffic management, maybe it isn't. The packet loss is definitely a problem, and so should be corrected. If Magritte posts a WinMTR with no packet loss and similarly bad latency on hop 2, that would be what I would investigate next. If someone read the same WinMTR and concluded hop 2 was the priority, they wouldn't necessarily be wrong. It's normally best practice to begin at the first sign of a problem, and work your way from there. I made a judgement call not to do so, but if someone disagreed, I wouldn't mind so long as they did so politely.

I hope this helps. :)

Oooh man, that's some massive information. Again, thank you Sarno. I've contacted Núcleo de Informação e Coordenação do Ponto BR, I'll update when they get back to me.

"

awterado wrote:

Oooh man, that's some massive information. Again, thank you Sarno. I've contacted Núcleo de Informação e Coordenação do Ponto BR, I'll update when they get back to me.

How did you do such contact? Better have been with a fork and a torch in hands. If you don't, i will.
Already buying the tickets (lul)