Trickle: A lightweight userspace bandwidth shaper

May 30th, 2007 edited by ana

Article submitted by Ferry Boender. We are running out of articles ! Please help DPOTD and submit good articles about software you like NOW !

Sometimes, you’ll want to download something but you don’t want it to completely saturate your Internet connection. Perhaps you’re already downloading something more important, or you simply don’t want to get in the way of other people that are sharing the same Internet connection. Some programs, such as gFTP, wget and bittorrent, offer built-in up/download rate limiting. Other programs, such as apt-get and associates, don’t. Enter Trickle.

Trickle is a user space bandwidth shaper. It allows you to limit the bandwidth consumption of a program without requiring all kinds of kernel patches, firewall configurations or root access to the machine on which you wish to use it. Trickle can run in collaborative and stand alone mode. In collaborative mode, trickle can limit the bandwidth used by a bunch of programs at the same time. In stand alone mode, trickle simply limits the program you specify.

Stand alone mode

Trickle is easiest to use in stand-alone mode. Simply run trickle with a download and/or upload limit and a program you want to limit. For example:

[todsah@jib]~$ trickle -d 20 -u 20 wget
trickle: Could not reach trickled, working independently: No such file or directory
           => `bigfile’
Connecting to||:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: 51,200,000 (49M) [text/plain]

 0% [                                     ] 180,224       21.83K/s    ETA 38:03

In the example above we use wget for demonstrative purposes, even though it has built-in bandwidth shaping. As you can see, the download rate is 21.83K/s. Of course, this is not exactly 20 K/s, but the download rate will vary between 19 and 21 K/s giving an average of 20 K/s. You can use the -w and -t command-line options to fine-tune this behaviour. The longer trickle runs, the closer it will get to 20 K/s. For more information, check out the manual page.

Daemon mode

In daemon mode, trickle can limit a group of programs to a fixed limit of bandwidth. To start the daemon, run the trickled command:

[todsah@jib]~$ trickled -d 20 -u 20

This will start the trickle daemon that will limit the total bandwidth available to all programs run via trickle to 20 K/s both up and down. So if you run a single program via trickle, it can consume 20 K/s. Two programs can each consume 10 K/s, etc. As an example, we start three wget sessions:

[todsah@jib]~/temp$ trickle wget
 1% [                                     ] 933,888        6.66K/s  ETA 1:47:17
[todsah@jib]~/download$ trickle wget
 1% [                                     ] 720,896        6.65K/s  ETA 1:56:59
[todsah@jib]~$ trickle wget
 2% [                                     ] 1,228,800      6.64K/s  ETA 1:45:00

The download rate is limited to about 6.6 K/s per session, making a total of 19.8 K/s. As is usually the case with bandwidth shapers, it may take a couple of seconds before all sessions are correctly limited. This is because of the algorithm used by shapers to determine how much they should delay the sending and receiving of traffic.


Trickle has been available in Debian at least since v3.1 (’Sarge’) and in Ubuntu since Warty. apt-get install trickle should do the trick.


  • Trickle doesn’t work with setuid programs. The reason for this is that setuid programs ignore the LD_PRELOAD functionality for security reasons. Trickle requires this functionality to do its shaping. (It also doesn’t work with statically linked programs for the same reason.)
  • Trickle only works with programs that use the socket(2) interface for transmitting and receiving data. Also, it only works with TCP connections, not with UDP connections.

Posted in Debian, Ubuntu |

17 Responses

  1. N. Nobelis Says:

    Very interesting article !
    Is it possible to adjust the limit after the launch of trikle ?

  2. Michael Magua Says:

    Rather useless for wget as it has the –limit-rate option.

  3. Ferry Boender Says:

    N. Nobelis Says:
    > Very interesting article !
    > Is it possible to adjust the limit after the launch of trikle ?

    No, that doesn’t appear to be possible. I tried killing the daemon and then restarting it with a different limit (while trickle instances where running), but that doesn’t seem to work. All trickle instances are simply limited to 10K/s (independent of the limit specified) after killing the daemon.

    Michael Magua Says:
    > Rather useless for wget as it has the –limit-rate option.

    As is noted in the article, wget was used for demonstrative purposes. wget was chosen mostly because it’s output is terse. Plus, wget doesn’t offer the same functionality as trickle in daemon mode where you could choose to limit all wget instances to a total of X K/s.

  4. N. Nobelis Says:

    In fact, the command tricklectl should allow us to change the limit after the launch of trickled, but its man page says :
    > tricklectl is a control utility that lets you query and modify the current state of a trickled bandwidth shaper daemon. This way you can for example change up- and download rates. In the moment tricklectl is of no use, but we hope to have it ready soon!

    Wait & see :)

  5. Cameron Dale Says:

    The idea of trickle is great, but my experience with it has not been good. Though I haven’t tried it recently, I found it completely useless for limiting BitTorrent downloads. Since it hasn’t been updated since 2003, I assume this is still the case.

  6. Fabio Ornellas Says:

    Very good choice against kernel level traffic shaping. I have tried that myself and can say it is too much work for a desktop (even for a router sometimes…).

    I believe a better result could be achieved by using some hooks over systrace or similar tool. In theory, it would work even with static binaries or UDP traffic. An IPC could be implemented with the running instance to allow on the fly changes. Of course, all ideas for the future…

    The most important is the concept of this software, that is beyond everything I saw about traffic shaping until now.

  7. Ferry Boender Says:

    I hadn’t tried limiting bittorrent downloads yet, but a quick test shows that trickle is at best mediocre when limiting bittorrent downloads. The speed of a download limited at 20 K/s varies wildly between 6 and 30 K/s. Perhaps the reason can be found in the fact that bittorrent uses many different TCP sockets to different sources at a time.

  8. mvanbaak Says:

    limiting bittorrent can be done in all torrent clients I found in debian. rtorrent can be used to limit the total traffic for all downloads you have running.
    I think this is a better way of doing stuff then trickle :)
    Trickle is nice for some other stuff tho. Thnx for the nice article.

  9. KarlMW Says:

    I use wondershaper (also in Debian) and find it works well for me. It supports changing limits after launching a program (which is one of the key features I needed).

    I use it for traffic shaping at work - my linux box is far better at competing for bandwidth than my boss’s windows box, so he gets no throughput if I don’t make an effort to share :-)

    It’s not userspace though, so not quite the same as trickle.

  10. Ferry Boender Says:

    mvanbaak Says:
    > limiting bittorrent can be done in all torrent clients I found in debian.
    > rtorrent can be used to limit the total traffic for all downloads you have
    > running.

    I use the mainline client (the official one), but there doesn’t seem to be a way to limit the download speed in that one. You can limit the upload speed however, which is more useful in bittorrent. Then again, why would I want to limit torrent downloads? ;-)

  11. Marcel Kraan Says:

    Wow i really need the 64 bit version of trickle… (fedora)

  12. Udi Says:


    And how do I display the amount of bandwidth currently (1 second/1 minute) consumed by different processes?


  13. SEWilco Says:

    Usage info is printed every n seconds by using the ‘-N n’ option. Use ‘-s’ to output to syslog instead of printing to output.

  14. Aurora Says:

    I tried using trickle on Gentoo on a AMD64 but little success. It won’t compile. There is an ebuild available that can be used - it patches the original files. But it seems to have a bug - I could not get it to limit downstream different from upstream. downstream was always limited to the same or less than upstream. Also, the application consumes horrendous percentage of CPU. Is there an alternative to this more than 5 year old program?

  15. Al Says:

    > I tried using trickle on Gentoo on a AMD64 but little success

    This blog is dedicated to Debian / Ubuntu. Try to ask Gentoo community, it will be more helpful.

  16. airtonix Says:

    doesn’t affect firefox’s bandwidth usage.

  17. airtonix Says:

    also i ran trickled with the above tests…doesnt affect any bandwidth usage unless i use the trickle instead of trickled.