Never had trouble with the cables but just for completeness:
Ethernet cables used are labeled CAT7 but are most likely just CAT6 with the highest grade of shielding since there's still (shielded) RJ45 plugs on them (and iirc real CAT7 cables don't have RJ45). The COAX cable is also one with a higher grade of shielding.
well yes and no.The shaper used in DOCSIS systems that limits a users maximal bandwidth does completely ignore DOCSIS overhead and only includes ethernet frames including their frame check sequence (FCS 4 Byte). (The linux kernel accounts for ethernet framing without the FCS).
"C.188.8.131.52 Maximum Sustained Traffic Rate 632 This parameter is the rate parameter R of a token-bucket-based rate limit for packets. R is expressed in bits per second, and MUST take into account all MAC frame data PDU of the Service Flow from the byte following the MAC header HCS to the end of the CRC, including every PDU in the case of a Concatenated MAC Frame. This parameter is applied after Payload Header Suppression; it does not include the bytes suppressed for PHS. The number of bytes forwarded (in bytes) is limited during any time interval T by Max(T), as described in the expression: Max(T) = T * (R / 8) + B, (1) where the parameter B (in bytes) is the Maximum Traffic Burst Configuration Setting (refer to Annex C.184.108.40.206). NOTE: This parameter does not limit the instantaneous rate of the Service Flow. The specific algorithm for enforcing this parameter is not mandated here. Any implementation which satisfies the above equation is conformant. In particular, the granularity of enforcement and the minimum implemented value of this parameter are vendor specific. The CMTS SHOULD support a granularity of at most 100 kbps. The CM SHOULD support a granularity of at most 100 kbps. NOTE: If this parameter is omitted or set to zero, then there is no explicitly-enforced traffic rate maximum. This field specifies only a bound, not a guarantee that this rate is available."
So in essence DOCSIS users need to (only) account for 18 Bytes of ethernet overhead in both ingress and egress directions under non-congested conditions. But since on an ethN interface the linux kernel already accounts for 14 of those for fq_codel+HTB specify the overhead as 4. For recent cake you can and should specify the overhead as 18 as cake can undo the kernels automatic overhead addition.
thanks for the data, I will take a few days before I find time to look over it closely as I did not find any smoking gun on my first reading (and I might not find one on fine reading either). The error messages you got in the log are an already known issue with the hfsc kernel module used by some of the qos scripts (hfsc_lite.qos, hfsc_litest.qos, and nxt_routed_hfsc.qos) if you tried those that might have triggered the message (but we also load the hfsc module during sqm start-up to have it available for the listed hfsc using scripts, auto-loading of modules is not reliable on all "supported" distributions)
Okay, I have looked closer into your files and I am sorry to say, I made you do all these tests for no gain, I have no real idea why you seem to be better of with only upstream shaping. I also am out of realistic ideas what to test next...
@danghuy1994 Both tests with SQM off and on have a "D" grade for connection quality in your dslreports speedtests. According to the FAQ on dslreports, that means you have a packet loss between 5% and 12%. Realtime data such as VOIP and videocalls are extremely sensitive to packet loss and no amount of shaping will fix that problem. As a matter of fact, non-realtime data also suffers from packet loss by decreasing throughput.
There is something very wrong with your setup or ISP that is causing these issues, as that is an extremely high figure for packet loss. I would focus on getting the packet loss under control before looking into any shaping with SQM.
I'm not sure in regards to the cable connection, but now we know what your download/upload is, can you test with the following settings just to see if that makes a difference in regards to bufferbloat (I'm sure the values can be set higher)
option download '15000'
option upload '3000'
Direct connection to the Cisco EPC3212 seems to be good, Bufferbloat and Quality ratings are both A+!
I have a quick question regarding SQM... I currently have a mesh network with 2 AP's and a gateway ( router)... I know SQM will be worth deploying on the Gateway / Router device; but will I gain anything deploying it on each note to regulate the mesh traffic???
mmmh, sqm-scripts is not ideal for wifi links, as it really really needs to have fixed bandwidth (or at least slowly changing bandwidth) to function; most WLAN links are just to variable to allow for static shapers like sqm-scripts' to work well. If you have ath9k (or less so ath10K) radios the airtime fairness patches (which I believe to be part of lede) might actually help more. Now if your radio links are super stable you might have luck with sqm-scripts, but even then the half-duplex nature of current generation WLAN will pose a problem...