comparing bittorrent clients

dninja · 2010-05-04 23:22:19

Apart from the nice GUI with pretty pictures I'm wondering what the difference is between Vuze and the original command line bittorrent client is. Does Vuze do any kind of special handling of torrents for faster download or anything else that would improve performance over the command line version?

I'm wondering because I have a headless box that I was thinking of putting the command line version on but would like to know if I'd take a performance hit by going from Vuze.

Any comments?

ajonat · 2010-05-05 00:42:55

Have you tried deluge? It has a command-line client and a web frontend, so you should be able to manage torrents from another computer with your browser or by ssh'ing into the box (using screen).

Last edited by ajonat (2010-05-05 00:44:39)

Wintervenom · 2010-05-05 00:57:42

dninja wrote:

Apart from the nice GUI with pretty pictures I'm wondering what the difference is between Vuze and the original command line bittorrent client is. Does Vuze do any kind of special handling of torrents for faster download or anything else that would improve performance over the command line version?
I'm wondering because I have a headless box that I was thinking of putting the command line version on but would like to know if I'd take a performance hit by going from Vuze.
Any comments?

Only if you are using Vuze's plug-ins to do so.

Last edited by Wintervenom (2010-05-05 00:58:06)

splittercode · 2010-05-05 01:33:28

Vuze is one of the more bloated programs I've ever used... I despise it. I highly suggest rTorrent if you're looking for something cli oriented. You can see in the LnF 2010 thread that a ton of archers use it. I've experienced no speed difference between it and vuze or deluge, but it uses like 5x less memory.

.:B:. · 2010-05-05 07:20:49

I wouldn't pick Vuze if I were you, unless you value UI over features and quality (and their GUI is what you're looking for).

kevku · 2010-05-05 08:08:43

.....
you can use the old azureus ui in vuze so I don't understand why people are still bitching about the ui. For me vuze is the most feature-complete bt client out there.

teh · 2010-05-05 08:28:04

rtorrent

kokoko3k · 2010-05-05 08:31:17

http://en.wikipedia.org/wiki/Comparison … nt_clients
Ktorrent is the most complete.

tomk · 2010-05-05 09:00:51

If your target machine is headless, I don't understand why you're even considering Vuze.

mikesd · 2010-05-05 09:37:29

tomk wrote:

If your target machine is headless, I don't understand why you're even considering Vuze.

For a headless box you can't beat screen and rtorrent.

Foucault · 2010-05-05 10:02:56

Although Azureus was one of the very first bittorrent clients it is ridiculously heavy for a program that its main purpose is to stay in the background and download. For a headless machine the safest bet would be Deluge or rtorrent. Deluge comes with a nice full-featured web frontend but you can't do much with its cli/curses interface. If you prefer cli, then rtorrent would be better, although there are some nice web frontends for rtorrent as well (such as rutorrent).

dninja · 2010-05-05 23:00:57

Putting features aside I think Wintervenom is the only person to answer my question. I don't care about interfaces, I'm perfectly happy with either CLI or GUI and I've enough processor and RAM to ignore bloat. What I want to know is do any of the different apps add any speed improvements or are they all the same under the hood when it comes to actually pulling down files.

My choice is either keep the app on my desktop or farm it off the the headless box. If they are both going to be the same speed then I'll farm it off, if Vuze (or any of the others) does some amazing stuff to make it download files twice as fast then I'll use that.

undefined · 2010-05-08 19:19:29

I don't think any client can increase the speed of download, but if your using DHT or Peer Exchange(PEX) in that case a client with a strong user base can affect the number of seeds for a torrent.

JohannesSM64 · 2010-05-08 19:45:23

Hey, what about btpd? It doesn't have fancy features, but if you don't need that, it's great.
edit: Ah, you were only asking about speed. Well, I don't know the differences, but btpd is fast here.

Last edited by JohannesSM64 (2010-05-08 19:52:26)

.:B:. · 2010-05-08 19:59:45

I am at loss why you inquire about possible performance impact, then state people disregard your question entirely, and finally dismiss suggestions by stating your hardware is powerful enough to handle the 'bloat' if it needs to. If you ask about taking a performance hit moving from Y to Z (or even Y'), it's only logical people will come up with alternatives. Somehow it seems you already made up your mind before you opened the topic...

As for your speed question: All clients work with the same protocol. Maybe some will be more efficient when it comes to overhead (I've seen rtorrent eat far more RAM on the same amount of torrents as e.g. transmission-gtk), but they'll all do the same thing, and generally they'll have to do it in the same way - they'll have to comply with what the protocol defines. Some torrent clients are less strict than others, but those won't really gain you any speed bumps at all - you'll merely have more chance to be blacklisted because of your client (especially closed sites work that way). You can fiddle with settings but the download speeds depend on your peers, not on your client - and on the fact whether you can be connected to or not, of course.

Apart from the obvious GUI complaints lots of users here have about Vuze, there have been quite a few complaints about how Vuze behaves in a torrent swarm - I know of at least one big site having it banned because of that. Generally such sites are very concerned with e.g. server load and client-side statistics, so they don't tend to do such things overnight.

dninja · 2010-05-08 21:40:47

.:B:. wrote:

I am at loss why you inquire about possible performance impact, then state people disregard your question entirely, and finally dismiss suggestions by stating your hardware is powerful enough to handle the 'bloat' if it needs to. If you ask about taking a performance hit moving from Y to Z (or even Y'), it's only logical people will come up with alternatives. Somehow it seems you already made up your mind before you opened the topic...

When I was asking about performance I was referring to the statement about download speed not about application performance on the machine. Your answer below is really what I was looking for, giving me the answer that regardless of what client I use the transfer speeds are likely to stay the same. Given that then I'll happily go with a CLI app that will run on my headless box. If you had said that Vuze (for example) did some funky stuff to somehow double the speed of downloads then I'd have ignored the CLI app and stuck to Vuze.

As for your speed question: All clients work with the same protocol. Maybe some will be more efficient when it comes to overhead (I've seen rtorrent eat far more RAM on the same amount of torrents as e.g. transmission-gtk), but they'll all do the same thing, and generally they'll have to do it in the same way - they'll have to comply with what the protocol defines. Some torrent clients are less strict than others, but those won't really gain you any speed bumps at all - you'll merely have more chance to be blacklisted because of your client (especially closed sites work that way). You can fiddle with settings but the download speeds depend on your peers, not on your client - and on the fact whether you can be connected to or not, of course.
Apart from the obvious GUI complaints lots of users here have about Vuze, there have been quite a few complaints about how Vuze behaves in a torrent swarm - I know of at least one big site having it banned because of that. Generally such sites are very concerned with e.g. server load and client-side statistics, so they don't tend to do such things overnight.

stqn · 2010-05-08 21:54:45

BitTyrant is supposed to improve download speed...

gazj · 2010-05-08 22:36:25

setup transmission on your headless machine, then use transmission-remote (from the transmission-cli package) to control it, works a charm for me

ekenbrand · 2010-08-02 22:28:35

utorrent + wine, unbeatable

forgot to say that is not open source

Last edited by ekenbrand (2010-08-02 22:29:19)

jack.mitchell · 2010-08-03 13:58:40

Deluge. Run it as a daemon and connect to it remotly using the official deluge client or the web interface. However the current (1.2.x) web client is dog slow with over a dozen torrents, 1.3.0rc has improved this vastly and is much much quicker but seeing as it is RC then it is not yet in the official repositories, and they've had it as rc for months upon months now Also the 1.3 in aur is built differently to the 1.2.x in the official repositories so I can't easily replace it. However, I would still say it beats all the others hands down in terms of features and usability (taking into account speed and reliability).

Last edited by jack.mitchell (2010-08-03 13:59:44)

cs_student · 2010-08-04 20:49:43

If you are going to be using a gui, I would suggest ktorrent over vuze.

However, since you have a headless computer, if it is running apache && mysql, I would look into torrentflux. It is a webUI frontend for bitornado. It works well, and makes it very easy to torrent remotely (which is great if you live in a college dorm like me). It's really useful for pira... erm, sharing... at work, school, etc. Also, it allows you to have multiple users. This is very handy if you and your friends have similar taste. I can browse the items my friends have torrented and download them myself if I find they got something I want.

If you don't want to share with friends, then rtorrent + ssh + screen is amazing.

Last edited by cs_student (2010-08-04 20:51:04)

otterfox · 2010-08-05 09:08:53

I'm pretty sure that no-one who who's even thought about which bit torrent client they're using uses vuze.
I've tried rtorrent, deluge and transmission on linux.
-rtorrent takes a bit of learning and it's not so great for sharing with friends unless you're going to give them all shell accounts and let them use it. But if you do use rtorrent you'll probably look at using screen with it...I'd go with byobu (in AUR) which uses screen but adds user friendliness to it making it 10 times easier to use (controlled with f-keys rather than arcane ctrl+* commands).
-I used to use deluge (recently) because I rather like python as a language. It was pretty nice, but I could never find the documentation and at took me a few mins of googling to find the docs every time. I used the webui but I had a problem with it loading firefox to 100%, what made me change was when it locked up at 100% CPU once a day, so I had to change before I went away for a week.
-I ended up changing to transmission, because transmission 2 had just come out. Transmission is really nice (and lightweight), my only complaint is that the webui doesn't offer SSL unless you proxy it through your own web server.

Square · 2010-08-06 07:45:17

I personally use aria2 for downloading torrents. It's as simple as it gets and handles all kinds of downloads.

Convergence · 2010-09-12 07:32:54

I've had download speeds of over 2 megabits per second with rtorrent (haven't actually tried to go faster). I might be wrong about this, but it seems to me that if a client is very bloated, it might actually slow down transfer speeds. If the system is bogged down (even a screamingly fast system) by a bloated UI, then it might actually take slightly longer to perform the real work of the protocol.

I think that it would be possible to use it in a multiuser setting as well. I remember seeing a setting in the documentation that causes rtorrent to automatically download a file if a torrent appears in a "watch" directory. You can also tell rtorrent to stop once the file has been downloaded, and you've shared the file to a certain percentage. Therefore, if you had a directory that was writable by all users, and had rtorrent watch that dir, anyone could download a torrent file to that directory and have it automatically be downloaded. It would automatically stop as well, so you wouldn't have to seed for eternity. rtorrent uses less than 1% of my (very old) cpu, which is nice.

Arch Linux

#1 2010-05-04 23:22:19

comparing bittorrent clients

#2 2010-05-05 00:42:55

Re: comparing bittorrent clients

#3 2010-05-05 00:57:42

Re: comparing bittorrent clients

#4 2010-05-05 01:33:28

Re: comparing bittorrent clients

#5 2010-05-05 07:20:49

Re: comparing bittorrent clients

#6 2010-05-05 08:08:43

Re: comparing bittorrent clients

#7 2010-05-05 08:28:04

Re: comparing bittorrent clients

#8 2010-05-05 08:31:17

Re: comparing bittorrent clients

#9 2010-05-05 09:00:51

Re: comparing bittorrent clients

#10 2010-05-05 09:37:29

Re: comparing bittorrent clients

#11 2010-05-05 10:02:56

Re: comparing bittorrent clients

#12 2010-05-05 23:00:57

Re: comparing bittorrent clients

#13 2010-05-08 19:19:29

Re: comparing bittorrent clients

#14 2010-05-08 19:45:23

Re: comparing bittorrent clients

#15 2010-05-08 19:59:45

Re: comparing bittorrent clients

#16 2010-05-08 21:40:47

Re: comparing bittorrent clients

#17 2010-05-08 21:54:45

Re: comparing bittorrent clients

#18 2010-05-08 22:36:25

Re: comparing bittorrent clients

#19 2010-08-02 22:28:35

Re: comparing bittorrent clients

#20 2010-08-03 13:58:40

Re: comparing bittorrent clients

#21 2010-08-04 20:49:43

Re: comparing bittorrent clients

#22 2010-08-05 09:08:53

Re: comparing bittorrent clients

#23 2010-08-06 07:45:17

Re: comparing bittorrent clients

#24 2010-09-12 07:32:54

Re: comparing bittorrent clients

Board footer