Optimizing transmission for low power MIPS

[draga]

Hi. Yesterday I've compiled Transmission 1.75 (daemon) inside a Mips architecture. It works great, but it uses quite a lot of resources.
On my 300Mhz and 64 MBytes Ram MIPS, it occupies almost 50/60% of cpu and more or less 10 MB ram while downloading 10 torrents.
BTPD, for example, just uses 15% cpu and 3/4 MB ram. I know it's a lighter program (and less complete), but maybe there's something I can do at compile time to lower Transmission resource needs. I've already disabled NLS and libnotify.
Any hint would be appreciated.

[rb07]

Not a fix, just some comments:

• When transmission-daemon starts and it already has some torrents it is normal to see higher CPU usage for a while since it it checking the torrents;
• RAM usage goes up with time. I even restart the daemon on my NAS some times to get it down.

If you have a good compiler for MIPS, then you can use maximum optimization and get a little better performance, nothing spectacular. Make sure the correct floating point mode is used (long story...) Problem is: there are no good compilers AFAIK (other than for CPUs for PC, and even there how long has it taken to get Xeon specific optimizations, how long will it take for the Phenom/i7/whatever optimizations?).

[rb07]

I forgot to add that the default configuration for the daemon is using encryption (--encryption-required) which results in the highest CPU load possible, I always change this to --encryption-tolerated.

[lesiuk]

I see it too.

I have 266 mhz, 32 mb ram MIPS.

And transmission is using 50 - 80% (all the time), (with 2 torrents, about 1,4 GB on list)
rtorrent - 4 - 6 % (while seeding), 30 - 50 % (while downloading), (with 80 torrents, about 120 GB on list)

[whjiang]

To rb07:

Which floating mode and how to set it for MIPS?

[Jordan]

The #1 thing you can do is what rb07 suggested, which is to prefer unencrypted peer connections. When Transmission's in steady state, encryption is by far its most expensive component, CPU-wise.

[rb07]

Which floating mode and how to set it for MIPS?

That's a topic about building the compiler, short story is that you can select one of 3 modes for floating point while building gcc, since MIPS doesn't have a fp-unit, you have to go for pure emulation mode (not mixed, not native).

[Headcase_Fargone]

Slightly off-topic, but somewhat relevant...

I've noticed similar patterns on my DNS-321 NAS. When Transmission starts up with two active torrents it typically eats 15-30% of the CPU (it fluctuates wildly, but that's not the problem). After being up for about ~12 hours that usage goes up to over 50%, and then another few hours later it's hitting the 90s. By 24h of uptime it's pegging the CPU and the unit becomes unuseable, forcing a hard reboot.

Memory usage seems to remain more or less constant. I've set encryption to "0" to no effect.

[jch]

Hmm, this looks suspiciously like http://trac.transmissionbt.com/ticket/2430 (which is number two in my personal TODO list for Transmission). But it's difficult to say without more information.

Folks, it'd be extremely helpful if you could provide us with some profiling data. Unfortunately, profiling is extremely system-specific, and I'm unable to give any specific advice.

--Juliusz

[jch]

I've just submitted a patch for #2430. Could you please apply the following series of patches:

http://trac.transmissionbt.com/attachme ... firm.patch
http://trac.transmissionbt.com/attachme ... toms.patch
http://trac.transmissionbt.com/attachme ... Cull.patch
http://trac.transmissionbt.com/attachme ... ally.patch

and let me know whether it helps?

--Juliusz

[jch]

Forget it, it's buggy.

--Juliusz

[Headcase_Fargone]

For what it's worth, I turned off DHT and PEX and set encryption to 0 and I haven't had to reboot my DNS-321 in two days. I didn't seem to help at first in terms of CPU utilisation, but it certainly does now.

[jch]

For what it's worth, I turned off DHT and PEX and set encryption to 0 and I haven't had to reboot my DNS-321 in two days.

That could very well be #2430 -- disabling PEX and DHT causes transmission to have fewer potential peers, and hence store fewer atoms. But we're just guessing -- there's no way to know without profiling data.

--Juliusz

[Headcase_Fargone]

Looks like I spoke too soon. Transmission was running sluggish (slow to update to Transmission Remote) so I ran a top and it was pegged at 100% CPU usage. Stopped Transmission and restarted it and all is well again.

[schodt]

I too am experiencing 100% CPU after some hours on my kurobox (PPC). Running 1.75 (daemon).
Sorry for the limited info....