I'm trying to have some simple bandwidth throttling set up on a Linux server and I'm running into what seems to be very weird stuff despite a seemingly trivial config.
To test, I start a file download over HTTP from the said client machine and measure the resulting speed by looking at Kb/s in Firefox.
Now, the behaviour is rather puzzling: the DL starts at about 10Kbyte/s and proceeds to pick up speed until it stabilizes at about 75Kbytes/s (Kilobytes, not Kilobits as configured!). Then, If I start several parallel downloads of that very same file, each download stabilizes at about 45Kbytes/s; the combined speed of those downloads thus greatly exceeds the configured maximum.
What I can't for the life of me understand is this: how come I get a "rate 589888bit 5pps" with a config of "rate 75000bit ceil 75000bit"? Why does the effective rate get so much higher than the configured rate? What am I doing wrong? Why is it behaving the way it is?
Please help, I'm stumped. Thanks guys.
I think I kinda sorta fixed the issue: I needed to tie the qdiscs/classes to an IMQ device rather than an ETH device. Once I did that, the shaper started working.
While I could get the shaper to limit traffic incoming to a machine, I couldn't get it to split traffic fairly (even though I've attached a SFQ to my HTB).
So I dismantled my config, went ahead and set up ClearOS 5.2 (a Linux distro with a pre-built firewall system) that has a traffic shaper module. The module uses an HTB + SFQ setup very similar to what I configured by hand.
Same fairness issue! The overall limit is enforced well, but there is no fairness! - two downloads share in the same weird proportion 65/15 proportion rather than 35/35.
This creates an htb bucket with rate limit of 75Kbit/s, then it creates two sfq (a fair queing qdisc) underneath that.
By default, everyone will be in the first queue, with a guaranteed rate of 1Kbit and a max rate of 30Kbit. Now, your ip of 10.41.240.240 will be guaranteed 35Kbit and can take as much as 75Kbit if the non-selected traffic is utilized. Two connections from .240 should average out and be the same per connection, and a connection between a .240 and a non .240 will parallel at a 35:1 ratio between queues.
I see this has been dead since Apr... so hopefully this info is still of value to you.
The rate (299288) is considerably larger than the ceiling (230000).
There are a large number (90174) of giants reported.
This problem will be corrected by disabling "checksum offloading" in your domU(s) using the ethtool utility. See the one of the Xen articles for instructions.
Not the answer you're looking for? Browse other questions tagged linux tc htb or ask your own question.
Sharing Bandwidth and Prioritizing Realtime Traffic via HTB, Which Scenario Works Better?
How to add delay to incoming traffic?
Is there a way to limit bandwidth per ip using HTB + a CIDR range in Linux?