How to Limit the Network Bandwidth Used by Applications in a Linux System with Trickle

How to Install Trickle in Linux

1. Install trickle via yum or aptitude.

To ensure a successful installation, it is considered good practice to make sure the currently installed packages are up-to-date (using yum update) before installing the tool itself.

# yum -y update && yum install trickle 		        [On RedHat based systems]
# aptitude -y update && aptitude install trickle 	[On Debian based systems]

2. Verify whether trickle will work with the desired binary.

As we explained earlier, trickle will only work with binaries using dynamic, or shared, libraries. To verify whether we can use this tool with a certain application, we can use the well-known ldd utility, where ldd stands for list dynamic dependencies. Specifically, we will look for the presence of glibc (the GNU C library) in the list of dynamic dependencies of any given program because it is precisely that library which defines the system calls involved in communication through sockets.

Run the following command against a given binary to see if trickle can be used to shape its bandwidth:

# ldd $(which [binary]) | grep

For example,

# ldd $(which ncftp) | grep

whose output is:

# => /lib64/ (0x00007efff2e6c000)

The string between brackets in the output may change from system to system and even between subsequent runs of the same command, since it represents the load address of the library in physical memory.

If the above command does not return any results, it means that the binary it was run against does not use libc and thus trickle cannot be used as bandwidth shaper in that case.

Learn How to Use Trickle

The most basic usage of trickle is in standalone mode. Using this approach, trickle is used to explicitly define the download and upload speeds of a given application. As we explained earlier, for the sake of brevity, we will use the same application for download and upload tests.

Running Trickle in Standalone Mode

We will compare the download and upload speeds with and without using trickle. The -d option indicates the download speed in KB/s, while the -u flag tells trickle to limit the upload speed by the same unit. In addition, we will use the -s flag, which specifies that trickle should run in standalone mode.

The basic syntax to run trickle in standalone mode is as follows:

# trickle -s -d [download rate in KB/s] -u [upload rate in KB/s]

In order to perform the following examples on your own, make sure to have trickle and ncftp installed on the client machine ( in my case).

Example 1: Uploading a 2.8 MB PDF file with and without trickle.

We are using the freely-distributable Linux Fundamentals PDF file (available from here) for the following tests.

You can initially download this file to your current working directory with the following command:

# wget 

The syntax to upload a file to our FTP server without trickle is as follows:

# ncftpput -u username -p password  /remote_directory local-filename 

Where /remote_directory is the path of the upload directory relative to username’s home, and local-filename is a file in your current working directory.

Specifically, without trickle we get a peak upload speed of 52.02 MB/s (please note that this is not the real average upload speed, but an instant starting peak), and the file gets uploaded almost instantly:

# ncftpput -u username -p password  /testdir LinuxFun.pdf 


LinuxFun.pdf:                                        	2.79 MB   52.02 MB/s

With trickle, we will limit the upload transfer rate at 5 KB/s. Before uploading the file for the second time, we need to delete it from the destination directory; otherwise, ncftp will inform us that the file at the destination directory is the same that we are trying to upload, and will not perform the transfer:

# rm /absolute/path/to/destination/directory/LinuxFun.pdf 


# trickle -s -u 5 ncftpput -u username -p password /testdir LinuxFun.pdf 


LinuxFun.pdf:                                        	2.79 MB	4.94 kB/s

In the example above, we can see that the average upload speed dropped to ~5 KB/s.

Example 2: Downloading the same 2.8 MB PDF file with and without trickle

First, remember to delete the PDF from the original source directory:

# rm /absolute/path/to/source/directory/LinuxFun.pdf 

Please note that the following cases will download the remote file to the current directory in the client machine. This fact is indicated by the period (‘.‘) that appears after the IP address of the FTP server.

Without trickle:

# ncftpget -u username -p  password . /testdir/LinuxFun.pdf 


LinuxFun.pdf:                                        	2.79 MB  260.53 MB/s

With trickle, limiting the download speed at 20 KB/s:

# trickle -s -d 30 ncftpget -u username -p password . /testdir/LinuxFun.pdf 


LinuxFun.pdf:                                        	2.79 MB   17.76 kB/s

Running Trickle in Supervised [unmanaged] Mode

Trickle can also run in unmanaged mode, following a series of parameters defined in /etc/trickled.conf. This file defines how trickled (the daemon) behaves and manages trickle.

In addition, if we want to set global settings to be used, overall, by all applications, we will need to use the trickled command. This command runs the daemon and allows us to define download and upload limits that will be shared by all the applications run through trickle without us needing to specify limits each time.

For example, running:

# trickled -d 50 -u 10

Will cause that the download and upload speeds of any application run through trickle be limited to 30 KB/s and 10 KB/s, respectively.

Please note that you can check at any time whether trickled is running and with what arguments:

# ps -ef | grep trickled | grep -v grep


root 	16475 	1  0 Dec24 ?    	00:00:04 trickled -d 50 -u 10
If you liked this article, then do subscribe to email alerts for Linux tutorials. If you have any questions or doubts? do ask for help in the comments section.

If You Appreciate What We Do Here On TecMint, You Should Consider:

TecMint is the fastest growing and most trusted community site for any kind of Linux Articles, Guides and Books on the web. Millions of people visit TecMint! to search or browse the thousands of published articles available FREELY to all.

If you like what you are reading, please consider buying us a coffee ( or 2 ) as a token of appreciation.

Support Us

We are thankful for your never ending support.

17 thoughts on “How to Limit the Network Bandwidth Used by Applications in a Linux System with Trickle”

  1. Hi,
    How to limite bandwidth only when needed.

    Ex: I want use app1 to download on a system with total bandwidth of 800 ko/s
    # trickle -d 600 foo_app1
    To let 200 ko/s to other apps.
    How call ‘trickle’ to tell it to use all Bandwidth when other app are finish to use bandwidth remaining ?
    I haven’t see no options in man page.
    Perhaps another app do that?

  2. If any user figures out how to run your app without trickle your bandwidth management no longer works. You need method that are part of the kernel for proper bandwidth management.

    • @cybernard,
      Would you be as kind as to share a specific example of how an user would be able to do that? Please notice that we covered this possibility near the bottom of the article. If you make an experiment and are able to fool trickle, please report back with the specifics so we can edit the article accordingly. Thank you!

  3. This is very interesting but a bit redundant. Cgroups (control groups) is built into the kernel and provides awesome control over an application’s usage of not only network but mem, CPU, disk I/o and more. This is taken to the next level by containers and docker which provide better tooling and automation to make more easily use cgroups and other plumbing built into the os.
    I highly recommend spending your time learning docker and the other container tooling as this is the future for better designed apps and this skill set is in VERY high demand right now.

    • @Terry,
      Thanks for taking the time to share such a well-supported and informative comment. You are SO right about docker. The reason why we published this article is because it outlines the basics of network bandwidth shaping. We will consider writing and publishing a docker series in the near future once we’re done with the RHCSA and RHCE series.


Got something to say? Join the discussion.

Have a question or suggestion? Please leave a comment to start the discussion. Please keep in mind that all comments are moderated and your email address will NOT be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.