Hello,
I've been tweaking and trying out stuff with Cake but have a few questions.
My current connection is: ADSL2+, Annex M (DSLModem/PureBridge-->Router(Openwrt)) and I have been running ATM_Overhead_Detector script and the results were showing a 32 byte overhead (RFC 1483 Bridged LLC). But after some research I started to wonder if I should set (somehow) 32 byte overhead on ingress and 18 on egress due to Linux adding the 14 byte ethernet frame? Is my logic correct, if so how do I do this? Here is my config file and tc -d qdisc output:
qdisc noqueue 0: dev lo root refcnt 2
qdisc fq_codel 0: dev eth0 root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn
qdisc noqueue 0: dev br-lan root refcnt 2
qdisc noqueue 0: dev eth0.2 root refcnt 2
qdisc cake 8019: dev eth0.1 root refcnt 2 bandwidth 2Mbit besteffort triple-isolate nonat nowash no-ack-filter split-gso rtt 100.0ms raw overhead 0
linklayer atm overhead 18 mpu 64 mtu 2047 tsize 128
qdisc ingress ffff: dev eth0.1 parent ffff:fff1 ----------------
qdisc cake 801a: dev ifb4eth0.1 root refcnt 2 bandwidth 14Mbit besteffort triple-isolate nonat wash no-ack-filter split-gso rtt 100.0ms raw overhead 0
linklayer atm overhead 18 mpu 64 mtu 2047 tsize 128
I'm also curious how ATM frames affect gaming when many games send small UDP packets and the minumum packet size is 106 ? 53+53 . If the game sends an 80 byte packet it means after its always 106 due to cell padding?
The other side of the DSL link will reassemble the IP packet before passing it onto non-ATM links, so this ATM celling is mostly invisible, except the one often can see that the RTT latency of packets increases in steps of 48 bytes (the ATM overhead detector uses this fact to deduce the overhead).
Thank you for sharing your knowledge. I've been reading up alot and trying all kinds of different configurations and settings. But I seem to have the same problem as another user here on this forum, I'm playing CSGO on a pretty high level and when I'm using cake my bullets dont register. So I switched too fq_codel and it feels alittle bit better..
But now I'm curious why simplest_tbf.qos isnt running for me because I want to try it out. This is the weird message I get in the kernel log:
sch_tbf: burst 1 is lower than device TMP_IFB_4_SQM mtu (1514) !
What is TMP_IFB_4_SQM? And anyone have any idea how to fix this
This error message should not affect simplest_tbf.qos's functionality this happens in the stage where we set up test qdiscs to figure out whether they are operational. This should also be fixed in current master builts, but not in the 18.x branches.
As soon as I use simplest_tbf.qos I cant surf the web. In my webbrowser it says TLS handshaking and just freezes.. Guessing some fragmentation is going on and messes things up.
Is there an easy way to upgrade to the latest build and try running it?
btw, Im running openwrt on my asus rt-51u so its kind of slow but for my connection i guess its alright
edit: update on simplest_tbf. it's running fine on snapshot releases of openwrt
So, I can definitly 'feel' a difference when running cake/piece of cake and playing CSGO. And the hitreg is worse with it. When running freshly flashed OpenWRT and no aqm or tc it is much better. And I'm trying and want to figure out why it is that way, and what the optimal settings for my setup is.
If anyone have any idea how to systematicly test different setups (trial and error way) I would very much like to hear. I guess maybe I can run tcpdump (???) while playing and try to read the output what's happening, but also I'm thinking I need some higher degree in network engineering and figure out how the netcode in the source2 engine work... Gah this is frustrating for someone who always looking to optimize...
I assume you mean with no other activity on the line? would be surprised if you could play at all with no SQM and someone else on your LAN running a speedtest
Yeah no activity beside me. I don't know. Maybe it's some kind of nocebo/placebo when using cake and not using it... or server issues or my line condition is changing exactly when i turn off sqm. but I looked at my modem stats and they look alright.. Some CRC errors maybe around 200 at 24h. So I guess its alright. There are so many variables to change though, my windows machine where i can change different paramentars on my NIC like offloading/rss queues/interrupt moderation/flow control etc. then there is the nic on my router where you can change alot and.. then you have the linux kernel with sysctl and ipv4 core tcp variables. so there is alot to look into... also csgo where you can changits a mess..
but at the moment the best 'feeling' is running no sqm default fq_codel/cubic(although i dont think it has any impact on the udp packets but i havent understood the netcode for source2 engine if it using a mix tcp and udp.) Also disable offloading on the router but only offloading like gro if i disable checksum rx and tx it feels weird when gaming. and on my intel nic disable everything tcp/udp offloading, interrupt moderation, flow control, etc etc.
So I'm running with this at the moment, but still when spraying with an ak/colt its like this jerky feeling where there is delay between the bullets and sometimes not. hard to explain. the hitreg is on point though. But it's not smooth when spraying. I'm probably digging to deep in to this for my own good but I learn a little about linux and network while doing it
well, cake is a bandwidth shaper, which means it's delaying packets. so long as your total traffic is well below the bandwidth limit your ISP uses, the fastest delivery will be without shaping.
as soon as someone else tries to bulk download or upload anything over TCP though, the bufferbloat starts and your game will become unplayable
Well, unless your link is close to saturation a shaper should have almost no effect on latency. Unless either the shaper's configuration is unusual or the router's CPU is overloaded. I note that for a shaper to become affected CPU "micro"stallls are sufficient....
There have been reports of some consumer routers having serious latency related issues that are caused by some kind of driver bugs, the R7800 is one of them. what router hardware are you using?