[Solved] ASUS RT-AC68U DSL settings

You actually can't put queues on bridges, the queuing happens on the individual interfaces, so basically on the wired LAN interface, like eth0.1 or whatever. The more sophisticated way is to use a veth pair and inject into the bridge via the veth, but I don't think this is absolutely necessary.

That sounds wrong for egress, properly configured cake should work close to 99% of link rate on VDSL2 (100*64/65 = 98.46%, as you have a ~1.5% "loss" for PTM's 64/65 encoding).
So how about we try to fine-tune your sqm configuration first?

This is not going to work, currently sqm will only allow one active instance per interface...

So how about on egress you simply mark the packets at their source correctly? See:
https://forum.openwrt.org/t/microlags-with-sqm/33404/31?u=moeller0
for an example how to change the marking under windows 10 on a per application basis...

I was stumped and almost started pulling hair out

this is a little complex but now that I know what to sqm I can add the ruleset after its optimized

changed to

sqm layer cake wan egress(pppoe-wan)
sqm piece of cake eth0.1(eth0.1)

I don't require piece of cake to distribute resources across hosts but I do require layer cake packet ordering across hosts especially wan egress

speed speed2

This is with all sqm disabled. I pay for 25 down 3 up. My dsl line stats report data rate as 28 down 3.5 up, I know that fluctuates with congestion but it's so rural here there are no torrent users or enough users to congest or cause noise issues on the line


gpedit1 gpedit2 gpedit3

I will execute the commands in powershell for the exe files and remove these rulesets

image

image

In addition to ipv4/wireshark being the only enabled option for my lan controller I also have basically all of the lan options disabled except interrupt moderation which is set at minimal -- I will reinstall the driver to revert them all to default settings

That will work...

According to your sync rates I estimate the following maximum theoretical TCP/IPv4-goodput:

28029 * 64/65 * ((1500-8-20-20)/(1522)) = 26328.504114
3502 * 64/65 * ((1500-8-20-20)/(1522)) = 3289.53660164

Which seems to be roughly in line with the speedtests results.
I would set internet download speed for sqm to: 28029 * 64/65 * 0.95 = 26217 Kbps
and internet upload speed for sqm to: 3502 * 64/65 = 3440 Kbps
and then I would test whether that results in desirable low bufferbloat during saturation tests. If not then gently reduce the shaper rates a tad and repeat the test.

Typically these values are independent of congestion, they might be noise limited and with SRA (seamless rate adaptation) they might change on an active link, in that case set the shaper referece rates above (that I took from your modem output) and replace them by the long term minimal sync rates you see...

But this is what helps isolate your game traffic from another computer's video streaming, unless this never is an issue for you you can ignore the dual-xxxhost keywords.

About group policies, I believe that without a domain controller windoes really does not want to support you in using this for per application QoS, while the linked powershell based method seems to work independent of a domain controller. (If you operate your own domain controller, ignore me :wink: )

That said, if your group policies do work and you see appropriately marked packets leaving your windows host there is no need to switch to the powershell method, just keep in mind that windows updates might disable the policies (or they might not the ways od Redmond are mysterious).

Disabling flow control seems a belt and suspenders kind of thing, as I can almost guarantee that no device in your network will use ethernet pause frames by default (famous last words...)

I guess that is a good thing going back to the defaults, then you can enable/disable/configure each option independently and only use those that actually have a perceivable influence on the network performance....

Good luck.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.