Slashdot Mirror
BitTorrent Clients Reviewed
prostoalex writes "PC Magazine is running a review of several popular BitTorrent clients. They review uTorrent, an app that 'packs an outstanding array of features in 107KB, and doesn't even create a folder in your Program Files' and give it 4.5 stars. BitTorrent Client from BitTorrent.com, 'whose clean interface has three basic elements: a large progress bar for each torrent you're working on, a slider that controls your maximum upload rate, and a link to the BitTorrent Search engine', gets 4 stars. BitPump 'features an attractive interface that sacrifices a detailed feature set for BitTorrent tweakers in favor of simplicity and ease of use' and gets 4 stars. Finally, Azureus, 'a favorite with advanced users, who enjoy its plug-in system and huge range of tweakable settings', gets 4.5 stars. An interview with Bram Cohen from BitTorrent is available as well."
Azureus, because my downloads matter. And, it works on a Mac. Plus, it has plug ins such as SafePeer to keep those pesky people away.....
It's either on the beat or off the beat, it's that easy.
I moderate therefore I rule!
--
I've used ABC; how does that hold up?
This app shows why platform-optimized code will _always_ beat generic XP frameworks (Java/Python). There is no earthly reason a BitTorrent client has to be big and slow. I like Azureus (especially its DHT) but it drags my machine down compared to uTorrent (which you don't even feel is running). If uTorrent supported Azureus' DHT instead of mainline-DHT I know I wouldn't use Azureus at all.
[1.1GHz Pentium M with 512MB RAM, yes I know that's not a lot but I'd still like to be doing other things when my BT client is running.]
Go somewhere random
but it seems it takes up a lot of CPU even if I'm only downloading one torrent. So instead I switched to ABC, which seems good enough for now.
Though I might definitely give some of the other ones in the list a go.
'For we walk by faith, not by sight.' II Corinthians 5:7
I know Shareaza isn't the absolute greatest bittorrent client out there... but it seems to work fine for me, and the fact that it's also a Gnutella2 and eDonkey client makes it just too damn good for getting all those 'latest and greatest' BitTorrent things, as well as those hard to find things you only get via other P2P networks.
:)
:P
Plus... if your tracker goes down it looks for alternat Gnutella2 sources... sweet.
Oh... and it's open source... that's good... right?
Define "good". BitComet is banned at a wide variety of private trackers for doing dodgy things (the authors don't believe in private trackers so use DHT for all torrents until the newest version which got it banned), and it also known as a leeching client (in that it cheats the protocol to get better speeds). uTorrent has stolen most of it's features, and is smaller and faster... and generally better in every single way.
I actually use screen + launchmany-curses.py. Drop the torrent files in one directory and pick up the downloads in a second directory after a while.
The article claims that the official BitTorrent client, written in Python, requires the Java 1.5 runtime.
I have to state that I strongly disagree with one of the comments at the end from Brahm Cohen. I mean, MS Avalanche is vaporware, but that doesn't mean that use of FEC (forward error correction) is a bad idea. Granted it would increase local storage requirements when seeding, but there would be almost no impact on network bandwidth and the CPU overhead is negligible. Personally, I'd be more than happy to sacrifice say a 10% increase in local size to ensure that I get a complete copy of the torrent. I've found numerous torrents that died out somewhere between 90 - 100%; And the worst is when you have a wasted download because you're missing only a fraction of a percent.
Personally, I would like to see a combination of the BitTorrent "send the least common block" approach and a selectable Reed-Solomon coding defaulting to around 10%. In my empirical experience that would clear up almost every failed torrent I've hit. Of course, it is an extendable protocol. Perhaps I should stop bitching and look into writing an Azureus plug-in to test this idea out.
I find btlaunchmanycurses better than btdownloadcurses, as I can run several torrents and see them all at once~ I too have no idea why this was marked funny...
I mod down anyone who says "I will be modded down for this", regardless of the rest of their comment
Transmission is a bare-bones, ground-up rewrite in C and has really impressive performance. I use this as my default.
If Jesus wants me it knows where to find me.
I've been a keen BT user for years now and rave on about it to friends when asked where I get some of my stuff from. Inevitably they're interested and go off and try it and I'll even send them a torrent file to get them started. However what happens next is that they complain of slow speeds or no seeds on torrents which I know are flowing well. The reason for this is always the same: port forwarding and not entering their external IP address (for some set-ups). As soon as I say, 'You'll have to edit your modem/router configuration slightly to get it to work' they'll throw their hands up in horror and there ends their great BT experiment. It doesn't help that some wireless systems move the internal IP assignment around via DHCP requiring port 6881 to be re-pointed again. That sort of stuff is simply beyond most regular users and they 'just don't go there'.
So for me, the issue is not clients (I use BitTorrent for OSX very happily as if it mattered) but the way the protocol handles NAT/DHCP routing - surely it could be automatic? If it were BT use would explode and we'll all get faster speeds as a benefit. Anyone know if that could happen one day?
spoonerize "magic trackpad"
I've switched to uTorrent after being a longtime Azureus fan, because you can not have Azureus running while also playing any recent video game. It's a real memory and CPU hog.
uTorrent by contrast takes virtually no CPU, no RAM, and for that matter only ~110k of disk space. And it has about 99% of the useful features of Azureus. Only really miss a couple of things, like the "swarm" tab -- and that's just for fun really.
Running Azureus and HL2 at the same time would render the game virtually unplayable for me. uTorrent, on the other hand, doesn't even make a dent in the FPS. In fact I play DOD:Source all the time and forget to kill uTorrent first - and I've never seen a problem in either FPS or lag as a result.
Fact: Azureus is a CPU and RAM hog. Now granted, give it enough CPU and RAM to work with and obviously you won't notice an impact on system performance. OTOH, try to play any recent 3d game while Azureus is busy, on virtually any system -- you'll find it quickly becomes untenable.
.. some recent changes to uTorrent (latest betas, http://utorrent.com/download/beta/) seem to have rocketed it WAY ahead of the pack in actual transfer completion times. Maybe it's just me, but I'm seeing 5-10x faster overall time for torrents to complete. This appears to have nothing to do with peak bandwidth and everything to do with how quickly uTorrent can connect to peers and begin downloading.
uTorrent does ~99% of what Azureus does, but somehow manages to do it all in a 110k binary, while having virtually no RAM or CPU footprint. (I'm downloading multiple torrents with it just now -- and it's consuming 0-1% cpu, 4,240 kb RAM in task mgr).
However
With Azureus I'm accustomed to 10-30 seconds for each peer to establish connection, and another ~10 seconds in the best case to begin actual data transfer. In contrast, with the latest uTorrent beta, I am seeing connections establish in 1-2 seconds, and data begin transferring roughly 1 second after that. The result appears to be that, while my peak transfer rate is about the same as before, uTorrent is managing to keep the average transfer rate consistently high throughout the download. This makes sense, since BT is all about connecting to and switching between peers constantly as it distributes the traffic load. If you've got a relay race going and all the runners are the same speed, but one team takes an extra 30 seconds at each handoff of the baton, you know who's coming in first.
I'd be interested in hearing if anyone else is seeing this kind of dramatic improvement.
http://utorrent.com/download/beta/
And yes, I am making a moral case for using bittorrent. I don't believe in copyright, or intellectual property of any kind, and I'm sure a number of people share this view. Bittorrent helps everyone, by giving them whatever infomation they want-unregulated by others. You benefit from it, and so does everyone else.
Well, everyone benefits except for the people who own the copyright - you've run roughshod over them. They don't count, though, they only created the entertainment you believe should be free. Fuck them!
Slashdot - where whining about luck is the new way to make the world you want.
But doesn't load half the files of the computer into ram when it starts.
uTorrent takes 5Mb of RAM estate running full speed with 20+ torrents loaded in... BitTornado, using wxPython, hogs 25Mb/instance (== 25Mb/torrent, for it launches an instance per file) and a well loaded azureus will "optimize" at least 150Mb of your ram...
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
Thanks AC, I didn't know that.
r rent_show_less_DHT_peers_in_the_status_bar_than_Bi tComet_Azureus.3F
http://www.utorrent.com/faq.php#Why_does_.C2.B5To
[Fuck Beta]
o0t!
Beat that.
Err... no. I've had Azureus running under XP for a week, downloading 10+GB of stuff, and uploading near the same. CPU time? 1h 2m. Memory usage: 73MB at the moment.