Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.
Sign up to join this community
I use this tc command to limit upload speed on an interface:
tc qdisc add dev eth1 root tbf rate 2mbit burst 10kb latency 70ms peakrate 2.4mbit minburst 1540
But it results in heavy packet loss. If the data coming via eth0 (WAN) is 7 GB, it will be 6.2 GB on the rate-limited interface eth1. Are there any other rate limiting solutions that cause lesser packet loss?
If I've understood correctly, you're trying to limit your ingress traffic from your ISP by limiting egress traffic on your locally facing interface.
The packet loss you're seeing are probably to be expected, as dropped packets are (one of) TCPs way(s) of detecting congestion, and the way a router can signal congestion. It's also the only reasonable way your router can abide by the limitation you've given it via tc without breaking i.e. TCPs congestion avoidance. (tc does have facilities for using RED, although I don't know enough about this to tell you anything beyond it's existence).
Instead of shaping egress traffic on your inward facing interface, you could check out tc's ingress qdisc, attach it to the interface facing your ISP and a tc filter to police your ingress traffic. Packet loss will still occur, as it's probably the only viable way for your router to signal congestion.
For an example, see the LARTC cookbook entry "The Ultimate Traffic Conditioner", which among other things use tc's ingress qdisc.
ingress qdisc there will be packet loss. I specified 2mbit as the limit, and WAN facing interface shows incoming rate around 300kBps. On NAT facing interface it was stable 250kBps. But it was slightly better than rate limting on NAT facing interface. In my case I have one WAN interface, and more than one NAT interfaces facing separate local networks. For one network I need to limit download speed to 2mbit.
May 24, 2011 at 10:02
It depends on the size of your tx queue, if you're throttling hard then the TC can only drop rather than queue the packets, unfortunately I only know how to do this on cisco ios, not unix tc.
You can increase the size of your queue to fix the problem. (As stated by jdborg) Sorry, my rating isn't high enough to comment directly.
If this command is producing unwanted packet loss
sudo tc qdisc add dev eno1 root tbf rate 1mbit burst 32kbit latency 400ms
You can fix the problem by increasing the buffer (queue) size by changing the latency from 400ms to 10000ms
The command would now look something like this sudo tc qdisc add dev eno1 root tbf rate 1mbit burst 32kbit latency 10000ms
In Summary: Increasing the queue size as I have shown above will fix the packet loss problem. It is just a matter of how much it will need to be increased.
I did a 10Mbps iPerf test when the queue was only 400ms, which resulted in 90% dropped UDP packets. Redoing the iPerf test when the Queue was set to 10000ms resulted in 0% packet loss.
How I setup the iPerf test
The iPerf test was done where PC#1 was the iPerf server, and PC#2 was the iPerf client. PC#2's outbound connection was throttled via the tc command
eth0has the WAN ip. As only upload speed can be shaped, I use the above posted line oneth1which is the NAT interface. So I shape the download rate ofeth0by shaping the upload oneth1.