search

MichaIng / DietPi

Lightweight justice for your single-board computer!
https://dietpi.com/
GNU General Public License v2.0
4.89k stars 498 forks source link

DietPi-Software | Transmission: 100% CPU usage #3025

Closed Epicteto closed 4 years ago

Epicteto commented 5 years ago

Creating a bug report/issue

Required Information

Additional Information

Steps to reproduce

Download torrent.

Expected behaviour

Speeds should surpass those of Raspberry pi 3b+, Transmission 2.92 (14714), which reaches 20-30MB/s (the USB max) with CPU% between 20% and 70%.

Actual behaviour

During download, transmission is using one core, and CPU% bottlenecks at consistent 100% for a regular download speed of about 20MB/s. If download speed is slower, CPU% is lower.

Extra details

Tried changing UDP/encryption/peer/cache/different torrents with no success. Samba transfers reach 90MB/s on the same device, Internet connection speed test is about the same.

MichaIng commented 5 years ago

@Epicteto Many thanks for your report. Indeed that are strange results.

Performance-wise we found another strange result on RPi4: https://dietpi.com/survey/#bench_ram While it's LPDDR4 RAM should be much faster than RPi3, the benchmarks show it's even a bid slower. I am not yet sure where this is coming from, since DietPi is based on the official Raspbian image with exactly the same firmware installed.

Could you please paste:

vcgencmd get_config int
vcgencmd get_config sdram_freq

The RPi3 is on the same DietPi version, both with similar software installed? And did you do apply any performance/overclocking settings? Ah and SDcard is the same, or at least should be same speed?

Epicteto commented 5 years ago

@MichaIng

Many many thanks for DietPi. Great experience on a few RPis for the past couple years.

The RPi3 has a different setup:

Additional Information (if applicable)

Extra details

The system has the same software installed as well as radarr and sonarr, which were "systemctl stopped" for the test.

Rpi4: vcgencmd get_config int

arm_freq=1500 audio_pwm_mode=514 config_hdmi_boost=5 core_freq=500 core_freq_min=500 disable_commandline_tags=2 disable_l2cache=1 disable_overscan=1 disable_splash=1 display_lcd_rotate=-1 enable_gic=1 enable_uart=1 force_eeprom_read=1 force_pwm_open=1 framebuffer_depth=16 framebuffer_ignore_alpha=1 framebuffer_swap=1 gpu_freq=500 gpu_freq_min=500 init_uart_clock=0x2dc6c00 lcd_framerate=60 pause_burst_frames=1 program_serial_random=1 temp_limit=65 hdmi_force_cec_address:0=65535 hdmi_force_cec_address:1=65535 hdmi_pixel_freq_limit:0=0x11e1a300 hdmi_pixel_freq_limit:1=0x11e1a300

RPi4: vcgencmd get_config sdram_freq

sdram_freq=0

Update

RPi4 (see 2 captures) touches 30MB/s like the RPi3, core is 100% at >20MB/s

image image

Same torrent, different system, same network: image

Samba share from the different system to the RPi4 image

MichaIng commented 5 years ago

@Epicteto

sdram_freq=0

I think the SDRAM frequency is hard-coded on RPi4. I also reviewed some overclocking threads on https://www.raspberrypi.org/forums/ and never found someone adjusting this value, but only ARM and core frequencies (+voltage, if required). Although would be great to have some verification from firmware devs.

Did you monitor the CPU temperatures (G_OBTAIN_CPU_TEMP) during download/transfer? Does it reach 60 °C or higher? We did not yet adjust the temperature limit for RPi4 on current version, I just recently updated it to 75 °C, since temperatures are close or even higher than RPi3. If if reaches 60 °C or higher, you should raise the limit to avoid down throttling, e.g.:

G_CONFIG_INJECT 'temp_limit=' 'temp_limit=75' /DietPi/config.txt

Reboot required to have it active.

Just to clarify:

So general what we need to compare:

  1. Raspbian Buster Lite vs DietPi Buster, to check if it's DietPi specific
  2. If no difference above, RPi3 with Buster vs RPi3 Stretch, to check if it's Buster specific

I will also test Transmission on RPi2 Buster now. With my setup, CPU usage should not stay at 100% as well.

Thread on RPi forum, not sure if related: https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=246807

Did quick test on Buster VM and usual CPU usage around 15% there, although with only 2.7 MiB/s speed, WiFi limited 😉. Tested on multiple drives/files systems.

MichaIng commented 4 years ago

I mark this issue as closed, as it has been a while. Feel free to reopen if required.

zerom1nd commented 3 years ago

this problem in client transmission, he work on one core (loading 100%) and give max ~30mbyte/s. in my router too have only ~30mbyte/s, but i have another version (opkg and ipkg packages) give full speed of port!

need client support multi threads! maybe deluge/qbittorrent better ?

MichaIng commented 3 years ago

AFAIK generally Transmission has multi-threading support but not every single task is spread across multiple threads. What do you mean by "other versions"? Other versions of Transmission make use of multiple threads and serve higher speeds for the exact same action then the one that we ship (current Debian package)?

Not sure if Deluge or qBittorrent make use of multiple cores more effectively, but their memory management seems to be better.

I would simply try it out as there are many other aspects that affect the effective download speed, including drive R/W, which also has an effect on CPU usage, depending on the used file system type. E.g. NTFS (with ntfs-3g driver) and exFAT utilise the CPU usually much harder than native UNIX file systems, like ext4, f2fs etc.

zerom1nd commented 3 years ago

i have NVME and ext4 file systems, i cant make better perfomance ;) problem in transmission-client..

i understand it, because my Asus RT-AX88U in different transmission client give one version 20-30mb/s, other - 70!