I run transmission-daemon on a 400mhz arm linkstation.
Up to version 2.13 with only encrypted peers the CPU was pegged at about 800-900k/s
Now when I upgrade to 2.21 the cpu is pegging at around 300k/s.
Any ideas on how to sort? Has something fundamental changed? Or should I just roll back to 2.13 and wait for more stability in the 2.20+ version?
Huge perfomance hit 2.13 >2.21
Re: Huge perfomance hit 2.13 >2.21
Interesting... low performance with both versions compared to an HP MediaVault which is also ARM but at 500 MHz:
I think the main factor that affects performance in these NASes is the low ammount of RAM, mine has only 128 MB, I'm sure it could fly if it had at least 1 GB (i.e. LAN speed just reaches 25% of the Gbps interface it has, and most of the time its around 10% you got to get it in a good moment to do better -- not a joke, the stupid little php processes running by cron do interfere most of the time).
Are you building Transmission? Have you tried the --enable-lightweight configure option? (I don't use it, but it would be interesting to know what changes in practice).
Code: Select all
$ cat /proc/cpuinfo
Processor : ARM926EJ-Sid(wb) rev 0 (v5l)
BogoMIPS : 332.59
...Are you building Transmission? Have you tried the --enable-lightweight configure option? (I don't use it, but it would be interesting to know what changes in practice).
Re: Huge perfomance hit 2.13 >2.21
I build from source and have tried the lighweight flag. I've also played with encryption and the 'cache-size-mb' option. It improves matters but we are talking shades of gray rather than huge improvement.
More testing shows the more torrents you have the slower it gets. Ie if I remove all seeded torrents I get almost full speed back but that is no use as I download then seed until I've upped 2x what I'd downloaded.
I appears to get it's knickers in a twist when seeding lots (well 10) larger torrents. So I've rolled back to 2.13 and everything is working as 'normal'.
If you need more testing, I'll stick 2.21 back on and get some more firm data.
More testing shows the more torrents you have the slower it gets. Ie if I remove all seeded torrents I get almost full speed back but that is no use as I download then seed until I've upped 2x what I'd downloaded.
I appears to get it's knickers in a twist when seeding lots (well 10) larger torrents. So I've rolled back to 2.13 and everything is working as 'normal'.
If you need more testing, I'll stick 2.21 back on and get some more firm data.
Re: Huge perfomance hit 2.13 >2.21
Sounds like a memory problem, just like I said, these devices have very little RAM and the more torrents your daemon handles the more memory it needs.
But I don't see why there is a difference between versions.
With any version I've seen that the longer the daemon is running the bigger the memory it uses. I some times just restart the daemon (after months of running) to get it back to using low memory. But now that you described this, I just checked and version 2.21 does seem to be using more memory (around 25% before, 37% now)... but I also just changed the cache size, perhaps that was the cause.
But I don't see why there is a difference between versions.
With any version I've seen that the longer the daemon is running the bigger the memory it uses. I some times just restart the daemon (after months of running) to get it back to using low memory. But now that you described this, I just checked and version 2.21 does seem to be using more memory (around 25% before, 37% now)... but I also just changed the cache size, perhaps that was the cause.
Re: Huge perfomance hit 2.13 >2.21
Just finished testing with the modified cache-size-mb (I was looking at a way to fix wild download bandwidth changes, it did) and did have a look at CPU and memory use: CPU went up to 70%, memory up to around 60%, download speed was above 1 MiB/s most of the time, 1.2 peek from simple observation; after finishing CPU is 14% and going down, memory 40%.
It looks like you are right, the CPU might be a limitation when more than one torrent is downloading at high speed. Comparing to a ftp transfer, which goes to about 14 MiB/s, the CPU went up to 60%, memory less than 1% all the time... so a very rough comparison is that verifying takes the extra 10% of CPU, not bad (but I'm also not taking into account that the speeds where an order of magnitude different).
I'm still not sure how the versions affect this.
It looks like you are right, the CPU might be a limitation when more than one torrent is downloading at high speed. Comparing to a ftp transfer, which goes to about 14 MiB/s, the CPU went up to 60%, memory less than 1% all the time... so a very rough comparison is that verifying takes the extra 10% of CPU, not bad (but I'm also not taking into account that the speeds where an order of magnitude different).
I'm still not sure how the versions affect this.
Re: Huge perfomance hit 2.13 >2.21
Testing with 2 torrents didn't change CPU use or memory much, at most 10%, but in average it stayed about the same. Total download bandwidth increased above 2 MiB/s (I saw a 2.34, and there where other peaks, but the average was probably around 1.5).
Re: Huge perfomance hit 2.13 >2.21
What number do you set for cache-size-mb?
I am using ar71xx(400mhz) based router running on OPENWRT and found 2.21 a bit slower than 2.13.We can use nice or renice to initialize transmission with higher pri to get better performance while processes fighting for resources in these kinds of low performance device.
I am using ar71xx(400mhz) based router running on OPENWRT and found 2.21 a bit slower than 2.13.We can use nice or renice to initialize transmission with higher pri to get better performance while processes fighting for resources in these kinds of low performance device.
Re: Huge perfomance hit 2.13 >2.21
Done some further testing.
2.21 appears to have some buglet in the uploading queuing. I was seeding at 50k/s up and in the 3 hours I ran the test, no-one got a single bit from me.
I then switched back to 2.13 and I'm seeding at 50k/s for the full time.
Then I did some testing with 'upload-slots-per-torrent'. Same thing happened, 2.13 still uploaded to at 50k/s but with more in the 'queue' while 2.21 lurked like a depressed teenager doing nothing.
Something is very wrong with bandwidth management in 2.21 as I'm now downloading at about 200k/s (my router says so), the %age completed is increasing in transmission but I'm getting 0k/s.
Also ""preallocation": 2," appears not to be pre allocating!
2.21 appears to have some buglet in the uploading queuing. I was seeding at 50k/s up and in the 3 hours I ran the test, no-one got a single bit from me.
I then switched back to 2.13 and I'm seeding at 50k/s for the full time.
Then I did some testing with 'upload-slots-per-torrent'. Same thing happened, 2.13 still uploaded to at 50k/s but with more in the 'queue' while 2.21 lurked like a depressed teenager doing nothing.
Something is very wrong with bandwidth management in 2.21 as I'm now downloading at about 200k/s (my router says so), the %age completed is increasing in transmission but I'm getting 0k/s.
Also ""preallocation": 2," appears not to be pre allocating!
Re: Huge perfomance hit 2.13 >2.21
axishero
Who are you asking? And your other point... nice would be useless if the CPU is already doing 100%, don't you think?
abaxas
You are describing many problems, probably unrelated.
To summarize: Version 2.21 has worked before, performance is bad compared to 2.13, and in the last 2 tests it didn't work at all.
The last result sounds like an altogether different problem. But if you can isolate what change broke it...
Then you put an additional 2 problems: bandwidth management? you mean, what some tool shows... but what tool was it? I would try several (Web client, transmission-remote, etc.) just to discard problems with the tool.
Preallocation doesn't seem to work, but has it ever worked with that setting? I've never tried other than the default (which is 1), and that works fine.
Who are you asking? And your other point... nice would be useless if the CPU is already doing 100%, don't you think?
abaxas
You are describing many problems, probably unrelated.
To summarize: Version 2.21 has worked before, performance is bad compared to 2.13, and in the last 2 tests it didn't work at all.
The last result sounds like an altogether different problem. But if you can isolate what change broke it...
Then you put an additional 2 problems: bandwidth management? you mean, what some tool shows... but what tool was it? I would try several (Web client, transmission-remote, etc.) just to discard problems with the tool.
Preallocation doesn't seem to work, but has it ever worked with that setting? I've never tried other than the default (which is 1), and that works fine.