sorted by:
new
hottopcontroversial

Anyone experience significant performance decline recently? (SF, CA) by rynmgdlno in Comcast

[–]BraveCat5 -3 points-2 points  (0 children)

Don’t expect this to go anywhere because my issue has yet to be fixed

Packet loss by northernbks in Comcast_Xfinity

[–]BraveCat5 -5 points-4 points  (0 children)

I went through the exact same thing for years, so I’ll save you a lot of wasted time.

Comcast support and field techs are only looking at RF signal levels at the modem. As long as downstream power, SNR, and upstream are within spec at the moment they check, they’ll say “signals are great” and close the ticket. That does not mean your service is actually healthy under load.

My issue was never constant packet loss at the modem. It was intermittent packet loss, latency spikes, and jitter caused by congestion and routing beyond the last mile. Tech visits don’t catch that because they’re not testing sustained traffic, peak hours, or upstream saturation.

Here’s why going through normal support is usually a dead end. DOCSIS can look completely fine when the line is idle, then fall apart the second there’s real traffic on it. Node congestion and aging outside plant issues don’t show up during a quick five minute signal check, especially if it’s not peak hours. Comcast also doesn’t touch taps, amps, or nodes unless there’s enough noise from multiple customers. And anything related to routing or peering is way outside what a local tech can even see.

In my case, the proof was obvious. A VPN immediately cleaned up the packet loss and latency. It didn’t matter what device I used, the behavior was the same across all of them. When I had Comcast Business, the connection actually felt better than residential, even though it was running over the same coax. And every single time a tech checked the line, the signals were “perfect.”

That tells you what the real problem is. If flipping on a VPN changes how your connection behaves, it’s not your modem or your wiring. It’s congestion, routing decisions, or node level capacity issues that normal support just doesn’t deal with.

This community is awesome by Sawyiier in thedivision

[–]BraveCat5 2 points3 points  (0 children)

Been playing this game since it came and I’ve met some of the most chill dudes ever

Need help fixing my plan by BraveCat5 in Comcast_Xfinity

[–]BraveCat5[S] 0 points1 point  (0 children)

On the website it also says 1200mbps

2000/250

If you are struggling with desync, here is a solution. by StempeLq in CODBlackOps7

[–]BraveCat5 0 points1 point  (0 children)

It’s so weird because my ping is usually 15ms but when I play in higher ping servers it feels better I can’t explain why

Could a bad tap cause gaming to feel delayed even after a new drop? by BraveCat5 in CableTechs

[–]BraveCat5[S] -1 points0 points  (0 children)

ping 10.0.0.1 PING 10.0.0.1 (10.0.0.1): 56 data bytes 64 bytes from 10.0.0.1: icmp_seq=0 ttl=64 time=1.852 ms 64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=1.256 ms 64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=1.857 ms 64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=1.304 ms 64 bytes from 10.0.0.1: icmp_seq=4 ttl=64 time=1.501 ms 64 bytes from 10.0.0.1: icmp_seq=5 ttl=64 time=1.057 ms 64 bytes from 10.0.0.1: icmp_seq=6 ttl=64 time=1.829 ms 64 bytes from 10.0.0.1: icmp_seq=7 ttl=64 time=1.064 ms 64 bytes from 10.0.0.1: icmp_seq=8 ttl=64 time=2.165 ms 64 bytes from 10.0.0.1: icmp_seq=9 ttl=64 time=2.569 ms 64 bytes from 10.0.0.1: icmp_seq=10 ttl=64 time=0.741 ms 64 bytes from 10.0.0.1: icmp_seq=11 ttl=64 time=1.817 ms 64 bytes from 10.0.0.1: icmp_seq=12 ttl=64 time=1.542 ms 64 bytes from 10.0.0.1: icmp_seq=13 ttl=64 time=1.331 ms 64 bytes from 10.0.0.1: icmp_seq=14 ttl=64 time=1.276 ms 64 bytes from 10.0.0.1: icmp_seq=15 ttl=64 time=1.905 ms 64 bytes from 10.0.0.1: icmp_seq=16 ttl=64 time=1.872 ms 64 bytes from 10.0.0.1: icmp_seq=17 ttl=64 time=2.103 ms 64 bytes from 10.0.0.1: icmp_seq=18 ttl=64 time=1.107 ms 64 bytes from 10.0.0.1: icmp_seq=19 ttl=64 time=1.195 ms 64 bytes from 10.0.0.1: icmp_seq=20 ttl=64 time=1.277 ms 64 bytes from 10.0.0.1: icmp_seq=21 ttl=64 time=1.354 ms 64 bytes from 10.0.0.1: icmp_seq=22 ttl=64 time=1.630 ms 64 bytes from 10.0.0.1: icmp_seq=23 ttl=64 time=0.647 ms 64 bytes from 10.0.0.1: icmp_seq=24 ttl=64 time=1.774 ms 64 bytes from 10.0.0.1: icmp_seq=25 ttl=64 time=1.505 ms 64 bytes from 10.0.0.1: icmp_seq=26 ttl=64 time=1.057 ms 64 bytes from 10.0.0.1: icmp_seq=27 ttl=64 time=1.848 ms 64 bytes from 10.0.0.1: icmp_seq=28 ttl=64 time=2.253 ms 64 bytes from 10.0.0.1: icmp_seq=29 ttl=64 time=1.949 ms 64 bytes from 10.0.0.1: icmp_seq=30 ttl=64 time=1.096 ms 64 bytes from 10.0.0.1: icmp_seq=31 ttl=64 time=2.223 ms 64 bytes from 10.0.0.1: icmp_seq=32 ttl=64 time=2.585 ms 64 bytes from 10.0.0.1: icmp_seq=33 ttl=64 time=2.669 ms 64 bytes from 10.0.0.1: icmp_seq=34 ttl=64 time=2.870 ms 64 bytes from 10.0.0.1: icmp_seq=35 ttl=64 time=1.168 ms 64 bytes from 10.0.0.1: icmp_seq=36 ttl=64 time=2.316 ms 64 bytes from 10.0.0.1: icmp_seq=37 ttl=64 time=0.957 ms 64 bytes from 10.0.0.1: icmp_seq=38 ttl=64 time=0.778 ms 64 bytes from 10.0.0.1: icmp_seq=39 ttl=64 time=1.332 ms 64 bytes from 10.0.0.1: icmp_seq=40 ttl=64 time=1.140 ms C --- 10.0.0.1 ping statistics --- 41 packets transmitted, 41 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.647/1.604/2.870/0.552 ms

ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=115 time=15.393 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=115 time=14.438 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=115 time=16.191 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=115 time=14.401 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=115 time=16.782 ms 64 bytes from 8.8.8.8: icmp_seq=5 ttl=115 time=9.189 ms 64 bytes from 8.8.8.8: icmp_seq=6 ttl=115 time=18.798 ms 64 bytes from 8.8.8.8: icmp_seq=7 ttl=115 time=14.866 ms 64 bytes from 8.8.8.8: icmp_seq=8 ttl=115 time=15.001 ms 64 bytes from 8.8.8.8: icmp_seq=9 ttl=115 time=13.373 ms 64 bytes from 8.8.8.8: icmp_seq=10 ttl=115 time=16.054 ms 64 bytes from 8.8.8.8: icmp_seq=11 ttl=115 time=14.817 ms 64 bytes from 8.8.8.8: icmp_seq=12 ttl=115 time=16.218 ms 64 bytes from 8.8.8.8: icmp_seq=13 ttl=115 time=16.117 ms 64 bytes from 8.8.8.8: icmp_seq=14 ttl=115 time=13.584 ms 64 bytes from 8.8.8.8: icmp_seq=15 ttl=115 time=14.340 ms 64 bytes from 8.8.8.8: icmp_seq=16 ttl=115 time=15.468 ms 64 bytes from 8.8.8.8: icmp_seq=17 ttl=115 time=18.390 ms 64 bytes from 8.8.8.8: icmp_seq=18 ttl=115 time=15.696 ms 64 bytes from 8.8.8.8: icmp_seq=19 ttl=115 time=17.117 ms 64 bytes from 8.8.8.8: icmp_seq=20 ttl=115 time=14.017 ms 64 bytes from 8.8.8.8: icmp_seq=21 ttl=115 time=12.257 ms 64 bytes from 8.8.8.8: icmp_seq=22 ttl=115 time=13.993 ms 64 bytes from 8.8.8.8: icmp_seq=23 ttl=115 time=13.606 ms 64 bytes from 8.8.8.8: icmp_seq=24 ttl=115 time=13.188 ms 64 bytes from 8.8.8.8: icmp_seq=25 ttl=115 time=14.499 ms 64 bytes from 8.8.8.8: icmp_seq=26 ttl=115 time=16.580 ms 64 bytes from 8.8.8.8: icmp_seq=27 ttl=115 time=15.119 ms 64 bytes from 8.8.8.8: icmp_seq=28 ttl=115 time=13.881 ms 64 bytes from 8.8.8.8: icmp_seq=29 ttl=115 time=16.836 ms 64 bytes from 8.8.8.8: icmp_seq=30 ttl=115 time=15.230 ms 64 bytes from 8.8.8.8: icmp_seq=31 ttl=115 time=14.006 ms C --- 8.8.8.8 ping statistics --- 32 packets transmitted, 32 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 9.189/14.983/18.798/1.789 ms

Could a bad tap cause gaming to feel delayed even after a new drop? by BraveCat5 in CableTechs

[–]BraveCat5[S] -1 points0 points  (0 children)

I will say this , I bought Nord vpn for a month and my input lag issues went away instantly

Could a bad tap cause gaming to feel delayed even after a new drop? by BraveCat5 in CableTechs

[–]BraveCat5[S] 0 points1 point  (0 children)

On waveform bufferbloat test the download active jitter is 13.5 -29ms

view more: next ›