if you are using cake, changing the existing config in cron or via some other tool is faster and doesn't break the state of the connections that invoking sqm does.
e.g.
tc qdisc change dev eth0 root cake bandwidth X
You can still use one of the uci commands to make the value in /etc/config/sqm reflect the actual current setting, which has the advantage that if your connection is killed (think pppoe) the sqm instance that hotplug.d will start after the interface re-appears will hav the most recent bandwidth set...
Thanks Dave! Just made the decision to pull an all-nighter since I have to be up in a few hours anyway, and noticed your OP in this thread just as I switched my bedroom lamp off. The video was thoroughly enjoyable and worth it; don't think I've laughed so hard for a very long time! And incredibly informative and interesting too 
. I only wish I had've known about LCA so I could've attended personally.
Now I'm going to read about the 1986 internet collapse and revamp my knowledge of the TCP and UDP protocols, since I've mostly forgotten everything from my 2013 Networking 101 classes.
On behalf of all of humanity, thank you so much for your past and continued efforts to mitigate (and eventually eradicate, I hope) this crazy problem that I never knew existed until a few days ago. Cheers! 
Somehow figuring out how to give that AHA! moment to 99.99999% of the populace that doesn't get it yet, has long been on my mind. Really, it's quite a long journey from realizing your network doesn't have to be chunky and slow, that you don't have to yell upstairs to "daad, stop using the internet so I can game", to conceptualizing QoS, then bufferbloat and the fixes for it. I really wish that someday, somehow, we come up with a faster way of gaining deeper understanding.
Would you have grokked and enjoyed my talk as much a month ago, before you sort of understood this stuff? Would your mom? Boss? I don't know. Certainly I've found very few journalists that grok it.
1 Like
It's useful to think about how much time it takes to transfer N packets. It's L + N/B
L is the latency it takes to get one packet to travel through the pipe... N/B is how long it takes to "pour N packets through the pipe"...
If you have a big bandwidth... B is large... You still can't make it be faster than L + 0
Key to making things feel fast is to make L small so that all the quick little things you need to do to set up lots of connections and so forth doesn't take long.
If course of you have big chunks of data you Also want big bandwidth B so you don't wait for large transfers.
But the point of it being two quantities and both need to be small is worth emphasizing
As a web developer who deals with bufferbloat on an hourly basis (even though I didn't know it; always blamed my ISP and federal government for implementing poor-quality infrastructure), yes, I would have. My mum is sadly no longer with us, but even if she were, you are correct in assuming that she wouldn't have a clue about any of this stuff LOL. My dad struggles to turn the computer on, so yeah...and journalists, well...do any of those people really care about anything besides selling papers?
It certainly is a crying shame though. We need to get the word out on a global level, and I for one will be telling all my clients to raise hell from now on if they experience the same hourly issues that I used to (which they presumably do).
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.