Limit incoming and outgoing bandwidth and latency in linux – Managing your servers can streamline the performance of your team by allowing them to complete complex tasks faster. Plus, it can enable them to detect problems early on before they get out of hand and compromise your business. As a result, the risk of experiencing operational setbacks is drastically lower.
But the only way to make the most of your server management is to perform it correctly. And to help you do so, this article will share nine tips on improving your server management and fix some problem about linux, networking, bandwidth, latency, .
I realise many similar questions have already been asked, but so far I’ve yet to find a solution to my problem.
I have a virtual linux server (running Debian Squeeze) that I use for testing of website speeds in order to measure increase and decrease in load time of said websites. I’m attempting to limit the bandwidth and latency of this server in order to be able to get close to real world load times on the websites, but have so far failed.
What I want specifically is the following:
- To set an incoming and outgoing latency of 50 ms.
- To set an incoming bandwidth limit of 512 kbps.
- To set an outgoing bandwidth limit of 4096 kbps.
I’ve been reading up on netem and using the
tc command, but it’s still all a bit over my head. I’ve managed to put together this command to control the latency which seems to work, but I’m not even sure if that only handles the outgoing latency or both:
tc qdisc add dev eth0 root netem delay 50ms
Any network gurus around that can help me out?
After further research I’ve gotten halfway to my goal, using this command all outgoing traffic behaves as I want it to:
tc qdisc add dev eth0 root tbf rate 4.0mbit latency 50ms burst 50kb mtu 10000
However, I still haven’t been able to throttle the incoming traffic properly. I’ve learnt that I’m supposed to use an “Ingress Policer filter” I’ve been trying to do just that with the command below, playing around with different values, but no luck.
tc qdisc add dev eth0 ingress tc filter add dev eth0 parent ffff: protocol ip u32 match ip src 0.0.0.0/0 flowid :1 police rate 1.0mbit mtu 10000 burst 10k drop
The bandwidth is affected by the command though, the values above make the speed start at 2MB/s and, as a transfer progresses, slowly dropping down to around 80-90kB/s which it reaches after about 30 seconds of transfer.
Any ideas on what I’m doing wrong?
I finally settled for just setting the outgoing bandwidth/latency on the server, and then doing the same on the client, effectively reaching the same result.
These are the commands I ran on the server and client respectively to reach my goals:
Server: 4 Mbit 50 ms
tc qdisc add dev eth0 handle 1: root htb default 11 tc class add dev eth0 parent 1: classid 1:1 htb rate 1000Mbps tc class add dev eth0 parent 1:1 classid 1:11 htb rate 4Mbit tc qdisc add dev eth0 parent 1:11 handle 10: netem delay 50ms
Client: 512 kbit 50 ms
tc qdisc add dev vmnet1 handle 1: root htb default 11 tc class add dev vmnet1 parent 1: classid 1:1 htb rate 1000Mbps tc class add dev vmnet1 parent 1:1 classid 1:11 htb rate 512kbit tc qdisc add dev vmnet1 parent 1:11 handle 10: netem delay 50ms
Some 80-90 kByte / s is about what to expect from
tc filter add ... police rate 1.0mbit ...
You ask incoming data to be thrown away when it arrives at 1 mBit / s, that’s about 125 kByte / s. The remote server will then drop to considerably lower than that (maybe half, not sure). After that, all packets come through, so the remote end slowly picks up speed until 125 kByte / s are again reached. You get an average throughput considerably below 125 kByte / s, which is typical of ingress shaping.
I’m a bit surprised that the speed should reach 2 MByte / s with the ingress policy filter already in place. Where did you measure – at the downstream client (programm) or at some upstream router? Or maybe you first started the connection and only afterwards you kicked the ingress policy filter in place?