Transmission causes leopard slow death

[TheBang]

I have just read this entire thread in an attempt to be marginally less ignorant when I post.

Thank you. This kind of attention to the problem is what I was hoping for when I wrote my mini-rant above.

Many users have reported that it only happens when speed limiting is on. This is right in line with mcui's theory.

I rarely (almost never) use Speed Limit. I do use "Limit total bandwidth" for both up and down, but it makes sense that it would trigger on that also, since that's just another form of speed limiting.

[*] 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.

In my testing, I NEVER adjusted or turned off my upload limit (in "Limit total bandwidth"). It did not seem to trigger or affect the freeze. If I had download limits in place, then I would get the crash. When I turned off "Limit total bandwitdth - download rate" I would no longer get the crashes. As soon as I enabled it, a crash would happen soon thereafter.

Now, the fly in the ointment. As I mentioned earlier, I've been running with download limits off. Per my last post, I once again enabled download limits for this testing. I haven't crashed. There appear to be specific circumstances or configurations that trigger it. Obviously, that is why it affects some people and not all. Since I was last crashing, I've updated to 1.50 final, I've updated VMWare to 2.0.2 (from 2.0 and 2.0.1; although VMWare seems to symptomatic and not causal), and I've done OS updates, but I'm not sure which.

When people report getting crashes, I think people need to be specific about the limits they're using. Do you use "Limit total bandwidth"? Up? Down? Do you use Speed Limit? Up? Down? Which ones are active when you crash? Edit: actually, kine's reporting format right above me seems to be perfect and contain all the information asked for. Maybe just add the Transmission version and OS version (with updates) to the end there.

[guilherme]

Just wanted to add that I've been running 1.50+ (7830 as of now, but basically just the nightlies) for a while with only upload limits on (my max = 75 KB/s, my limits vary between 55 (mostly) and 35). I do not experience this slow death problem - however, when Transmission is on with those settings, I do encounter "temporary" spinning balls of death when using Safari or Mail (opening/switching tabs, opening mail, reading rss, etc), which disappear after 5 seconds or so. I do not know if this pseudo-issue is brought up by Transmission, but testing with a max seeding speed of 5 did not affect this behavior (it's still there).
Maybe it is related, but it probably isn't.
Either way, I've just started downloading Ubuntu + FreeBSD and set up a download limit of 70 KB/s (will change during download to test) on 1.50.

Edit: so... that was fast. Took 3 minutes between adding FreeBSD and Ubuntu's torrent (both amd64 and i386 versions), setting my limits to 150 down/40 up and a fast death. Note that I had never experienced this issue before trying this method. All 4 torrents are heavily seeded and would probably max out 99% of the connections out there. First, it was Transmission that spinning-balled, then I hit Command+Option+Esc in order to force close it, but then the app that does the force quitting spinning-balled as well, and then Safari (don't know the english for it, but something like "Force Application Quit"). Right now I'm back to 7930, running WITH speed limits on (same up limit, down limit set to 1000, which is more than I can handle) and everything's running smoothly =)

2nd Edit: Will now run the same test on uTorrent, BitRocket, Vuze, Transmission GTK and XTorrent (if there is a trial of some kind). I guess the last two will be the most useful, as both are libtransmission =)

[guilherme]

uTorrent 0.9.0.4, BitRocket, XTorrent (the 2nd one, shareware, based on libtransmission ) and Vuze did not present such behavior, although uTorrent did his usual 90-100% CPU usage and noisy fans.

On the other hand, the GTK client for Transmission also did "fast death" my MacBook - with the only difference being that there was no Spinning Ball, as it seems that SPODeath is a Quartz implementation (GTK runs on Apple's X11). Except for this small difference, the GTK client behaves exactly the same as the Aqua client on my MacBook.

I have no experience with the Daemon and CLI, but should I test them as well (on Leopard)? If so, I suppose I should look at the wiki for instruction, right?

Oh, forgot to mention that both clients Leopard's death are related to a console message from the Kernel as well:

Code: Select all

21/02/09 08:51:33 kernel npvhash=4095 
21/02/09 09:41:10 kernel npvhash=4095 

Edit: ok, nevermind that message. I'm almost sure that it just means that I did a hard reset (powerdown>power up).
I did further testing with the latest "point" releases of 1.4, 1.3, 1.2, 1.1, 1.0 and 0.9. Of those, the first one to actually kill leopard (and it was a bad crash - even the clock stopped in time =P) was 1.34. I'm leaving for lunch, but when I get back, I'll test 1.3 through 1.34 =)

[kidmidnight]

1.22 did it too. the problem is that it is so intermittent its hard to pinpoint.

[guilherme]

From 1.34 on, all I had to do was to leave it on for 5 min and then come back. 1.22, 1.11, 1.06 and 0.96 all ran for nice 15 minutes without dying =)

[kidmidnight]

errr... did it again.

This time it was when i limited the download rate to 100 from unlimited. I think it is either the act of changing the rate or just changing the download rate because i have a permanent upload cap on which never changes (crap dsl...), and that doesnt seem to effect it at all. I should play around with changing my upload rate a few times to see if that does it too; but the cap itself doesnt seem to be causing any of the crashes.

[husky]

I've been testing 1.50 now, and i haven't got any hangs in 24 hours. I've been using these settings:

Download rate: no limit
Upload rate: 50kb/s
Global max. connection: 200 peers
Max. connections for new transfers: 60 peers

And i haven't been using speed limit mode. I did experience some hangs on other programs, but those might be unrelated. No weird messages in the logs either. So my guess is that the hangs seem to relate to download limit rates.

[Jordan]

Does it happen (ever, or less frequently, or equally frequently) when you start the session without any download speed limits, and leave the download speeds unlimited?

[guilherme]

For me it never happens (as it never did before the instructions) - even with maximum download speeds (about 670KB/s here) =)

[kidmidnight]

I'm not going to say never, because it might have, but it happens much much much less frequently when you have no speed limits.


I will also say that it happens less when you start you session with a limit and stick by that the whole time.

[popophobia]

Strange, I've been running 1.34 previously on my old Mac (not sure about the version, but I didn't want to update OSX to 10.5.6 and the next version recommends 10.5.6, so I skipped it altogether). No problem whatsoever with speed limit. I actually had it very stable.

And now, I reinstall OS X 10.5.6 (same hardware) and download 1.42, slow death occurs almost everytime I run Transmission (speed limit is set by default). Upgraded to 1.50+ nightly built, the problem has gone away. I'm not sure what version though, I'll check when I get home.

Just wondering, is it safe to upgrade to 1.51? I don't want to use nightly built as the main client.

Thanks.

[livings124]

Just wondering, is it safe to upgrade to 1.51? .

Yes.

[parodyr]

I had transmission running for about 6 months without any problems (1.34 - 1.51).

My Settings: Leopard 10.5.6, 3GB RAM, internal + many FW800-external HDs

Downloading: about 60-120 torrents - at the same time (I usually don't care how long it takes, I just wait)
Seeding: 30-50 - at the same time (actually, all I have downloaded stay for seeding a long time)

Limits: Download: NONE; Upload: 100KiBi

My bandwidth is: 2048/2048 (SDSL with 2Mbps max on both sides), this is the reason for 100KiBi Upload limit.

Usually, I have time scheduled limit to 150KiBi (Download) and 100KiBi (Upload) from 18-22h (when I am at home)

I had this freezing problem *immediately* when I did following changes:

Limits: Download: NONE; Upload 150KiBi - this was the only change - The whole system would freeze within 3-5 minutes.

I read this forum and tried all suggestions (inactive memory, etc.) - No, that was not the solutions. In fact I could reproduce many times the situation where my "Free Memory" was 20MB and Inactive 1.5GB, but that was not the reason. I don't know why, but the reason seems to have been the raising of the Upload-Limit to 150KiBi. When I changed it back down to 100KiBi, everything went smoothly - even though I have only 10MB or 8MB Free Memory (2GB Inactive) from time to time.

It *is* true that Transmission seems to use a lot memory while checking data consistency and releasing them somehow only into the "Inactive Pool", but at the end of data consistency check, most of the Inactive Memory was released to the Free Memory pool automatically (Forget iFreeMem, no need for it).

The Freeze Issue is the same as with everyone: System freezes (mouse works fine), Network freezes (No ICMP-Echo packets from the machine when ping'ed).

BUT: The machine itself keeps running. CPU is still alive, etc. I did this check by writing a script which would "touch" a file every second. SO when the machine froze, I kept it on for ten minutes to see if the machine was actually alive but "only UI frozen". Yes, that seems to be the case (UI + Network). My script kept touch'ing the file all the time until I rebooted the machine.

The problem seems to be somewhere in the networking stack. As I remember correctly, all applications communicate with the Window Server via sockets/ports. Once the networking stack freezes, all UI should automatically freeze as well.

Hope this helps
Imdat aka parodyr

[essiw]

about the Free memory, inactive memory is also free memory (but it has already been used that is why it has a differend name, inactive memory can start up quicker to do the same thing it has done first) so unless you have also a low inactive memory value there is nothing to worry about

[parodyr]

To follow-up on my previous post:

I had Transmission running as described above with no problems. Then I switched to "Speed-limit"-Mode, where I have download speed-limit of 150KiBi and Upload still at 100KiBi.

This Speed-limit change caused the machine to freeze after about 5-10 Minutes. Same freeze as every time described before.

Now, it's back to the standard setting (No Limit for Upload, 100KiBi for download) and it works like a charm...

Imdat aka Parodyr