NC Outage Debby or not? Packet Loss only...

Getsco7

Anyone have any idea as to the nature of the outages in central and eastern NC? Support was unable to provide any details and suggested I call back after all the "storm related" issues are resolved.

Anyone else seeing issues with packet loss that are storm related?

William_M

Hi @Getsco7, welcome to our community!

I was able to locate your account, but I don't see you're in an area impacted by any recent outages nor am I measuring any packet loss while pinging your modem. It's showing an up time of 17 days, so before doing anything else I recommend rebooting your modem and router. If the issue persists afterward, would you please elaborate on the packet loss you are getting?

RAIST515O

Also... need to verify if packets are actually getting lost.

Sometimes policies at a hop will cause it to ignore the ICMP ECHO request, or it gets put into a delayed processing queue... but the packets themselves still get forwarded in a reasonable time (which is why they get those ignore rules set... so it can focus resources on the primary task of forwarding packets).

A couple of things to watch for:

First and foremost... If the same number of packets sent show up at the endpoint, then no packets were lost. They may have been potentially delayed, but not lost. Which leads to the next one...

Even though hops between may show weird spikes in ping responses (or no response events), that does not automatically follow that a similar impact happens at the endpoint. You may have bad inconsistency because of congested points along the way, but the stats at the end point may still be serviceable, though their may be bad jitter (variance in latency between packets)... which leads to potential issues with the protocols in play.

Want be mindful of what kind of traffic is having issues. Some things are more sensitive to bad jitter... largely because of how lag compensation is handled.

Something using TCP has certain flow control mechanisms built into the transfer protocol itself, which can reduce the amount of corrections needed to be done at the client or server end. It has it's own mechanisms for error correction/retransmits to try to make sure packets arrive in a timely fashion and in order.

UDP has no such countermeasures built in... it essentially just gets thrown on the wire. It either gets there or not. May or may not arrive in order. They may actually arrive too late and be effectively discarded by the server.

This can lead to a lot of problems with the lag compensatoon between the client and server because of strict limits on the amount of jitter it can handle. This can manifest in games in all kinds of janky ways… shots land around corners/through objects, something that animated on your local screen does not register as taking place by the server, game state can suddenly roll back a handful of frames, characters blink to different locations...

Some services opt for TCP for integrity at the cost of potentially slower transfers and response times. UDP is often chosen for potentially faster transfers/response times--can pack a bit more user data for the same packet size and offers more flexibility on the packet size, but it relies heavily on low and consistent latency to really shine.

This is pretty much why gamers obsess over their latency... because UDP is the bigger factor at play. Why they want to connect to servers closer to them... even if they start getting congestion lag spikes, they are more likely to stay within the limits for the game to remain more consistent. It is also why gaming VPN's became a thing--the services actively monitor/tweak routes to try to keep the latency factors in check.

Unfortunately the standards expected for such services are much more strict than some ISP's have. So it can often mean a lot of documentation to get things tweaked.