1

I am in need of simulating a high latency and low bandwidth connection for a performance test of my application. I have gone through a number of pages describing the tc command. But, I haven't been able to validate the numbers that I set. For example:

I took the following command values from: https://www.excentis.com/blog/use-linux-traffic-control-impairment-node-test-environment-part-2

tc qdisc add dev eth0 root tbf rate 1mbit burst 32kbit latency 400ms

With that applied on (say, machine A), according to the description on the page, I am assuming my output rate should be 128 kBps (at least approximately). To test this, I started transferring a 2 GB file using scp from machine A to another machine "B" which are in the same LAN. Transfer rates without any added impairment reach up to 12 MBps in this network. But, when the transfer started the rate was at 2 MBps, then it kept stalling and falling down until when it started to swing and stall between 11 kBps and 24 kBps.

I used nmon to monitor network throughput on both sides during the transfer, but it never went above 24 kBps (except for a couple of values reading 54 and 62).

I have also tried increasing the rate and bucket size, but the behavior during scp is the same. I tried the following command to increase the bucket size and the rate:

tc qdisc add dev eth0 root tbf rate 1024kbps burst 1024kb latency 500

And scp still stalled and swung around the same rates (11-30 kBps).

Am I inferring the term "rate" wrong here? I have looked at the man page for tc and it appears that my interpretation is correct. Could anyone explain to me what would be the best way to test the set parameters (assuming I did it correctly)?

0

In order to induce latency, you need to use the 'netem' qdisc.

You have been distracted by the 'latency' parameter to the TBF qdisc. For the TBF qdisc, this parameter only sets the maximum latency that will be allowed for enqueued packets. So, for example, if the queue is deep enough that the latency of an individual packet would be 400ms, then the packet will be tail-dropped. This doesn't actually help you simulate the high-latency you are hoping for.

I'd suggest using something like:

tc qdisc add dev eth0 root netem delay 400ms rate 1024kbps

Note: Do you mean kbit, though?

The tc tool refers to kilobits per second as 'kbit' and kilobytes per second as 'kbps'.

0

@user144844 Appreciate the response. Just FYI, netem doesn't have a rate argument.

I understand the tbf parameters fairly well. I am also aware of latency as part of a token bucket filter, and network latency in general. The problem, as I have mentioned, was that I could not see the rate being throttled at the set rate value when tested through scp for a 2 GB file.

Coming back to the original question: I decided to go ahead with my actual simulation with a number of virtual users doing certain transactions through the server where I set a 256 kbps bandwidth. In the end, it was clear that the set rate had been applied since my throughput came down from 968kbps (in LAN conditions) to 249 kbps (rate applied using tbf). The same persisted when I increased the load to twice and thrice the original and I could see the response time getting impacted. So, I believe the set parameters do work. scp just isn't the best way to test it.

I used the following commands to set my network conditions:

# tc qdisc add dev eth0 root handle 1: tbf rate 256kbit burst 256kbit latency 200ms
# tc qdisc add dev eth0 parent 1:1 handle 11: netem delay 50ms
# tc qdisc show
qdisc tbf 1: dev eth0 root refcnt 2 rate 256000bit burst 32Kb lat 200.0ms
qdisc netem 11: dev eth0 parent 1:1 limit 1000 delay 50.0ms

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.