While I had a long love affair with BitComet as my prefered BitTorrent client, it happens that I currently prefer to use the lean and clean uTorrent software. It is a bit smaller (but it has a tendency to eat up memory if left serving files for a long time -it’s ok if you stick to downloading) and it has a nice little interface that is clean and easily understandable.
As with many a BitTorrent client, µTorrent or uTorrent tends to have a relatively complex configuration. Many options, some of them utterly cryptic, a lot of them with a possible impact on performance. After months of tweaking, I think that I have obtained a configuration that is clearly optimized to download several giga-byte-sized packages (videos/movies, Linux distributions, full databases, etc.) on a fast ADSL connection (20Mbit/s, here).
So I was suggested to share it with all the ones who want to try and get quickly a BitTorrent connection working as fast as possible.
All the options
I don’t need to explain the choice of language (µTorrent has one great advantage of having such a large choice for localization).
I did not install IPv6 support (my ISP does not support it), but it is a very critical item to check because -as soon as it becomes readily available- it will bring a significant layer of compression and obfuscation to avoid your ISP throttling down your P2P traffic (as some US and Canada ISPs currently do; Shame on them!).
I don’t care receiving the beta upgrades (I’m all for the stability of software) and I favor browsing as anonymously as reasonably possible.
Since I am working at home, there is no need for the anti-boss key.
Download: I prefer to immediately pre-allocate file size (rather than seeing the software program stop later because it has been eating up all disk space), and I don’t want to the PC to shut itslef down while downloading. While it is generally good to reduce electricity consumption, stopping in mid-transfer is not good for the efficiency of the whole process.
We have to admit that display options are mostly a matter of taste. You can see mine, but feel free to choose others to your liking. These should not affect performance except if you decide to not start the downloads automatically (you still can start them manually, though).
If you download a lot of BitTorrent files, it may be worth organizing your downloads. I put everything in a common directory (
C:\Download from Internet\ as you can see) and avoid moving them around (even when finished). However, I prefer to store the torrents themselves in a separate sub-directory (
C:\Download from Internet\Torrents) for an easier management.
In order to make things easy, torrents that are downloaded in the download directory (
C:\Download from Internet\) are first detected, then started, then moved into their own sub-directory (
C:\Download from Internet\Torrents). This means that even if µTorrent is not started, I can download torrent files in the normal download directory, as anything else, but as soon as uTorrent starts, it will recognize the request.
One added little advantage is that if I put any torrent file in this directory (even from a remote machine) P2P download will start automatically. It is easy to setup a script in your email program to drop torrent files from email and thus to have your PC remotely starting downloads. Even from your iPhone, for example. This becomes Remote BitTorrent for iPhone.
The connexion port is allocated randomly in order to avoid issues with your ISP. Just make sure that this port is open in the firewall of your router. For your own computer, using UPnP and NAT-PMP to ensure that you optimize going through your local network and router.
Do not allow changing port at each startup. It would really mess with your router and other firewalls.
If possible, do not use any proxy (it would eat a significant performance and P2P-over-Proxy may not be acceptable by your ISP – read your contract).
This page is certainly the most important one (performance-wise). You may want to allow the automatic speed throttling, but I found that it was good to set it up manually. First, limit the upload to 80-90% of your upload stream capacity (check with your ISP). The little margin allows to have some capacity to do something else (like browsing Roumazeilles.net).
I admit that I limit a little more when I have no download to do, but this is not important here.
The number of connections should be high. Since I have 2GB (and now 4GB) of central memory on WinXP, there is no strict reason to limit myself, other than the fact that going over 1000 connections means that the computer spends more time handling connections than downloading. The ratio of 5:1 or 6:1 between connections and clients helps favor very efficient peers (those bringing most of the download rate).
On the other hand, I don’t want to spend all my bandwidth serving too many P2P clients. 6 is OK. If a couple of them are slow, it’s still possible to speed up on 4. That way, my computer sends data as fast as possible but does not negotiate a lot with others (essentially, it’s “let’s queue them rather than serving them all”).
DHT: You want DHT! This is one great way to find more clients, to keep them if the server is down, to grow the swarm for maximum speed.
Local search may be usable if there are other local users on your LAN (are you in a company? in a University?). It’s not critical for my own home LAN, though.
As far as possible, I want to encrypt my communications. It does not add a lot of invisibility, but it reduces the chances of seeing my ISP filter my traffic.
Here don’t let uTorrent add too many torrents at the same time. Downloading 3, 4, 5, 6 torrents is OK. This tends to max up the connection if they are active, but don’t set it up for more. I prefer to have my torrents arriving one after the other day after day, rather than all after a week of download.
Default values for sharing are OK, I guess.
I do not use planification. Let’s go fast. That’s all.
I do not use the WebUI.
The only Advanced features worth messing are:
Basic parameters for the cache are just that: Basic.
But the advanced parameters could be a little more important.
Growing the read cache size automatically could be an issue if you are near the disk space limit. So, I prefer not to allow this feature (which is only useful in extreme conditions, anyway).
While the Windows write cache seems useless or not efficient, the Windows read cache is important for some disk drives (especially if you are using external USB disk drives).