|
FreeBSD General Other questions regarding FreeBSD which do not fit in any of the categories below. |
|
Thread Tools | Display Modes |
|
||||
Quote:
I've been using rtorrent for a few years, I never encountered such behaviour. Quote:
__________________
Fhtagn nagh Yog-Sothoth |
|
||||
Everytime i download torrents at high speed, mouse pointer is twitching (big time), music is twitching.
i'm not sure at what exactly speed it starts, but i know for sure 6000Ks (rtorrent total download speed) download will cause it, not to mention that downloading torrents from local tracker i can get up to 13000+Ks I doubt it's HDD's fault. because i'm writing to SATA150, which almost ain't used by anything else. basically downloading torrents with high speed makes system almost unusable. That's why i was limiting download/upload speed to 2200Ks total Also CPU usage is pretty extreme (i think) check this post http://daemonforums.org/showpost.php...10&postcount=9 Quote:
|
|
|||
I'm using transmission_gtk, and I don't have any problems with it.
I like transmission - it's simple, fast and works fine for me. Also at high speed of download I don't have any problems with CPU usage. I don't like too Java-based torrent clients, and KDE dependent too.
__________________
"I never think of the future. It comes soon enough." - A.E Useful links: FreeBSD Handbook | FreeBSD Developer's Handbook | The Porter's Handbook | PF User's Guide | unix-heaven.org |
|
|||
Comparing the speed of a torrent client is a bit strange.. the technology itself is dependent on the capabilities of the seeds and peers.
I for example, tested the btpd client.. and I can achieve maximum throughput with it.. though, not on every torrent obviously. If you're experiencing speed issues, perhaps you configured the client improperly? |
|
||||
Regarding rtorrent problems:
I never encountered any problems, can you post your ~/.rtorrent.rc? There are some options you can tweak which can significantly improve performance. Also, I never encountered problems with CPU usage, I run rtorrent on a PIII 800/384MB RAM so I definitly would have noticed any.
__________________
UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. |
|
||||
.rtorrent.rc
Code:
# This is an example resource file for rTorrent. Copy to # ~/.rtorrent.rc and enable/modify the options as needed. Remember to # uncomment the options you wish to enable. # Maximum and minimum number of peers to connect to per torrent. #min_peers = 40 #max_peers = 100 # Same as above but for seeding completed torrents (-1 = same as downloading) #min_peers_seed = 10 #max_peers_seed = 50 # Maximum number of simultanious uploads per torrent. #max_uploads = 15 # Global upload and download rate in KiB. "0" for unlimited. download_rate = 2000 upload_rate = 200 # Default directory to save the downloaded torrents. directory = /home/Files/tr/f # Default session directory. Make sure you don't run multiple instance # of rtorrent using the same session directory. Perhaps using a # relative path? session = /home/Files/tr/.session # Watch a directory for new torrents, and stop those that have been # deleted. schedule = watch_directory,5,5,load_start=/home/Files/tr/*.torrent schedule = untied_directory,5,5,stop_untied=/home/Files/tr # Close torrents when diskspace is low. schedule = low_diskspace,5,60,close_low_diskspace=8000M # Stop torrents when reaching upload ratio in percent, # when also reaching total upload in bytes, or when # reaching final upload ratio in percent. # example: stop at ratio 2.0 with at least 200 MB uploaded, or else ratio 20.0 #schedule = ratio,60,60,"stop_on_ratio=200,200M,2000" # The ip address reported to the tracker. #ip = 46.88.15.155 #ip = getlost.fc # The ip address the listening socket and outgoing connections is # bound to. #bind = 127.0.0.1 #bind = rakshasa.no # Port range to use for listening. port_range = 6890-6999 # Start opening ports at a random position within the port range. port_random = yes # Check hash for finished torrents. Might be usefull until the bug is # fixed that causes lack of diskspace not to be properly reported. #check_hash = no # Set whetever the client should try to connect to UDP trackers. use_udp_trackers = yes # Alternative calls to bind and ip that should handle dynamic ip's. #schedule = ip_tick,0,1800,ip=rakshasa #schedule = bind_tick,0,1800,bind=rakshasa # Encryption options, set to none (default) or any combination of the following: # allow_incoming, try_outgoing, require, require_RC4, enable_retry, prefer_plaintext # # The example value allows incoming encrypted connections, starts unencrypted # outgoing connections but retries with encryption if they fail, preferring # plaintext to RC4 encryption after the encrypted handshake # encryption = allow_incoming,enable_retry,prefer_plaintext # Enable DHT support for trackerless torrents or when all trackers are down. # May be set to "disable" (completely disable DHT), "off" (do not start DHT), # "auto" (start and stop DHT as needed), or "on" (start DHT immediately). # The default is "off". For DHT to work, a session directory must be defined. # # dht = auto # UDP port to use for DHT. # # dht_port = 6881 # Enable peer exchange (for torrents not marked private) # peer_exchange = yes # # Do not modify the following parameters unless you know what you're doing. # # Hash read-ahead controls how many MB to request the kernel to read # ahead. If the value is too low the disk may not be fully utilized, # while if too high the kernel might not be able to keep the read # pages in memory thus end up trashing. #hash_read_ahead = 10 # Interval between attempts to check the hash, in milliseconds. #hash_interval = 100 # Number of attempts to check the hash while using the mincore status, # before forcing. Overworked systems might need lower values to get a # decent hash checking rate. #hash_max_tries = 10 I was messing with sysctl flags (basically i was fallowing book FreeBSD 6 Unleashed by Brian Tiemann) sysctl.conf Code:
security.bsd.see_other_uids=0 kern.coredump=0 net.inet.tcp.delayed_ack=0 kern.ipc.maxsockbuf=2097152 kern.ipc.somaxconn=512 kern.maxfiles=65536 kern.maxfilesperproc=32768 net.inet.tcp.sendspace=65535 net.inet.tcp.recvspace=65535 net.inet.udp.recvspace=65535 net.inet.udp.maxdgram=57344 net.local.stream.recvspace=65535 net.local.stream.sendspace=65535 kern.ipc.nmbclusters=65535 vfs.usermount=1 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.inet.ip.random_id=1 Last edited by graudeejs; 22nd November 2008 at 02:32 PM. |
|
||||
net.inet.tcp.delayed_ack: Delay ACK to try and piggyback it onto a data packet
kern.ipc.maxsockbuf: Maximum socket buffer size kern.ipc.somaxconn: Maximum pending socket connection queue size kern.maxfiles: Maximum number of files kern.maxfilesperproc: Maximum files allowed open per process net.inet.tcp.sendspace: Maximum outgoing TCP datagram size net.inet.tcp.recvspace: Maximum incoming TCP datagram size net.inet.udp.recvspace: Maximum space for incoming UDP datagrams net.inet.udp.maxdgram: Maximum outgoing UDP datagram size net.local.stream.recvspace: net.local.stream.sendspace: kern.ipc.nmbclusters: Maximum number of mbuf clusters allowed I will disable and reboot, to see what happens However i doubt it's the reason, because ctorrent was downloading torrents like mad (total 10.1M/s [average speed in last 20s, so they say]), and cpu load was low, and BSD didn't lag. EDIT, didn't yet do it. added Code:
hash_read_ahead = 8 hash_max_tries = 5 hash_interval = 10 and checked again. 1st time FBSD lagged was when rtorrent reached 3.2M/s (it was 300M file, so it cound't get to full speed) then i restarted, and next time it was at about 4M/s at 6M/s Wcpu was 34%, cpu state: 19.2 user, 29.2% system, 20.7 interrupt (on smp maching. P4-HTT @3GHz) I have 2G ram and 1G swap, swap wasn't used Last edited by graudeejs; 22nd November 2008 at 03:20 PM. |
|
||||
I disabled settings that i marked red in sysctl.conf.
Seams lags decreased a lot. only had 5 lags @5+M/s in period of about 3minutes. This is defiantly better, that it used to be. I still have lags, but way less and shorter. I'll keep monitoring. i want to see what will happen at 8 to 9M/s EDIT: ctorrent sill seam to be better at some point Last edited by graudeejs; 22nd November 2008 at 10:07 PM. |
|
|||
I just use Opera
|
|
||||
No that i don't want.
I don't want operas torrent client, because last i used it it sucked greatly (sorry if i'm rude, but there is no other word describing my experience) besides, i don't think i want to use opera because it's closed source. + i have to compile qt3 thanks for reply |
|
||||
What's wrong with a python based bittorrent client? The original bittorrent client was even coded in python.
EDIT: btw Deluge is my favorite client right now, it has a similar feel to utorrent. you should try it, its nice Last edited by chill; 24th November 2008 at 10:54 PM. |
|
||||
I really like ktorrent. It does have KDE as a dependency, but it has always Just Worked for me, and the UI is intuitive and easy to use. The learning curve is low. It may be worth just installing KDE's libs and stuff to use ktorrent because of how well it works.
|
|
|||
ctorrent rules for a command line client.
__________________
BSDForums.org refugee #27 Multibooting with LILO |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
FreeBSD server, Windows clients, daily backups | Weaseal | FreeBSD General | 4 | 25th December 2008 05:50 PM |
Exempting clients from AuthPF | Kristijan | NetBSD Security | 1 | 12th July 2008 12:09 AM |
Client torrent ! | gnowar | OpenBSD General | 10 | 3rd June 2008 10:50 AM |
torrent? | knasbas | OpenBSD Packages and Ports | 6 | 29th May 2008 05:30 PM |
opera: disable inbuild torrent utility | ephemera | FreeBSD Ports and Packages | 11 | 17th May 2008 12:26 AM |