SQM CABLE DOCSIS 3.1 Settings + Packet Prioritization

I'm confused so what value should I put in the download

I typically recommend to run a few reliable speedtests and then plug these goodput numbers into SQM (where they will be interpreted as gross throughput numbers). But I really do not remember the details of your contract or link by heart so can only guess.

well my ISP told me where I live you can only have a 100Mbps link or well that said that was the limit but doing a speed test I got 127Mbps the highest and lowest 124Mbps on upload it is 32 Mbps.

Mmmh DOCSIS ISP have a tendency to promise less than they actually provision. So in your case O probably would set the download shaper to 100-110 Mbps (download shaping is approximate and a bit of head space to the real bottleneck is recommended), for egress I would try 30. And then confirm that these settings deliver acceptable bufferbloat under load :wink:

If it's bad they only promise 10%, that's what they told me

That really depends on the number of users in your segment and how many are active concurrently. Almost all access networks offer more aggregate enduser-capacity than the network can deliver (under worst case all are active at the same time assumptions), but the actual situation is rare.

However if this happens often in your network, have a look at https://forum.openwrt.org/t/cake-w-adaptive-bandwidth/108848 how to adaptively adjust the cake shaper settings.

It seems that I should reduce something more

Why, the test looks fine...

noticed there was an increase in load

another question how to know if my isp uses vlan? or is there any way?

In that test you posted a link to? What do you mean by "load" here?

Ask them? Other than that I have no robust and reliable method to offer. As I hinted at, measuring the throughput at different MSS can in theory help to deduce the per-packet-overhead, but requires really precise and repeatable measurements of the throughput; which makes this a rather theoretical Gedankenexperiment more than a useful empirical method.

to the upload link

But what happened to the upload? Too little thoughput/speed or too high bufferbloat?

the latency went up a bit but not so much as to despair maybe it's because I put overhead 22 I'll try with 18

Well, the way sqm's main work horses, fq_codel and cake, work is that by default they allow a standing queue of up to 5ms (or rather if the queuing duration of a flow exceeds 5ms for more than 100ms a drop/mark gets scheduled); the upshot of this is that during saturating loads the latency increases by at least 5ms...
When I compare the 95%iles of your tests between idle and down and upload I see only one value significantly exceeding 5ms, so from my perspective this is as good as it can be confirmed with on-line speedtests.
However you can always try to repeat the test with the shaper set to 50% of the current values, if the latency under load gets significantly smaller compared to your 100% tests, then we can continue the discussion :wink: