Manually Throttle the Bandwidth of a Linux Network Interface
mark.koli.ch
mark.koli.ch
Wrong: you see 10KB/s download speed because you are not throttling the incoming packets but the outgoing packets!
So, what you are really doing is rate limiting outgoing ACK packets to 1KB/s, which delays your outgoing ACKs, hence preventing the remote server from sending you data at full throttle.
You can see that with a tool like "bwm-ng" to see Rx/Tx speed, and you'll see exactly 1KB/s on Tx, and something variable on Rx.
The incoming rate will fluctuates depending on the TCP window setting used by the server which translate to how many non-acknowledged packets are allowed to be sent by the server.
Yep. TC's default is to policy outgoing traffic, which in OP's example is a bunch of TCP ACKs essentially. Instead, they should be using ingress keyword, something like described here:
http://blog.stevedoria.net/20050906/ingress-policing-with-li...
Caveat emptor: ingress rate-limiting is hard. Long story short, it all boils down to what you do with non-confirming packets: There are two alternatives, and both are rather sub-optimal. You can either buffer/delay packets in kernel space (default, which leads to bufferbload and memory waste), or drop (which author linked above opted for, which leads to excessive retransmits and bandwidth waste).
Not being pedantic, genuinely trying to understand how this stuff works.
Big network gear vendors that ship to ISPs have adopted early forms of AQM (both RED [3] and proprietary algorithms) quite a while ago - they had to:
(a) backbone routers have much smaller buffer-to-bandwidth ratio (compared to a PC or even home router), so endless buffering is not an option;
(b) buffer tail drops (i.e. what drop keyword does when added to tc filters/disciplines) interact really poorly with TCP bandwidth control algorithms, and rather badly with RTP streams, too (so drop is not an option either - it ruins user's connections; and
(c) ISPs and carriers would typically run links (on average) much closer to saturation than your typical home router, so situation where router has to make buffer/drop decision is much, much more frequent.
[1] My point above was that you don't really want to drop packets on the receiver side, after that packet already traversed expensive part of the network.
Your modem and the box on the other end of that bottleneck link are probably buffering far more than is reasonable. There's simply no reason for a cable modem to ever have in excess of 1s worth of backlog.
# htb
tc qdisc add dev eth0 handle 1: root htb default 11
tc class add dev eth0 parent 1: classid 1:1 htb rate 1kbps
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 1kbps
# tbf
tc qdisc add dev eth0 root tbf rate 1kbit latency 42ms burst 2k
[1] i.e. stuff like "I would like to have tcp/80 limited to 10 mbit/s, tcp/443 limited to 15 mbit/s, while sum of above should never exceed 20mbit/s, and tcp/80 should get priority when competing for that shared 20mbit/s"
EDIT: changed to "burst 2k". Having burst lower than interface MTU will delay large packets essentially forever.
one of my first gigs was troubleshooting an application failure over a low bandwidth dedicated link - everything worked fine until the traffic volume resulted in scheduling jitter due to buffer latency; the resulting added overhead of continual connection renegotiation operations killed what was rest of the link the link and caused the failure to propagate into the application itself..
thankfully this oversight led to me as an intern needing to perform the experiment to 'prove' the point, and a subsequent job offer.. so at least there was that :)
When capacity in your particular spot beam is good, latency could be 550 to 600 ms end to end. When it's bad it could be 1300 or 1700ms and will jitter around randomly anywhere in between those two figures.
It makes it much easier to do throttle the way you want.
tc is complicated because it does more things.
If some supercool app or videos don't work, sure, no problem, but if reading some programming documentation (with maybe 30KB of actual text) or a bank statement (with maybe 2KB of actual information) or even getting a restaurant address/phone number doesn't work because of monstrously huge sites with much back and forth (what's the technical term here...), that's frustrating.
So please please please do try to make your sites usable over bad connections :-)
This is only going to happen if people are accurately simulating the true problem. The instructions given in the article and the measures implemented by wrappers like the comcast tool mentioned in another comment do not simulate anything remotely realistic. Testing against a simulation like this can help verify that the obvious changes like reducing image sizes and the total number of requests for a page will help, but it won't fully show how things like the CDG and BBR TCP congestion control methods help.
What I've done when using a slow connection is run emacs with w3m on a remote server and get the rendered text through SSH. I'm realizing more and more that a lot of our interfaces are more visual so I might try your method.
https://www.google.com/search?q=ssh+timeout+keepalive+sshd_c...
Also, don't the instructions in this article only apply to outbound traffic?
If you're trying to simulate poor network conditions, you need to have a better understanding than this of what causes poor network performance, and how to properly emulate it.
http://jvns.ca/blog/2017/04/01/slow-down-your-internet-with-...
It has delay, loss, duplication, corruption, re-ordering, rate control.
And take a look at this SO thread: [http://stackoverflow.com/questions/130354/how-do-i-simulate-...]
Linux network stack isn't designed for this. The best easy thing to use is BSD's Dummynet pipes.