2

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?

2
  • 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? – This 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
3

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.

2
  • 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. – This May 24 '11 at 10:57
0

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.

0

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.

Here is an Example

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.

My Research

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 enter image description here

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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