General Discussion of SQM

I believe the issue is that we only get packets after the ingress node of the diagram, so if a packet matches to the flow table I believe sqm will not see it at all, at least for ingress.

Ah, right! because ingress is handled with an IFB in the standard setup. I'm using egress of my LAN instead :wink: if you have a qdisc on the egress of LAN does it see the packet from neigh_xmit? I haven't got a clue.

1 Like

Mmmh, just did a quick and dirty test on my wndr3700, wirt or without software flow offloading checked my sqm ingress settings are honored (I shape my 99 Mbps downstream link to 49 Mbps, since my current main router can only shape reliably to around 70-80 Mbps up+down, doing a wget -O /dev/null http://speedtest.belwue.net/10G --report-speed=bits -4 manual single flow spedtest shows a limit ~42Mbps independent of the offload status, but in any case doing this over the 5GHz radio has my router's CPU at 1% idle, enabling flow offloads with sqm disabled results in both times ~91Mbps goodput, but with 20% idel with softoffloads and 0-5% without).

So I cautiously retract my theory, software flow offloading might be compatible with ingress sqm (but the sqm is so expensive that it does not really give that much of an advantage).

I have (unscientifically) observed the lower download throughput with SQM ( download == 0 and upload == 275000) and offload enabled, but my router is also close to its limits in this test.
So I have for now disabled the offload.

Blockquote[quote="fantom-x, post:94, topic:30527"]
I have (unscientifically) observed the lower download throughput with SQM ( download == 0 and upload == 275000 ) and offload enabled, but my router is also close to its limits in this test.
So I have for now disabled the offload.
[/quote]

My r7800 runs out of juice for piece of cake / layer cake at that speed as well (~mid 200mbps wired). FQ_codel + simplest_tbf give me the best balance of throughput and latency (up to 500mbps wired). What qdisc / script are you running (cat /etc/config/sqm)?

I know some of you have probably seen it already, but for those of you running out of juice for SQM... if you haven't already seen them here are my recent results using RPi 4 for routing and shaping a full gigabit easily.

This one, but LAN/WAN use case does not interest me. 5GHz wifi tops out at around 260Mbps.

I saw that, but I am desperately trying to not multiply the number of devices to manage. Although, it does not look like I am gonna succeed here.

Yeah, I hear you. I eventually installed cfengine and have been trying to automate the heck out of everything... It has helped a lot with desktops and laptops and servers. There's no openwrt package for routers and access points though.

Well, for the several routers I manage I went the /etc/uci-defaults/ route. I package all configuration scripts and packages, disable preserve config in LuCI, and just send a firmware over to the router owner. They just upgrade, the configuration scripts do all the setup, and it is all good. If they mess up the config, I ask them to reset to defaults, and the router is as good as new in a few minutes.

Has ctinfo been backported to work for 4.4.167?

Is it normal that the SQM overhead size does not make any difference on my connection? Even more, I do not seems to any buffer bloat without SQM either...

As so often, the answer is, it depends... If you do not run out of CPU cycles, increasing the overhead should decrease the achievable speedtest-goodput. Once the configured shaper per-packet-overhead (SPPO) is larger than the real per-paket-overhead (RPPO) all it will do is decrease the achievable goodput. If the overhead is set too low increasing it can either decrease latency-under-load or just decrease goodput, depending on packetsize and the relation of true bottleneck gross rate and shaper gross rate.

So, assuming shaper gross rate (SGR) = bottleneck gross rate (BGR),
increasing SPPO will reduce bufferbloat/latency under load until SPPO = RPPO, any further increase will just reduce goodput.

If SGR < BGR, for any given packet size there will be situations where SPPO < RPPO will not result in bufferbloat, if SGR is sufficiently smaller than BGR. In a situation like this using smaller packet will typically make bufferbloat raise its ugly head again.

Bufferbloat is only truly squelched if SGR <= BGR AND SPPO >= RPPO, other combinations tend to be either sensitive to packet size distributions of your traffic, or sacrifice massive amounts of bandwidth.

Is that in any way understandable and helpful?

It is possible, albeit unlikely, that the ISP manages buffers in up- and downstream well enough to make bufferbloat on the WAN link a non-issue. Try to saturate your link with small packets and multiple flows and see how you ISP's hardware deals with that :wink:

2 Likes

Is there a tool to do that?

I would happily pay a subscription to a public flent server...

Think of overhead as a correction factor that is associated with packet size. if you have packet sizes almost always large, it makes no difference but with small packets it makes a potentially big difference. Games and VoIP will usually use small size packets. So if that kind of traffic is a big fraction of your link it will be an important thing to get overhead right.

When in doubt, just look up the best guess for overhead on your link type from the wiki, and add 10 bytes. done. spend more time tuning the speed and qdisc options.

1 Like

How much? I can set one up and charge people's credit card.

I was testing with fast.com, because dslreports does not want to scale to 300M/300M...

if you have 300/300 overhead is unlikely to be a big deal. Unless you are running a call center with thousands of simultaneous calls or you have a LAN party going for an entire high school or something :grinning:

you should do the guess and add 10 rule from above.

I disabled SQM entirely and see no buffer bloat...

Well I guess pricing depends on the monthly data allowance, x number of speedtests allowed within a given time, rate of the speed test for starters.