But If i set egress limit to 10Mbit on both shapers, keep WAN ingress shaping at 0 and LAN ingress shaping to 30Mbit, I still get less than 10Mbit on speedtest at this point (Including overhead so effectively 9Mbit+)
So download seems to be affected by the ingress limit i'm setting :-/
Both should have EGRESS only, no LAN ingress.
Specifically egress on WAN set to your upload speed, and egress on lan set to your download speed.
what is your tc -s qdisc show dev br-lan output and tc -s qdisc show eth1.2 ?
if you disable lan ingress sqm will not work:
tc -s qdisc show dev br-lan
qdisc noqueue 0: root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc ingress ffff: parent ffff:fff1 ----------------
Sent 98917 bytes 188 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
and when ingress on it will work:
tc -s qdisc show dev br-lan
qdisc cake 801d: root refcnt 2 bandwidth 58120Kbit besteffort dual-dsthost nat nowash no-ack-filter split-gso rtt 100.0ms raw overhead 0 mpu 64
Sent 141763 bytes 165 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
memory used: 6733b of 4Mb
capacity estimate: 58120Kbit
min/max network layer size: 54 / 1514
min/max overhead-adjusted size: 64 / 1514
average network hdr offset: 7
Tin 0
thresh 58120Kbit
target 5.0ms
interval 100.0ms
pk_delay 504us
av_delay 41us
sp_delay 22us
backlog 0b
pkts 165
bytes 141763
way_inds 0
way_miss 7
way_cols 0
drops 0
marks 0
ack_drop 0
sp_flows 1
bk_flows 1
un_flows 0
max_len 4542
quantum 1514
qdisc ingress ffff: parent ffff:fff1 ----------------
Sent 19622 bytes 173 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
My understanding is that bridges don't queue, you need the egress shaper on the physical Ethernet interface of LAN, say eth0.1 or if using a veth pair, egress of the end not in the bridge, maybe veth0 if you put veth1 in the bridge.
Ingress is a hack where packets are mirrored to an IFB device, but this happens before iptables, so tagging on the router doesn't help with wan ingress.
if you want a shaper on br-lan you should enable shaping on both ingress and egress.
i'm using shaper on eth0 not br-lan, but i did that to show you that's it's not working on br-lan!
Shaping doesn't work on bridges in general only the individual ports in the bridge. This is why we used veth devices before, we shaped in the veth first then sent the packets to the bridge
true.
side-note: if you want to use lan-tripleisolate script you should enable shapers on both ingress and egress!
wow, with 50 as overhead,no more upload spike also download is stable now!
This would indicate an ISP with enough clue to configure its shapers, certainly not impossible, but a rare beast ;)... I am still dubious, I would recommend to keep measuring this over a few days at different times of the day (or rather around peak usage) and see whether this behavior is stable now.
should i use the same overhead on veth0 and pppoe-wan?
also what about eth0 overhead?
i also forget to say that isp MTU=1480
So,
Is the way forward?
Another question, "Squash DSCP on inbound packets (ingress)" should I touch this at all? Is this DSCP squashing before the QoS alters my packets with iptables? What about "Ignore DSCP on ingress:"
Right!
No, use PREROUTING.
set "Squash DSCP on inbound packets (ingress)" to don't squash.
Ignore DSCP on ingress set it to allow.
i will help you configure veth and sqm+dsscp tags.are you ready ?
Is this necessary though? I thought it was all functioning properly now?
The only issue i see now with wide range port 'guessing' udp range is other applications also go through this range sometimes.
no you should use veth to tag packets on ingress.
As in 'better?' or is my setup not actually shaping ingress now?
Actually you don't have tags on ingress now.you have it work on egress.
second it's better to divide traffic into 4 class like : (bulk/downloads--besteffort/web surfing--video/video steams/youtube--voice/games/voip).
and having a four dscp classes.
BTW: which ip's your game is using while in game?
Mhh. I see what you mean here, perhaps tag ingress packets based on an IP range AND udp? To close the gap so to speak. I'm not sure, Id have to check how much the IP's change if at all.
I'll see if i can get this Veth stuff working myself first. Seems there are some people that set it up so ill work from there.
Well, I just stumbled over d3974b1e9f05a08825064c863f752e3fdbe51fbe6d6388006fbbc6c72ced6033 it looks like EPON is not simply ethernet, but can be actually worse. But again I would be really amazed if any ISP would bother to keep an eye to detail down to this level...
The way tagging works in this set-up is that we don't use "ingress" at all, we use egress on WAN (which is Upload) and egress on LAN (which is "download" to your LAN).
You don't need to squash DSCP on ingress, because there is no ingress queueing and you're going to use custom dscp tagging in firewall/iptables. It can be useful to have a default tag of CS0 (or maybe CS2) for everything you don't either up-prioritize or down-prioritize explicitly.