Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
I'm missing part of the picture. When you say "it will be 6.2GB on the rate limited interface", what is "it"? Are you saying you had 6.2GB data transmitted or 6.2GB data dropped or?? How are you measuring data dropped? How fast are you actually uploading the data through eth1 when you apply this policy? Which application are you using? – Mike Pennington May 20 '11 at 16:29
It's a Linux NATing router. I have a 4 mbps connection, and eth0 has the WAN ip. As only upload speed can be shaped, I use the above posted line on eth1 which is the NAT interface. So I shape the download rate of eth0 by shaping the upload on eth1. – nixnotwin May 20 '11 at 17:13
up vote 3 down vote accepted

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.

share|improve this answer
Even in 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. – nixnotwin May 24 '11 at 10:02
Re: "Packet loss will still occur, as it's probably the only viable way for your router to signal congestion." TCP signals congestion with packet loss; there is no magic associated with ingress or egress queueing. – Mike Pennington May 24 '11 at 10:57

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.