How I Manage Bandwidth Using Trickle on Ubuntu

How I Manage Bandwidth Using Trickle on Ubuntu

A practical guide to managing per-application bandwidth on Ubuntu using Trickle — covering installation, upload and download rate limiting, persistent configuration with trickled, daemon mode, and real-world use cases for shared connections.

· How-To
Tested on: Ubuntu 10.04 LTSUbuntu 11.10Ubuntu 12.04 LTS

Shared internet connections in 2012 were a constant negotiation. One person starts a large download, and suddenly everyone else on the network is crawling. Bandwidth caps were common on residential connections — 5 Mbps down, 512 Kbps up was considered decent in many areas — and a single apt-get dist-upgrade or ISO download could saturate the link for an hour. Trickle was the elegant, lightweight solution I used to manage this on Ubuntu. It is a userspace bandwidth shaper that lets you set per-application upload and download limits without touching iptables, traffic control, or any kernel-level networking configuration. Wrap any command with trickle and specify the rates — that is it. This guide covers installing Trickle, using it for one-off rate limiting, setting up the trickled daemon for persistent policies, and the real-world scenarios where it saved my sanity on shared connections. I used Trickle daily on Ubuntu 10.04 through 12.04 on a home connection shared between four machines, and it was indispensable. For related command-line essentials, see our CLI Basics guide.

Terminal showing trickle limiting wget download speed on Ubuntu

How Trickle Works

Trickle operates entirely in userspace. It uses the LD_PRELOAD mechanism to intercept an application’s socket system calls (specifically send(), recv(), read(), write() on network sockets) and inserts delays to enforce the specified bandwidth limits. The application itself has no idea it is being throttled — it simply experiences slower network I/O, as if the connection itself were slower.

This approach has several advantages:

  • No root required for basic use
  • No kernel modules or iptables rules
  • Per-application granularity — limit one process without affecting others
  • Trivial to use — just prefix your command with trickle

And some limitations:

  • Cannot limit already-running processes — must be applied at launch time
  • Does not work with statically linked binaries — the LD_PRELOAD trick only works with dynamically linked applications
  • Does not handle UDP well — Trickle is designed for TCP traffic

Step-by-Step Installation

Step 1: Install Trickle

Trickle is available in the Ubuntu repositories:

sudo apt-get install trickle

That is it. No configuration files to edit, no daemons to start. Trickle is ready to use immediately.

Step 2: Basic Usage — Limiting a Single Application

The syntax is straightforward:

trickle -d <download_rate> -u <upload_rate> <command>

Rates are specified in KB/s (kilobytes per second). For example, to limit wget to 100 KB/s download:

trickle -d 100 wget http://releases.ubuntu.com/12.04/ubuntu-12.04-desktop-i386.iso

To limit both upload and download for an apt-get operation:

trickle -d 200 -u 50 sudo apt-get dist-upgrade

This lets the upgrade proceed at a maximum of 200 KB/s download and 50 KB/s upload, leaving the rest of your bandwidth available for web browsing, email, and other tasks.

Step 3: Rate Limiting a GUI Application

Trickle works with GUI applications too. Launch Firefox with a 500 KB/s download limit:

trickle -d 500 firefox &

Or limit a file transfer in Nautilus by launching it through trickle:

trickle -d 300 -u 100 nautilus &

Step 4: Using trickled for Persistent Bandwidth Policies

For ongoing bandwidth management across multiple applications, use the trickled daemon:

sudo trickled -d 500 -u 100

This starts the daemon with a total bandwidth pool of 500 KB/s download and 100 KB/s upload. Any application subsequently launched with trickle (without specifying rates) will share this pool:

trickle wget http://example.com/large-file.iso &
trickle apt-get update &

Both processes share the 500 KB/s download pool. If wget is actively downloading, apt-get gets whatever bandwidth wget is not using, and vice versa.

Step 5: Configuring trickled with a Configuration File

For persistent settings, create /etc/trickled.conf:

sudo nano /etc/trickled.conf

Example configuration:

[service]
Priority = 1
Time-Smoothing = 0.1
Length-Smoothing = 2

[rate]
Download = 500
Upload = 100

Start trickled with the configuration file:

sudo trickled -f /etc/trickled.conf

trickled configuration file open in nano showing rate limits

Real-World Scenarios

Scenario 1: Background Downloads on a Shared Connection

You need to download a 700 MB Ubuntu ISO, but your housemate is on a video call. Limit the download to leave them plenty of headroom:

trickle -d 150 wget http://releases.ubuntu.com/12.04/ubuntu-12.04-desktop-i386.iso

On a 5 Mbps (≈625 KB/s) connection, this consumes about 24% of the available bandwidth. The download takes longer, but the video call is not affected.

System updates on Ubuntu could easily saturate a slow connection:

trickle -d 200 -u 30 sudo apt-get dist-upgrade

The update runs in the background at a controlled rate.

Scenario 3: Testing Application Behaviour on Slow Connections

Developers sometimes need to test how an application behaves on a slow connection. Trickle simulates this without modifying network settings:

trickle -d 10 -u 5 ./my-application

This limits the application to 10 KB/s download and 5 KB/s upload — roughly equivalent to a very poor mobile connection.

Scenario 4: Limiting rsync Backup Bandwidth

If you run rsync backups to a remote server and do not want them to consume all available upload bandwidth:

trickle -u 100 rsync -avz /home/user/documents/ user@backup-server:/backups/

Note that rsync also has its own --bwlimit flag, but Trickle provides a uniform approach across all tools.

Common Pitfalls

Trickle has no effect on the application. If the application is statically linked, Trickle’s LD_PRELOAD interception does not work. Check with ldd /path/to/binary — if it says “not a dynamic executable,” Trickle cannot control it. Most standard Ubuntu applications are dynamically linked, but some third-party binaries (especially Go and Rust programs) may be static.

Rate limit seems inaccurate. Trickle uses a time-smoothing algorithm to enforce rates over short time windows. During burst periods (the first few seconds of a transfer), the actual rate may briefly exceed the limit before settling to the configured value. The Time-Smoothing parameter in trickled.conf controls this behaviour — lower values enforce limits more strictly but may cause stuttering in interactive applications.

sudo commands do not respect trickle. When you run trickle sudo apt-get update, the LD_PRELOAD environment variable may be stripped by sudo’s security policy. Use sudo trickle apt-get update instead (run trickle under sudo, not the other way around), or configure sudo to preserve LD_PRELOAD by editing /etc/sudoers — though this has security implications.

trickled daemon conflicts with standalone trickle. If trickled is running and you also specify rates with standalone trickle -d 100, the standalone rates take precedence for that process, but it still consumes from the trickled pool. To avoid confusion, either use trickled exclusively (launching applications with bare trickle to join the pool) or use standalone trickle -d/-u commands without the daemon.

Trickle does not limit DNS lookups. DNS queries use UDP and are typically not intercepted by Trickle. On very slow connections, DNS resolution itself can add noticeable delay. This is not a Trickle limitation per se — the DNS traffic volume is negligible compared to application data.

Terminal showing multiple trickle-limited processes sharing bandwidth through trickled

Why Trickle Still Has a Place

Traffic shaping has moved into more sophisticated territory — systemd cgroups, network namespaces, tc with htb queuing disciplines — but Trickle’s simplicity remains its strength. For a quick, userspace, no-configuration rate limit on a single command, nothing else is as fast to deploy. Install it, prefix your command, specify the rates, and move on. On modern Ubuntu, Trickle still works exactly as it did in 2012. Some tools do not need to be complicated to be useful.

Frequently Asked Questions

Does Trickle require root access?
No. Trickle works in userspace by preloading a shared library (via LD_PRELOAD) that intercepts socket calls. Any regular user can run trickle to limit their own applications. The trickled daemon, however, requires root if you want to set system-wide bandwidth policies.
Can Trickle limit bandwidth for applications that are already running?
No. Trickle must be invoked before the application starts — it wraps the application at launch time. You cannot attach Trickle to an already-running process. For live bandwidth control of existing processes, you would need a kernel-level solution like tc (traffic control) with cgroups.
Does Trickle work with all applications?
Trickle works with applications that use the standard BSD socket API via dynamically linked libc. It does not work with statically linked binaries or applications that use raw sockets, kernel-level networking, or custom socket implementations. Most common applications (wget, curl, apt-get, Firefox, Chrome) work fine. Some applications using their own DNS resolution or non-standard I/O may behave unexpectedly.
What is the difference between trickle and trickled?
trickle is the standalone command that limits a single application’s bandwidth. trickled is a daemon that runs in the background and enforces bandwidth policies across multiple trickle-wrapped applications simultaneously, distributing the total allowed bandwidth among them. Use trickle for one-off limits, trickled for shared connection management.
Can I use Trickle to prioritise one application over another?
Not directly. Trickle provides flat rate limits, not priority-based scheduling. However, by assigning different rate limits to different applications, you can achieve a similar effect — give your work VPN 80% of available bandwidth and limit background downloads to 20%, for example.