Transmission daemon CPU load limits on limited platforms

[krx]

Hi,

Perhaps it would be possible for transmission to limit its CPU usage on the platforms like routers, where CPU and I/O limits are the real bottleneck. The issue is to find the balanced aproach, which is evidently based on the active torrents count, peer count, the bandwidth usage (both network and storage), and if ecnryption is off/preferred/forced

My goal is to build "green" torrent's router, which is limited in its performance, but adapts to the hardware it is running on. Because sometimes it is possible to fire&forget for long time such router, without any problems. But if the system loads gets over optimal 1-1.5-2, the whole platform performance is diminished. This is especially bad if you start to use other services (FTP/SMB/etc.), which compete for CPU and I/O. This can be solved by nice-ing transmission daemon from the relative POV. Yet in such case, the CPU queue must not overbooked from absolute POV, as in such case the responsivesness of the system rapidly falls.

For this moment to do this, the only solution I have found, is to manually limit active torrent count and allowed peer count - the most influential variables.

Some torrent cliens have such facility, which unpauses next paused torrent, as soon as the oldest in the the queue finishes its download and/or seed goals. In such case, the system load perhaps would be bound only to the peer global limit and thus might be controled without any artificial throttling methods.

I hope I made sense and this will be meaninfull to implement some time in the future.

From green POV, it is better to have such limited low-power green router, instead of the desktop, nettop, as I managed to get <15 Watts for the router + external USB HDD.

[charles]

There's already an `embedded' compile-time option to turn off i18n and to prefer unencrypted peers. Encryption is by far the highest CPU cycle sink in Transmission.

The second highest CPU cycle sink is torrent verification, which is being addressed in #2955.

Queueing already has a ticket, #671

Reducing the number of requests we make based on bandwidth available, even if the user's not using speed limit settings, is being addressed in #2993

[krx]

Replying to charles:

There's already an `embedded' compile-time option to turn off i18n and to prefer unencrypted peers. Encryption is by far the highest CPU cycle sink in Transmission.

Thanks for explanation. I am sorry, but I do not know what is "i18n". May you please explain? And does this your statement mean, that if I get Transmission from optware repository, then these optimized compile-time options will be ON by default?

The second highest CPU cycle sink is torrent verification, which is being addressed in #2955.

I see, I'm waiting eagerly on next release.

Queueing already has a ticket, #671

Thanks for noting. This one is big and old.

Reducing the number of requests we make based on bandwidth available, even if the user's not using speed limit settings, is being addressed in #2993

Understood.

Your answer sums up my issue, I will wait for separate solutions.