SQM setting question - Link Layer Adaptation

Hi mindwolf,

July 24
My theoretical calculation. Please chime in with opinions and your experiences using this calculation.
Docsis 3.0 uses up to 42,880 Mbps per channel for a total of 686,880 Mbps (608,000 goodput) Ds and 122,880 (108,000 goodput) Us.

This might or might not be true (no time to look it up), but I assume that this is not going to be the relevant limit for you, as DOCSIS systems employ a traffic shaper that keeps the user traffic within the contracted rates. (Now if you have a DOCSIS segment all to yourselves that might be different, but in that case I am certain you need to already know more about DOCSIS than I ever will, so in that case just ignore me).

10% of the max achievable Ds and 5% of the max achievable Us. MTU 1500 minus 20 bytes for TCP overhead, 20 bytes of IPV4 overhead. 44 bytes total is = 6 bytes of overhead for Docsis 3.0, 14 bytes layer 1 overhead, 14 bytes layer 2 overhead,

This is a bit opaque for me, but the DOCSIS shaper is known to talke a full ethernet frame including the frame check sequence into account, so that will be 1518 Bytes at most. Now what layer that actually lives in is somewhat tricky for me to doiscern, as DOCSIS will drag in its own additional overheads (like the MPEG headers) but will leave out typical ethernet overhead like preamble and the inter packet gap... But for end users as far as I can see the ISPs shaper setting and the assumption that there will be 18 Bytes of overhead on top of the IP packet should hold true.

So...
686,880-10%=68,880

Not sure that I agree with that:
686880 * 0.9 = 618192 (686880 minus 10% of 686880)
686880 * 0.1 = 68688 (10% of 686880)

68,688/1,46044=2,070
68688-2070= 66618
122,880-5%=6144
6144/1460
44=185
6144-185=5959
Package listed as 60 Ds; 4 Us
The Above answers of 66618 & 5959 match very closely within 1% of my max achievable speeds without congestion on the wire without SQM enabled.

But more relevant, I would start from the measured goodput (in Kbps?) and calculate backwards from that (assuming TCP/IPv4):
66618 * ((1500 + 14 + 4) / (1500 - 20 -20)) = 69264.4684932 Kbps
5959 * ((1500 + 14 + 4) / (1500 - 20 -20)) = 6195.72739726 Kbps
So as typical for cable ISPs you seem to have more bandwidth allotted than you could expect from your plan. But if your ISP uses power-boost that bandwidth might not actually be sustained but might throttle back after the 10 seconds a speedtest typically runs*. Also due to the interaction of the DOCSIS shaper assumption of 18 bytes per-packet overhead in combination with the true DOCSIS per-packet overheads that extra bandwidth might just be a stopgap measure to make sure you get your contracted bandwidth even when you use smaller packets, but I have no data to back this up...

I offer all of this as simple opinion, as I have not fully understood what your exact argument is (as I am not a native english speaker, please forgive my denseness).

Best Regards

*) This is why I recommend to use a speedtest that can run for more than 10 seconds, see [SQM/QOS] Recommended settings for the dslreports speedtest (bufferbloat testing)