Transmission causes leopard slow death

[kormoc]

Things for Leopard Users to Test - Phase 1

1. Apple has a handful of network fixes in its security updates. Everyone who wants to help should go to Apple Menu -> Software Update and get up-to-date with the security updates. This probably won't solve anything (though who knows, maybe we'll get lucky) but it will eliminate any noise in the bug reports caused by testers running different revisions of Leopard.

Mac OSX Version 10.5.8
Processor 2x2.8 GHz Quad-Core Intel Xeon
Memory 6 GB 800 MHz DDR2 FB-DIMM
Transmission 1.73 (8832)
VMWare Fusion 2.0.5

2. If mcui's theory is correct, then the issue should be most likely to occur when down (or up+down) speed limits are enabled, less likely to occur when only download limits are enabled, and least likely (rarely or never) to occur when no speed limits are enabled. So after getting up-to-date with the security patches, please test those three conditions and see how long / how frequently the behavior crops up.

I have no rate limits set, and I see this. Here's my settings:
Global Bandwidth Limits Download rate: unchecked
Global Bandwidth Limits Upload rate: unchecked
Scheduled speed limit: unchecked
Global macimum connections: 200 peers
Maximum connectsions for new transfers: 60 peers
User peer exchange for public torrents: unchecked
User distributed hash table for public torrents: unchecked
Prefer encrypted peers: checked
Ignore unencrypted peers: unchecked
Prevent known bad peers from connecting; checked
223,956 IP address rules in list
Automatically update weekly: checked
Peer lisening port: 51413 (port is open)
Rendomize port on launch: unchcked
Automatically map port: unchecked
Connect to trackers with a proxy: unchecked
System sleep: unchecked

net.inet.tcp.rfc1323=0
net.inet.tcp.recvspace=32768
net.inet.tcp.sendspace=32768
net.inet.tcp.win_scale_factor=1
net.inet.tcp.sockthreshold=0

rfc1323, win_scale_factor, sockthreshold seemed to do nothing, the recvspace and sendspace being set seems to solve it (for the past 20 minutes or so, It would typically fail after 4 minutes).

I was hoping that disabling the speed limiter would solve if, but even with it disabled, I can reproduce it 100% of the time in under 5 minutes

So the only downside to this is my gigabit network is a bit slower now.

[stannenb]

It's probably hazardous to my health to ask questions in this thread anymore... but does anyone see a difference in the Slow Death bug in 1.74 beta 1? I made some changes that may lessen its frequency and I'd like to know if I'm on the right track.

FWIW,

I'm using 10.5.8 and had repeated problems with the "slow death" problem. I found this thread and the workaround, installed it, and had no further problem.

Yesterday, I upgraded to Transmission 1.74 beta 1, removed the sysctl workaround, rebooted, and have been running for about 12 hours without problem.

So, from the perspective of this single user, yes, you're on the right track.

I'll update this thread if I start running into problems.

[cheule]

[*] Lastly -- and admittedly this is more opinion than fact -- everyone reading this should tell kidmidnight that it's probably a bug in his router.

Wow, that was so good I think I pooped myself a little. And to kidmidnight, good on you for taking it in stride. Also, glad to see you've been using the parodyr fix.

I can be the guinea pig and remove the network tweak. I'll try it tonight.

EDIT: Been running for about 5 hours now with 1.4b1 and no sysctl mods. I've had no slowdown/network freezes at all. So far looking really good. I also see 1.4 release went live as I write this, will switch to that.

[heffeque]

In my case, the slow death only occurs when with A LOT of torrents active and a lot of peers in each.

[bosephus61]

I'm pretty sure this issue is due to running out of kernel mbufs/ncl -- ( think the limit is around 13K) -- the downside is that it will take away more memory from apps but it tends to be worth.

You can increase the limit via the following line and then reboot the system without having the hobble TCP

nvram "boot-args maxloreserve=425 ncl=131072 initmcl=131072 nbuf=131072 mbuf_debug=0x3"

[Zolo]

i tried the new version and it still did it so i might try bosephust61s way. if not ill have to use utorrent or something until this is fixed. transmission is so much better but i cant crash my machine all day.

[Alesc]

Transmission is the best, but it crashes my Mac all the day too... uTorrent is good too, but does not report correctly my uploads on my favourite tracker... I'va tried all clients available, but I'm stuck with this awful Vuze... It's heavy, ugly, but stable and report correctly to my tracker...

[linenoise]

1.74 on a current 24" iMac with 10.6 and it appears speed limit is functioning correctly now. Been testing it sporadically since the release and haven't had a problem yet (touch wood). Going to leave it over the weekend, hopefully everything is still working come Monday.

Edit: A further week of testing, shaped from 12:00pm to 2:00am daily, and not a single hiccup. This is 1.74 on an unmodified Snow Leopard install.

[noelos]

I had 1.74 on a current iMac 24" with 10.6 too and had the same death problems with larger numbers of torrents.

I tried parodyr's approach and it appears to work. However, having read the whole thread now, I think, it still wasn't clear to me exactly what the fix does. It states it slows things down on a per-connection basis. Does this mean it makes each connection slightly more inefficient by fixing packet sizes or that it limits the absolute maximum bandwidth of each connection to a specific level?

I saw mentioned that it might slow down HTTP and FTP requests, but if it is a couple of percent versus a "cap" I can live with that. The bigger problem with a cap would be if it applied to my LAN too. Last thing I want is to limit LAN connection speeds when shuffling around DVD images between directly connected machines.

Can someone explain what parodyr's workaround actually does?

[metaclam]

The changes I made are the following (contents of /etc/sysctl.conf file):

net.inet.tcp.rfc1323=0
net.inet.tcp.recvspace=32768
net.inet.tcp.sendspace=32768
net.inet.tcp.win_scale_factor=1
net.inet.tcp.sockthreshold=0

You don't need to restart your machine, you can also do this manually:

Code: Select all
sudo sysctl -w net.inet.tcp.rfc1323=0
sudo sysctl -w net.inet.tcp.recvspace=32768
sudo sysctl -w net.inet.tcp.sendspace=32768
sudo sysctl -w net.inet.tcp.win_scale_factor=1
sudo sysctl -w net.inet.tcp.sockthreshold=0

So this issue persists with a vengeance on Snow Leopard. I just found this solution after reading through this forum. Earlier it was suggested it was an OS issue and Snow Leopard would fix it. But it has not. So what now? Are these changes safe to make on Snow Leopard?

edit: also can I comment the file somehow? I don't want to go around sticking in esoteric system files that I don't know where they came from later... thanks.

edit2: there also is no such file that exists "/etc/sysctl.conf" on my SL install

edit3: well no dice. I tried it anyway -- created that file, with a ; comment in front if that makes a difference, with unix line endings. restarted. launched transmit. killed connection again, as usual. so the question remains, does this work on snow leopard? if it is supposed to, are file permissions an issue maybe?

[cheule]

so the question remains, does this work on snow leopard? if it is supposed to, are file permissions an issue maybe?

I am no longer having this issue at all. Running stock 10.6.1, with Transmission 1.74 release (8993).

However, if you are having a network slowdown and then system freeze, it sounds like adding the sysctl.conf is a good idea for you. This file will not ruin anything. It just sets limits to the network interface that should be set automagically, but apparently are not.

Don't be uncomfortable with creating conf files. Ccomfort just comes with experience (meaning, the more you do it, the more you realize it's not strange at all).

If you think you might have messed up the creation of this one, follow these steps.

1) open Terminal (found in Applications -> Utilities)

2) Type: "sudo pico /etc/sysctl.conf" (no quotes)

3) type admin password, if it's the first time you've ever used 'sudo', it will give you a scary message, read it, but remain unscared.

4) copy and paste this into the pico text editor:

Code: Select all

sudo sysctl -w net.inet.tcp.rfc1323=0
sudo sysctl -w net.inet.tcp.recvspace=32768
sudo sysctl -w net.inet.tcp.sendspace=32768
sudo sysctl -w net.inet.tcp.win_scale_factor=1
sudo sysctl -w net.inet.tcp.sockthreshold=0

5) press ctrl-x, accept save

6) reboot

This was written from memory, so if I skipped a step or something, feel free to correct my procedure.

[blueadept33]

WOW, thank god it's not just me, reinstalled whole OS after trying all the different torrent clients trying to fix this issue, my roomies were going to kill me. Thought I was taking crazy pills, now to fix it , ugh

[kassandradeluxe]

Just fyi, there's a second thread discussing the same issue:
http://forum.transmissionbt.com/viewtop ... 865#p40865

[benphelps]

I am having this same issue with 1.75 (9112) running 10.6.1

I have the EXACT same problems described in the second post.

[jakobb]

So i did the sudo thingy and corected this so called OS short comming, still doesn't work - but here is some trivia for you: Tomato Torrent works! And that without lagging, beachballing, failure to quit and what not.

The story is the same under 10.5 and 10.6 - Transmission is that fantastic piece of software that combines all the torrent needs one could have but without actually succeding in the main goal - downloading torrents. But then again its free!

Don't get me wrong I love transmission, just not when trying to use it...