DietPi-Software | Transmission: 100% CPU usage

[Epicteto]

Creating a bug report/issue

Required Information

• DietPi version
  G_DIETPI_VERSION_CORE=6
  G_DIETPI_VERSION_SUB=25
  G_DIETPI_VERSION_RC=3
  G_GITBRANCH='master'
  G_GITOWNER='MichaIng'

• Distro version
  Buster

• Kernel version
  Linux DietPi 4.19.58-v7l+ DietPi-Software | Bundle Pi-hole & PiVPN #1245 SMP Fri Jul 12 17:31:45 BST 2019 armv7l GNU/Linux

• SBC device
  RPi 4 Model B (armv7l)

• Power supply used
  5.1V 3.1A Canakit

• SDcard used
  Sandisk Edge 32gb

Additional Information

• Software title
  transmission-daemon 2.94 (d8e60ee44f)
  fresh install

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]

@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]

@MichaIng

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

The RPi3 has a different setup:

• DietPi version
  G_DIETPI_VERSION_CORE=6
  G_DIETPI_VERSION_SUB=25
  G_DIETPI_VERSION_RC=3
  G_GITBRANCH='master'
  G_GITOWNER='MichaIng'

• Distro version
  Stretch

• Kernel version
  Linux DietPi 4.19.42-v7+ General | Update VM images to Stretch #1219 SMP Tue May 14 21:20:58 BST 2019 armv7l GNU/Linux

• SBC device
  RPi 3 Model B+ (armv7l)

• Power supply used
  Official supplier provided (Canakit) -- I'm far away

• SDcard used
  Official supplier provided (Canakit) -- I'm far away

Additional Information (if applicable)

• Software title
  Transmission 2.92 (14714)

• Was the software title installed freshly or updated/migrated?
  It was likely updated with dietpi-update whenever a new version was released.

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

Same torrent, different system, same network:

Samba share from the different system to the RPi4

[MichaIng]

@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:

• RPi3 and RPi4 download speeds via Transmission is now the same, only CPU usage is much higher on RPi4?
• The 90 MiB/s download speed via Samba was on RPi4 DietPi to the same target drive?
• In case of external drive, which file system, exFAT? Because there is another report about constant CPU usage on exFAT since Buster: Mounting exfat drive cause large CPU spike #3027
• And in case of external drive, did you assure to use a USB3 port on the RPi4 since there are two USB2 as well. If Samba transfer was to the same drive, it was obviously USB3..

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]

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

[zerom1nd]

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]

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]

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!