I just tested it for 5 mins, but to also mark the outgoind packets with cs5 works like a charm!
SQM works also very good with netflixing girlfriends in the lan but I havent tried it with a wifi device. will do so soon. Could I just put another SQM on wifi? Or is that too much?
Thank you so much, it has really helped a lot!
Well you could but it won't necessarily work so well, the issue is that you need to keep the total download below your 22Mbps or whatever it is. To do that you can do the following:
You can create the veth pair as follows in your firewall.user script (untested)
ip link add type veth
ip link set up veth0
ip link set up veth1
ip link set veth1 master br-lan
then you'll need to add a static route so that all packets coming in WAN destined for LAN are sent to veth0 rather than br-lan, and put an SQM on veth0
note that this is a little tricky, you could lose your connection to your router if you route to veth0 and it's not properly got veth1 in the bridge or something like that. Save your config backup before you try this stuff, and be prepared to revert via failsafe.
thank you again and again =)
It sounds a little bit complicated but I will try it on the weekend.
earlier you wrote:
Can I try it with this option in the meantime? If yes, how do I set it up? A third SQM instance, cake, piece of cake - thats easy. But which interface do I assign it to? wlan1? wlan0? And what bandwidth should I use? The wifi doesnt need that much and the main priority should still be the lan computer.
Also one more question regarding all of my SQM instances: Do you think overhead with 31 is correct? Connection is VDSL2 , PPPoE, VLAN 7 Tagging.
in your existing WAN instance you can specify a download rate, but beware that this will not have the nice properties of the DSCP tagging (so for instance it might drop your game packets).
Ok thanks.
I will try the veth thing as nothing will stop my nice new DSCP flaggings =)
Shout out to all other gamers: Try to it up as described in this thread. Im still very happy with the result!
So one thing I am unsure about is whether you are using sqm/cake's IP isolation modes or not, as these should help to isolate different machines from each other (say your gaming from your SO's strreaming). Could you post the contents of "/etc/config/sqm" here?
Well, on a Telekom vdsl2-link the actual overhead on top of the pppoe-wan device is actually 34 Bytes (8 bytes for PPPoE, 22 bytes for the ethernet frame (src-mac(6), dst-mac(6), ethertype(2), frame-check-sequence(4), VLAN(4))) and 4 bytes for the PTM overhead.
DTAG actually uses a traffic shaper at the BNG/BRAS level, so the uplink 4.8 Mbps are not the relevant limit for your uplink shaper. Luckily they for some time now report their estimated achivable tcp/ipv4/http goodput values as part of the PPPoE handshake, (in /etc/ppp/options uncomment "debug" then the PPPoE ACK message will be displayed in the log ("logread | grep -e pppd" will give you the output, look for SRD (download) SRU (ipload))). To get from there to the real configurable gross upload rate calculate:
SRU * (1526)/(1500-8-20-20)
Same for download, just replace SRU with SRD and keep in mind that ingress/download shaping requires a somewhat larger bandwidth sacrifice then egress/upload shaping, so for egress you might be able to set 100% of the calculated value above, for ingress I guess something like 90% of that number should work more reliable.
Getting the shaping bandwidth and overhead is really important for sqm to work as intended, after getting that right, you might want to retest even without the dscp magic (for testing, by all means use dscps there is a reason why sqm supports them). The next step would be internal IP isolation (see https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm-details especially the section titled " Making cake sing and dance, on a tight rope without a safety net").
Good luck!
Thanks for your reply.
here is config sqm:
and: How to I uncomment debug? What is the SSH command? Thanks in advance
And of course I will soon look into IP isolation and come back with probably a ton of questions =)
I guess there is still some room for experiments to see whether sqm can work a tad better even without using DSCP marking (again, I still recommend to use DSCPs for use-cases such as yours, but I fell the base configuration can be improved a bit, which partly will also help layer_cake's DSCP treatment)
Basically the protocol used by the program you used to generate the above screen shot.
SSH is short for Sechure SHell an encrypted terminal access to your router, basically a way to issue commands on the router's command line. See https://openwrt.org/docs/guide-quick-start/sshadministration for operating specific details.
By editing the file /etc/ppp/options. One way to do this should be to issue the following command:
sed -i 's/#debug/debug/g' /etc/ppp/options
This replaces the commented form #debug with the "active" form debug.
Sure, take your time, please keep your questions in the open (just keep posting in this thread).
SRU=4757#SRD=23619#
So 4996 for upload (maybe I just put 4900?) and 24806 - 10%= 22325 for download
Is that correct?
Something I noticed: my MTU is now 1484. Is that correct or shall I increase it? In the WAN section I typed in 1492.
I noticed I had a small error in my formula above (since corrected) the on-the-wire framesize is 1526 not 1525.
4757 * (1526)/(1500-8-20-20) = 4999.44 Kbps
23619 * (1526)/(1500-8-20-20) = 24822.72 Kbps
for safety reasons I would actually reduce these a bit to:
4757 * (1526)/(1500-8-20-20) * 0.99 = 4949 -> 4950 Kbps
23619 * (1526)/(1500-8-20-20) * 0.9 = 22340 -> 22300 Kbps
But your values should work as well.... (These are starting values anyway, you really should test how the link performs under load, with say the dslreports speedtest).
The next step after getting overhead and shaper bandwidth configured will be to fine-tune the configuration, but first things first 
So on pppoe-wan openwrt will automatically set the MTU effectively to 1492, so you should be able to undo your change without any loss of connectivity...
This acutally seems a rather important issue, as I had a constant loss of sync when I left it blank or put it on 1500. Does this make sense to you? Or was it just a really really bad coincedence with the ISP being bad (I normally have a very stable sync).? I am kinda afraid of going back to leave it blank as it took kinda all afternoon to break it down to the mtu change that is causing the sync loss.
Regarding the new values for igress and egress: they seem to be working good as well. I see constantly an A+ on bufferbloat. The quality grade sometimes go to A but I think this is due to the ISP or dslreports servers and not the router settings. So I guerss right that your next suggestion/tuning would be to look into internal IP isolation right? Or is there anything beforehand to tune? In the end, I really want to have the best settings and router possible.....
Intresting, could you please blank this field again, reconnect the wan interface and then do a "logread | grep -e pppd" and post the REDACTED (the debug output might contain clear text PPPoE username & password which you should not post here) output here? In my case pppd takes care of setting the MTU to 1492.
There is also the method described in https://en.code-bude.net/2017/02/20/how-to-read-calculate-and-set-mtu-in-windows-linux-and-osx/ to empirically check the current effective MTU, could you run this test as well (with the MTU field blanked out).
Wrong MTU on IPv4 might cause fragmentation and on IPv6 it might cause packet loss (if pMTUd does not work correctly) but it should have zero effect on the DSL-synchronisation, so what errors did you encounter exactly?
Great, now could you test this again with your game, just to confirm that this alone is not as good as you like it, espcially when the other user(s) start to concurrently use the link?
Yes, basically I would propose you replace your curent /etc/config/sqm with:
config queue
option debug_logging '0'
option verbosity '5'
option qdisc_advanced '1'
option squash_dscp '0'
option squash_ingress '0'
option ingress_ecn 'ECN'
option egress_ecn 'ECN'
option qdisc_really_really_advanced '1'
option linklayer 'ethernet'
option overhead '34'
option linklayer_advanced '1'
option tcMTU '2047'
option tcTSIZE '128'
option tcMPU '64'
option linklayer_adaptation_mechanism 'default'
option iqdisc_opts 'nat dual-dsthost ingress'
option eqdisc_opts 'nat dual-srchost'
option interface 'pppoe-wan'
option download '22300'
option enabled '1'
option upload '4950'
option qdisc 'cake'
option script 'layer_cake.qos'
And test this, if this is still not as good as with internal DSCPs (which would amaze my, as typically the upstream is somewhat more sensitive to DSCPs,) switch back to your dual sqm-instances, on-onWAN and one-on-LAN approach.
Have a look at https://serverfault.com/questions/769843/cannot-set-dscp-on-windows-10-pro-via-group-policy for potential ways to convince Windows 10 to expose its per application dscp marking capabilities even on non-domain controller/AD managed networks. This should help in marking your games (unless you play on a console, as I assume it will be super hard to configure this there). Heck you might even contact the game studio and ask nicely to make the DSCPs configurable....
Sure thing. First here is the determined MTU size with the method described above. 1464
Here the output of logread:
So the disconnects or loss of sync even happen with the set MTU of 1492. I have the fields empty at the moment. Fun fact: I think my ISP lowered my downlink (see SRD value in the screenshot above). Is that because I asked them to check the connection because of the disconnects? Are these frequent disconnects my mistake in the router config or is it the ISP?
OK, thought so. This is in line with my thoughts as mentioned above.
At the moment it is kinda unplayable as I have so many disconnects... but I will enter your SQM proposal in 20 min and get back to you.
Thank you so much, I really appreciate this kind of help!
This indicates an MTU of 1464 + 28 = 1492 so PPPoE does the right thing already, also notes how pppd complains about your MTU of 1492, as in that case it will need to fit its 8 byte header into the 1492 bytes resulting in an usable MTU to the internet of 1492-8 = 1484 Bytes...
Have a look at the output of the sync values in your modem, I expect that the Sync actually fell. If the sync value (or rather the maximum allowed by the DSLAM) end up being a muktiple of 1000Kbps it is very likely that DTAG's latest "toy" got activated on your link; DTAG now introduces Assia's DSLExpresse to manage problematic lines, you line with its relatively frequent losses might have triggered DSLExpresses intervention, which mostly shows as a fast reduction of the sync bandwidth that will, assuming your link stays error free enough, slowly be increased again. The idea is to trade a little bandwidth for more stability. In general not a bad idea,, but certainly something to keep in mind when using a traffic shaper on your router...
First thanks for all the testing, secondly, as long as your line keeps loosing sync no amount of sqm-goodness is going to save your bacon while gaming, this needs to be solved first, think about a "Stoerungsmeldung" with your ISP.
So I inserted the SQM settings as above. One question is regarding the custom firewall rules I insterted earlier with the iptables: Do I need to remove them or shall they stay?
For initial testing I would remove them, then if the simpler cake-only mode (with somewhat optimized cake settings) still does not work well enough with your gaming (which I assume tp be the case) you should reintroduce the iptable commands (and potentially also the split of the shaper into egress shaping on WAN and LAN).
Ok will do that.
When I go back to WAN LAN option, shall I keep the advanced settings you gave me?
And as you expected it, it is not good without the iptables.
Well these will to be adapted a bit for the LAN part, but let's tackle this once we get there...
This leaves me at a bit puzzled, do you run any heavy concurrent traffic while gaming?
BTW setting ICMP to CS5 seems slightly wrong, unless you exclusively want tp use ICMP packets to probe how your game traffic would behave (but please note that at least on egress unix ping will allow you to specify the dscp/tos marking on the packet, so you do not necessarily treat all icmp packets as CS5).
