As we all know jitter is more prevalent when it comes to cable modems/internet. Is there anything I can to suppress ping spikes/jitter outside of my network (i.e. running ping plotter). Just curious. I have a R7800 and running the latest (stable) version of LEDE. Any suggestions are greatly appreciated. Thanks.
Not really. There are many factors that contribute to jitter on a docsis network, and they're usually tuned for high bandwidth and high rtt to allow for flunctuations. Most Cable ISP's don't even have control past a 25 mile radius because it's sub-leased.
1 Like
Please note that when using tools like pingplotter, traceroute, and mtr is seems wise to only look at the values returned from the endhosts, any intermediary "ping spikes" might simply e caused by de-prioretization and rate-limiting of direct responses on those hops. The same applies to packet loss, packet loss that consistently increases from a specific host on is diagnostic of problems, packet-loss unique to a specific intermediary host most likely can be ignored as insignificant (unless you need to talk to that host directly, but then it ceases to be an intermediary hop).
And yes the DOCSIS egress MAC is bursty, but the whether that matters really depends on your "jitter budget" (how much jitter you are willing to accept).
To add to moeller0 statement about egress, it is very bursty. Sending information to a host has an average wait time of between 2ms to 6ms depending on many factors such as time of day, network configuration, maintenance to hardware and software at the CMTS, etc in which cable segment congestion (the node your neighborhood is attached to) is the biggest determining factor. The short explanation is converting an rf signal to fiber to hybrid fiber coaxial with MANY conversions and steps along the way. This doesn't mean it will transmit in those slots, just wait for the next opportunity to do so. Pay attention to the end hosts as many hops in-between will try to reduce or compensate for the latency/jitter to the next jump. Having worked for a few cable companies and sorting through many technical documents regarding DOCSIS, it's no easy task keeping the "machine" producing. It's almost like squeezing 100 lemons to prepare an ounce of lemonade.
A simple way to think of sending packets upstream for cable network is like a traffic circle or round-a-bout. Packets have to yield to other traffic and then proceed when the opportunity allows. Your cpe modem sends as much information as it can within that small window, then waits, and sends more resulting in small bursts or larger ones depending on the conditions mentioned before. It's not a continuous flow of information by any means and will result in minor jitter opposite the control of a controlled lan environment or even a fiber link.
I had endless issues with sip based VoIP on cable, packet loss and jitter were both big issues. I guess this is why.
Packet loss should be addressed by your ISP. Jitter is considered low priority.
1 Like
In addition the process
One factor of this is the request/grant cycle in DOCSIS, since many CPEs share the same upstream channel their transmissions need to be coordinated in time, this works partly by requesting TX opportunities and waiting with the real data transmission until these requests have been granted (and obviously only using those time slots that the CMTS allotted). I note that other shared media like GPON have similar mechanisms.
One other reason for burstiness is that more recent DOCISIS standards behave a bit like WIFI in that they try to aggregate data (so they only incur the grant/request and overheads per aggregate instead of per packet), but the way to collect aggregates is to wait a bit, which also introduces more timing variability...
I addressed packet loss by switching to an ISP using a fiber optic network 
It's concerning your Cable ISP didn't want to address packet loss as a concern. Charter Cable at least cares to give full service to packet loss and bandwidth issues. Jitter and bufferbloat shall not be mentioned in their presence 
You didn't say, but have you looked at the SQM package for controlling delay? It might make a difference.
There's a "Howto" at https://lede-project.org/docs/user-guide/sqm
Yes, I had worked hard to set up a custom QoS system, it worked, but it seemed like it couldn't ever get things good enough. I suspect weather caused damage to cable connections on the pole and things got worse over time due to this signal degradation. In any case, things work great now with fiber and my custom QoS system based on FireQOS