Discussion Forums > Technology
best remote bitorrent client?
kitamesume:
if only you were using windows... you could practically pilot your server's GUI from another PC through the net =P what was it called again? remote management?
kureshii:
--- Quote from: kitamesume on October 28, 2011, 08:40:55 AM ---if only you were using windows... you could practically pilot your server's GUI from another PC through the net =P what was it called again? remote management?
--- End quote ---
Linux has RDP servers as well, and has had them for a number of years. And before that we had VNC, not to mention X over SSH.
Still, it is a poor solution for laggy/slower connections, and generally a waste of bandwidth when you don't require a full GUI. a web UI or console-GUI solution is much more bandwidth-efficient.
@OP:
I've had pretty good success with ruTorrent+rtorrent; you can try that as recommended by zetskee, or try transmission/deluge. Try a few different setups, see which you like best.
jackoneill:
Transmission has a daemon, a web ui, and a qt client that can serve as a regular torrent client or it can connect to any local or remote transmission daemon. There is also an official cli client (not interactive) and a number of unofficial console clients (ncurses and whatnot).
http://www.transmissionbt.com/resources/
per:
Both transmission and rtorrent does not really scale all that well when you have a non-insignificant amount of active torrents.
rtorrent, at least 1+ years ago when I tried, seems to assume that disk reads are basically instant, and does not queue them very well either, which really helps when you have a multi-disk raid.
it went to 100% CPU when sharing to a low-thousand number of peers, almost all time spent in kernel (select, it seems that they are not using epoll). And since the disk is mmapped as memory, accesses to it is blocking. So in essence only one read is done at once.
The again, I guess they work just fine for "normal" amounts of torrents (and bandwidth) even if they are inefficient.
I never got transmission running correctly with my torrent list at all.
kureshii:
--- Quote from: per on October 28, 2011, 11:23:42 AM ---it went to 100% CPU when sharing to a low-thousand number of peers, almost all time spent in kernel (select, it seems that they are not using epoll). And since the disk is mmapped as memory, accesses to it is blocking. So in essence only one read is done at once.
--- End quote ---
Check the MaxMultSec setting in hdparm for each disk in the array. Once I enabled it I got much better mdraid performance and rtorrent read/writes (when running other concurrent disk i/o stuff). I haven't tested this with a not-insignificant number of torrents though.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version