How debug QoS on DIR-825/B1?

I mean what not will be limit if I buy TP-LINK TL-SG105E on hardware DIR-825/B1 without shaper filters ? Or DIR-825/B1 even if use latest OpenWRT firmwares have limit bandwidth ? DIR-825/B1 can to provide from WAN to LAN ports 1 Gbps with full speed?

i don't remember the tests, but DIR-825b1 without shaping on clear Ethernet should be capable of 500 Mbps with offloading. There were tests somewhere. You can do a test yourself easily uisng iperf.

Would you mind telling us how Ingress policing in Openwrt can be done for those who aren't hindered by a language barrier? Would love to play around with this. And would this be compatible with flow offloading?

Well, please keep in mind that policing (basically hard dropping of all packets coming in above the set rate) is rather harsh and that even most ISP switched from simple and cheap policing to traffic shaping to control the access rates for typical end customer lines as shaping simply performs better (by allowing some queueing which gives the traffic shaper some burst tolerance while a policer will likely "decimate" packets coming in a burst which neither TCP nor streaming over UDP will be very tolerant for).
Dave Taht was designing a less harsh policer at a time, but I believe that project is in deep hibernation.

Too bad :frowning:

If I want to try anyway, how would I do this? :slight_smile:

Are there any cheap really simple shaping algorithms, that are way less CPU hungry than for example SQM is?

As far as I can tell, no, the issue, as I see it, is that low-latency traffic shaping needs timely access to the CPU, so is mostly CPU-latency bound (not necessarily throughput limited). All of the shapers available in Linux so far HTB, cake, HFSC all seem to top out at similar rates (on the same hardware), so unless someone has a brilliant idea how to solve this I would guess most shapers will stay computationally expensive. Now, if an access modem would have something like BQL on the bottleneck link at least for egress we might be able to not require a traffic shaper (one would still want to run an fq system like fq_codel or cake's but one would not need the costly shaper component anymore). Realistically, barring any miracles, the best bet is probably to switch the main router to sufficiently capable hardware and just accept the high cost of traffic shaping... (a step I for one have not yet made, instead I shape my 100/40 Mbps link down to the 49/36 that my puny router manages to reliably shape with sqm, but most users are less Mbps-indifferent than I am :wink: ).

@moeller0, you should try that RPI4 I'm advocating these days for your router :wink: it would definitely handle 100/40 connection.

Also, it would be great if we could get managed switches with hardware shaping built in. If a decent simple shaping scheme came built into $25 managed switches, we could offload all of that to customized hardware. I think as WAN connections start to move upwards of 100Mbps even just a token bucket filter + BLUE + WRR might be enough to control most bufferbloat and could be implemented in hardware rather easily.

Even better would be someone could train a selection of Neural networks on different test data... One set of neurons for gamers, one set for office workers, one set for non-gamer households, etc... Then in your managed switch you just select "i'm a gamer" or "we're a normal household" or "we run a small business" or whatever, and it'd DSCP mark and drop packets based on fancy statistics, in hardware.

If you want to play with custom QoS / policing etc I suggest a multi-pronged approach... tc is a really unpleasant way to handle packets... but nftables is fabulous. So the first thing I'd do is figure out how to build an nftables firewall, and then add to that firewall a table hooked into ingress. It's then very easy to specify an nftables match to match packets over a certain rate and drop them.

You can also match packets and DSCP tag them on ingress, so that they will go through the IFB of SQM with the tags on them...

Since it's not entirely on-topic here. I'll maybe create a new thread for nftables based QoS experiments... I've got some stuff to share, and maybe we can get a wiki page going as well.

Please do! This all sounds mighty interesting to me :slight_smile:

Ok, new topic is here: QoS and nftables ... some findings to share

1 Like

That would be much appreciated! :slight_smile:

Thank you ) I buyed TL-SG105E work exelent ) speed CBR 159,5 DL and 145 UL )

1 Like