I've been trying to get support to forward the info to the NOC but they don't seem to care.
I have the same problem you are describing and I believe it's being caused by a hop on my route.. this router keeps spiking and no one seems to care.
Seems like the only thing they'll investigate are total outages.
Levels are ok, even speedtest are acceptable.. the problem is taht long will spike constantly and that kills internet gaming.
I'm so sure it's spectrum routes that if I set my router to send all my PS4 traffic via VPN (skipping the problematic hop on spectrums route) the jitter goes away but the VPN connection is way slower than what I'm supposed to be getting from spectrum.
Yeah... been there before. BUT... that is a GREAT way to demonstrate the issue. It in fact was a key part of our campaign to clean up routing specifically to Ormuco's ASN in Montreal when FFXIV first went live on servers up there (they later moved things to Germany fornthe EU and the west coast for NA). VPN's afforded a means to demonstrate the disparity in different routing corridors being offered by various peering partners.
It took some time and a LOT of effort through Tier3... but we eventually cleaned up a LOT of routing along at least the eastern seaboard. To this day, I can still get better than 60ms latency from here in SC all the way to some ASN's in Montreal...better than some routes into cities less than half that distance to the west of me. When we first started, latency was NEVER below 120ms, and more often exceeded 200ms with peaks approaching 1 full second and timing out intermittently.
The trick is in getting good data demonstrating the symptoms into the proper channels so it can <hopefully> get escalated to a team that may actually be able to do something about it.
|1||Locked||QAM256||17||561000000 Hz||-4.5 dBmV||39.8 dB||25||7|
|2||Locked||QAM256||2||471000000 Hz||-2.9 dBmV||40.8 dB||0||0|
|3||Locked||QAM256||3||477000000 Hz||-2.9 dBmV||40.8 dB||0||0|
|4||Locked||QAM256||4||483000000 Hz||-3.1 dBmV||40.7 dB||0||0|
|5||Locked||QAM256||5||489000000 Hz||-3.2 dBmV||40.6 dB||0||0|
|6||Locked||QAM256||6||495000000 Hz||-3.4 dBmV||40.3 dB||0||0|
|7||Locked||QAM256||7||501000000 Hz||-3.4 dBmV||40.2 dB||0||0|
|8||Locked||QAM256||8||507000000 Hz||-3.5 dBmV||36.7 dB||0||0|
|9||Locked||QAM256||9||513000000 Hz||-3.7 dBmV||40.2 dB||0||0|
|10||Locked||QAM256||10||519000000 Hz||-3.8 dBmV||40.2 dB||0||0|
|11||Locked||QAM256||11||525000000 Hz||-3.8 dBmV||40.2 dB||0||0|
|12||Locked||QAM256||12||531000000 Hz||-4.1 dBmV||40.1 dB||0||0|
|13||Locked||QAM256||13||537000000 Hz||-4.3 dBmV||40.0 dB||0||0|
|14||Locked||QAM256||14||543000000 Hz||-4.5 dBmV||39.8 dB||21||0|
|15||Locked||QAM256||15||549000000 Hz||-4.4 dBmV||39.9 dB||15||0|
|16||Locked||QAM256||16||555000000 Hz||-4.3 dBmV||39.9 dB||9||0|
|17||Locked||QAM256||1||465000000 Hz||-3.0 dBmV||41.9 dB||0||0|
|18||Locked||QAM256||18||567000000 Hz||-4.9 dBmV||39.9 dB||0||0|
|19||Locked||QAM256||19||573000000 Hz||-4.8 dBmV||40.3 dB||0||0|
|20||Locked||QAM256||20||579000000 Hz||-5.1 dBmV||39.9 dB||0||0|
|21||Locked||QAM256||21||585000000 Hz||-5.1 dBmV||39.9 dB||0||0|
|22||Locked||QAM256||22||591000000 Hz||-4.9 dBmV||40.3 dB||0||0|
|23||Locked||QAM256||23||597000000 Hz||-4.8 dBmV||40.3 dB||0||0|
|24||Locked||QAM256||24||603000000 Hz||-4.4 dBmV||40.4 dB||0||0|
|Upstream Bonded Channels|
All I wish is for a higher tier or someone from the NOC to take a look at that router. Chat/Phone support is useless as the only thing they'll do is reset the modem and send another technician ad nauseum. If I report the problem 10 times, 10 times theyll handle it the same way. This is really furstrating, I know they won't care a bit but I'm close to cancelling since I feel too much time will be spent trying to get them to even listen.
should also note there is elevated packet loss occurring at level3 exchanges in the Houston/Dallas area again... around 3x as much as the congested Spectrum/RR node close to the CPE showed up in that particular report.
We've seen this peering arrangement flounder like this in the past. Still see it occasionally with Level3 in Atlanta as well for the southeast corridors. As far as this upstream segment, it may be more of the same things we've seen in the past where traffic may need to get spread out a bit more to the likes of TATA, Cogent, or maybe even XO.net or Zayo?. Just a few thoughts...
Thanks for taking your time and your input. I used to have problems like this on my previous ISP but at least they where a lot more reachable and genuinely tried to get to the bottom of the problem. Very frustrating trying to deal with an ISP that won't listen.
Encouraging to see the level3 hops weren't there in that tracert... TATA showed up that time (as6453 hop). While still not "ideal", jitter pushing up to 60ms is a helluva lot better than 50% packet loss.
Hopefully it as an indication some new BGP announcements are passing around... upstream routing may see some slight improvements on it's own over the next 72 hours. Those local nodes though... that is gonna be a tricky issue because of internal routing policies.
If you don't see improvements by Friday evening, might want to try a modem reset to see if perhaps pulling a new config down gets you on a different gateway or something. Sometimes things get revamped from the head end, but the modem will not grab those changes in real time... will only grab them when it goes through the reboot process and requests new config files and such. Either a full power cycle (not just a reboot, full power down for a bit) or resetting the modem to defaults should prod the updates if any get scripted.
Keep in mind though if a tech visit is scheduled, you will want at least 6 hours of uptime before they show up so they have some log entries if some of the automated ranging requests and such are erroring out.