Control your bandwidth with Trickle

Apps
Ever had one of those situations where you pause for a moment, think back to a time long ago, and say, I wish I knew this back then? Even if you haven't, Trickle will trigger many such memories. With Trickle you can control the upload and download speeds for applications such that no single application hogs all the bandwidth. This gives you the power to ensure that downloads from Firefox don't interfere with your attempts to download a file through FTP.
Shaping bandwidth traffic is one of the mundane tasks of a system administrator, be it in a large corporate setting or a small office. In the present day and age, I doubt there's anyone who hasn't himself experienced, or heard someone they know moan about one of the users on the network hogging all bandwidth.
The need to control bandwidth access for individual users on a network is a no-brainer, but you may ask yourself whether there's any real need to limit the upload or download speeds for individual apps. The answer is yes, but there's more to it than that. You can only truly appreciate Trickle if you've ever encountered situations where one application dominated the traffic making the lives of other apps a nightmare. At different times, due to many different reasons, applications may refuse to play nicely and cooperate.
I'm sure you've heard the tale of the warrior who came across a bridge that was only wide enough for one and on the other side stood another warrior. The only way to decide who goes first was by admitting the other as your superior or by engaging him in a fight and drawing first blood. How the story continues depends on which warrior the storyteller likes more or which warrior favoured Emacs over Vi.
Applications often face this situation too, since the bridge isn't always wide enough for all the applications, and sometimes there are more than two applications that wish to use the bridge. Knowing how to throttle bandwidth available to applications is akin to having a shinier and sharper sword and skills that can be rivalled by none.
Not only that, it pretty much makes your blood transparent, so you can never lose a first blood contest. Plus, it makes the bridge wide enough for everyone. It's a very zen solution, if you look past the lost glory of winning a first blood match. (OK: enough with the warrior metaphor --Ed)

Bandwidth plumbing

Trickle is just a yum install or apt-get install away if you're on a Fedora or Debian/Ubuntu machine. You must have the libevent library, Trickle's only dependency, already installed before you install Trickle. Most modern distribution will already have this installed. If you want, you can also install the celebrated traffic shaper from source with the configure, make and make install trio of commands.
Trickle regulates speeds by delaying the data transferred over a socket. Trickle provides an alternate version of the BSD socket API, with the effect that socket calls are now handled by Trickle. Speed is limited by controlling the amount of the data written or read from a socket. Trickle can only work on TCP connections, so you can't use it to regulate UDP stream connection such as DNS.
Not only that, it can't work with all TCP connections either. Since Trickle uses the dynamic linking and loading, it can only work with applications that use dynamic libraries (Glibc). Statically linked applications are thus not compatible with Trickle. To determine whether or not you can use Trickle to regulate speeds on an application, you can use the ldd command, which will give you a list of all shared libraries. So, if you're wondering whether or not Trickle will work with the Epiphany browser, use the command:
ldd /usr/bin/epiphany | grep libc.so
        libc.so.6 => /lib/libc.so.6 (0x00c14000)
You can similarly test for other applications such as KTorrent, KFTPgrabber etc. As long as you get a result, Trickle can regulate the speeds for those applications. To that end, you can even limit the bandwidth available to the RPM command when installing or querying packages.
Trickle isn't a strong enforcer of limits. When setting speeds, remember it can fluctuate by as much as 5kbps.
Trickle isn't a strong enforcer of limits. When setting speeds, remember it can fluctuate by as much as 5kbps.

It never rains but trickles

When using Trickle, choose appropriate download and upload speeds to limit applications. You don't have to do anything fancy to make Trickle slow your apps down - just use the -d and the -u switches to tell Trickle the respective download and upload speeds you want an application to have access to. For instance, the command
trickle -d 20 wget -c http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm 
...will download the rpm package using Wget and not exceed the 20kbps download speed. Naysayers may please note that while one can control Wget's download speeds with the --limit-rate command option, it's only used here to illustrate my inability to think of a better example.
Along with the -d switch, which is used set download speeds, you can use the -u switch to regulate the upload speed. If setting per-application speeds seems too much of a chore, you can set global speeds with the command
trickled -d 50 -u 10
Remember to put in your own values into the command, because copy/paste is not the best way to go about this. The trickled daemon monitors all connections, so once you've set up trickled, you don't need to bother setting speeds for Wget, FTP, browsers and everything else that uses TCP.
Now that we know how to determine what apps Trickle can dominate, let's try to slow down the bandwidth available to the RPM command. First, let's see if Trickle has any power over it.
[linuxlala@localhost ~]$ ldd /bin/rpm | grep libc.so
        libc.so.6 => /lib/libc.so.6 (0x00c14000)
Suppose you wish to limit the download speed available to RPM to 5kbps. You can do that with the -d switch like so:
trickle -d 5 rpm
You don't need to specify any upload speed limits in this case. Since RPM can be used to install packages from a remote site directly without downloading them first, when you run this:
rpm -ivh http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm
...you'll notice the drop in speed.
If I were you, this is about the time I'd launch a terminal session and find out just how many applications I can regulate with Trickle. Remember, when you fix speeds for one application, like your browser, the allotted bandwidth gets split between all the files you simultaneously download. And I got proof. We'll see what happens to two torrents I tried to download with KTorrent when the bandwidth available was restricted to 20kbps.
If you think setting upload and download speeds is all that Trickle does, you're wrong. This nifty little tool lets you set per-application priority, and you can also define time and length-soothing parameters. Don't let the fancy jargon scare you. With time-smoothing, you can define the time interval for the application to transfer data.
Large values will produce bursts in sending and receiving data while smaller values ensure a smooth and continuous data transfer. You need to use the -t command switch to define the time-smoothing values (in seconds). The default value is 5s. According to the trickled man page, smoothing time of under 1s is ideal for interactive applications and anywhere from 1-10s for applications that transfer large amounts of data. Like smoothing-time, you can also define a smoothing-length with the -l command switch.
You can specify the download limit for Firefox with the -d switch.
You can specify the download limit for Firefox with the -d switch. When you now launch Firefox from your launcher, the speeds will be limited to the values you assigned. Remember to change this value if you want to be able to enjoy YouTube!

Permanent settings

As already mentioned, defining global speeds (setting speed limits for all applications), is done with the trickled command. But what if you need to define custom time- and length-smoothing values for different applications?
To achieve this amazing feat, turn to the /etc/trickled.conf file. In fact, when you run Trickle, it checks to see if the trickled daemon is running and implements the parameters defined in the file for the program it is running. Trickle will override the options defined in the /etc/trickled.conf file if you specify values with the Trickle command.
Each section in the file is demarcated by square brackets. The format of the file is straightforward, but you don't have to believe me. See for yourself:
[service]
Priority = <value>
Time-Smoothing = <value>
Length-Smoothing = <value>
The first thing you might notice in the trickled.conf file is the Priority parameter. Priorities are set relative to other services. A lower value suggest higher priority. What's the point of all this doo-dah you ask? Well, for one, services with a higher priority get more bandwidth than other services. Plus, with priorities, trickled gets its own queue going whereby you can connect to a service even if the bandwidth is maxed out. Here's my copy of the file to show you how this translates in the real world.
[ssh] 
Priority = 1 
Time-Smoothing = 0.1 
Length-Smoothing = 1
[www]
Priority = 2 
Time-Smoothing = 5
Length-Smoothing = 10 
[ftp]
Priority = 8
Here, SSH has the highest priority so that remote sessions aren't slow and the time- and length-smoothing values ensure the same. Nothing upsets people more than slow browsing, so WWW is next in the priority chain. Finally, I don't do much of FTP, so it has the lowest priority, and since I haven't assigned any smoothing values, Trickle will use the default value.

What's the catch?

We've covered everything Trickle can do and I can tell you're impressed. But is this the complete picture? Could this awesome tool, which serves such an obvious need, really have no drawbacks? Unfortunately, no. And its biggest drawback is that it hasn't seen a new release in many years. But that's nothing to worry about, since this is a common trait for many open source projects, where the developer probably can't make the time to work on the to-do list.
My biggest concern with Trickle is that it can't dynamically adjust set speeds. So, if you set the upload rates at 20kbps for Firefox, but later decide to increase or decrease it, you will have to close Firefox, reset the speeds and then launch Firefox. And not just Firefox: Trickle doesn't allow dynamic speed adjustments at all. This feature has been on the to-do list for some time and it's also listed under Section 6 of the published paper athttp://monkey.org/~marius/trickle/trickle.pdf.
Depending on your requirements and what you do, you might also want to investigate how Trickle works with something like VNC Viewer. As with the ldd command described above, Trickle can play ball with VNC Viewer. Consider this an assignment and get cracking.
Another problem with Trickle is that it doesn't work too well with some applications. Since I primarily use the Gnome desktop environment on my Fedora machine, I also had the Transmission BitTorrent client installed, apart from KTorrent, which works well with Trickle. Like KTorrent, Transmission too internally allows limiting the download/upload rates per torrent.
When you set the download speed for Transmisson with Trickle, it works flawlessly. However, when you set an upload limit, the download speed also drops. For example, if you set the upload speed to 10kbps, the download speed will never go beyond 10kbps. To set speeds from within Transmission, select the torrent from the list, and click the Torrent Info button. You can now set upload and download speeds from the Options tab.

A lone ranger?

Not hardly! There are many bandwidth shapers, each with its own feature set and quirks. Wondershaper is just one such tool. Like Trickle, it too appeals to the Bashful types, being a command-line utility and all that. Unless you're on a network, or have multiple NICs, Wondershaper probably isn't right for you. It's advantage lies in its ability to limit per NIC traffic.
So, if you wish to limit the download and upload speeds for eth2 use the command: wondershaper eth2 downspeed upspeed Unlike Trickle, where the settings are lost once you close the terminal (only if you launched the app with the trickle -d command), to disable traffic shaping, use wondershaper clear [network interface]. In this case, you'd have to specify eth2.
Wondershaper is available in the software repositories for Ubuntu and Debian. Other distro users will have to download the compressed tarball and extract the wshaper script from within.
Because of its ability to control traffic transfer per NIC, Wondershaper has inspired many other bandwidth shapers. Most of them, like Trickle and Wondershaper haven't seen a new release in years, but they each have a faithful user base.

Trickling KTorrent downloads

Launch KTorrent
Launch KTorrent: You can launch KTorrent from the Applications > Internet menu or from a terminal with the KTorrent command. Depending on how you launch it, you need to set speeds before you do. You can also set an alias for KTorrent if you don't wish to set the speeds each time you launch KTorrent.
Set torrent speed
Set torrent speed: If you have multiple torrents in the download queue, the bandwidth available gets split between them. In my experience, most of the time, one of the torrents stalls while the other hogs all the bandwidth. Every few minutes, for barely a few seconds, the bandwidth got split almost equally.
Download limits
Download limits: With KTorrent, you can define maximum upload/download speeds per torrent. If you restrict one torrent to less than the bandwidth set by Trickle, the other torrent takes over the leftovers. When you add a new torrent, it will get less than 1kbps speeds for a few minutes before the other torrents start to share.
You should follow us on Identi.ca or Twitter
 

Your comments

Skype?

How about limiting Skype?
I hear it doesn't support UDP :(

This site is amazing. There

This site is amazing. There really is a truckload of technical information on here you'll never find anywhere else. Thats all I have to say.

@Zac Ball

Apart from in last months magazine :)

RE: Skype?

It is not possible to limit UDP traffic. This is not a limitation of the software but a (intentional) limitation of the protocol itself.
Excellent article!

Big ups for this tute

Nice plain how-to, yet with plenty detail anticipating most questions.
Thanks so much

Great for web developers to test local websites

I use this to limit my web browser speed when testing websites on my server. That lets me see how the site will actually load from the web (not including latency) instead of opening instantly since it's on a gigabit lan.

Comment viewing options

 
 
 
Select your preferred way to display the comments and click "Save settings" to activate your changes.
Username:    Password:  


Comentarios

Entradas populares de este blog

Tutorial Configuración MPC-HC

TSMC