Ponponz - Disconnections

|------------------------------------------------------------------------------------------|
| WinMTR statistics |

Host - % Sent Recv Best Avrg Wrst Last
192.168.1.1 - 0 181 181 0 0 1 0
142.254.146.221 - 0 181 181 10 57 382 19
ae63.jfvlinbj02h.midwest.rr. com - 1 178 177 19 204 1080 112
be34.lsvmkyzo01r.midwest.rr. com - 0 181 181 13 63 383 15
be24.clmkohpe01r.midwest.rr .com - 0 181 181 20 72 389 27
bu-ether15.chctilwc00w-bcr00.tbone.rr. com - 0 181 181 31 82 394 32
66.109.5.136 - 0 181 181 30 80 396 43
66.109.5.225 - 0 181 181 29 78 396 37
66.109.9.149 - 1 178 177 29 82 392 110
ae1-br02-eqch2.as57976. net - 1 172 171 29 132 3816 36
be2-pe1-eqch2.as57976. net - 0 181 181 30 78 395 37
chi-eqch2-ia-bons-02.as57976. net - 0 181 181 32 79 394 41
24.105.62.129 - 0 181 181 30 73 392 34
________________________________________________ ______ ______ ______ ______ ______ ______

WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

Ponponz,

Not seeing anything obvious here and you’re with Spectrum/Charter rather than comcast. How often are you disconnecting, and have you tried anything to troubleshoot this yet? If not, the biggest things I’d recommend to you based on that data is:

  1. Power cycle your router/modem and reset your PC to clear any possible cache corruption
  2. Make sure your network drivers are up to date
  3. Reset your UI - especially if this started with the latest patch. Addon corruption is common with a new patch and usually I rebuild my addon library with fresh manual installations of my addons each major patch to prevent issues.

When I experience disconnects, only this HOP spikes and goes over 2k+ MS latency.

ae1-br02-eqch2.as57976. net - 1 172 171 29 132 3816 36

What do I do? I already contacted Spectrum and they checked all cable and modem/router, they said everything was fine on a physical level. I don’t have issues with any other services.

Ponponz,

That’s not relevant information because the rest of the test looks fine. That specific hop gets reported all the time but it just ignores a lot of test packets to prevent DDoS attacks at that node because it’s at a larger interchange in chicago. You’ll see a similar problem higher up in your test, but we can safely ignore that too because most of the test looks okay, and by the end of it you’re getting what we’d consider normal latency averages.

Did you try the troubleshooting above?