Slow curl download speeds

Creating a bug report/issue

Required Information

  • DietPi version | DietPi 8.5
  • Distro version | Bullseye
  • Kernel version | 5.10.110-meson64
  • SBC model | Odroid N2+
  • Power supply used | Default Odroid N2+ supplied
  • SD card used | 64GB Odroid eMMC

Additional Information (if applicable)

  • Software title | curl
  • Was the software title installed freshly or updated/migrated? Installed freshly
  • Can this issue be replicated on a fresh installation of DietPi? Yes

Steps to reproduce

  1. Log in as a regular user
  2. Go to your user folder (e.g. /home/jeffrey)
  3. Run a curl download

Expected behaviour

Consistent download speeds, for example, I have a 50 Mb connection, so I would expect a speed of around 6000 KB/s.

Actual behaviour

Speeds are heavily fluctuating, going from 6000, to 0, to 4000, to 6000 and back to 0 all the time.
It looks like the device is writing the data to the local storage while it is at 0. When I download the file to /dev/null or to /mnt/dietpi_userdata, everything seems to work as expected.

Extra details

eMMC read speeds are around 120 MB/s and write speeds are around 70 MB/s. Ethernet directly connected to a FRITZ!Box 6660 Cable. Both of these don’t seem to be the bottleneck.

Are /home/jeffrey and /mnt/dietpi_userdata both in eMMC?
What is the output of mount; df -h
You can see also the see total amount of iowait of all processes in wa field of top.
Or you can see them split down with iotop command.

They are both on eMMC.

jeffrey@odroid:~$ mount; df -h
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=1470724k,nr_inodes=367681,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=387472k,mode=755)
/dev/mmcblk1p1 on / type ext4 (rw,noatime,lazytime)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
none on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=30,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=2669)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /var/log type tmpfs (rw,nosuid,nodev,noatime,lazytime,size=51200k)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime,lazytime,size=1936384k)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime)
Filesystem      Size  Used Avail Use% Mounted on
udev            1.5G     0  1.5G   0% /dev
tmpfs           379M   39M  340M  11% /run
/dev/mmcblk1p1   58G  2.4G   53G   5% /
tmpfs           1.9G     0  1.9G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs            50M  8.0K   50M   1% /var/log
tmpfs           1.9G  4.0K  1.9G   1% /tmp

The problem seems to be caused by the CPU governor.
When it’s on schedutil and I download a file, once the download speed drops to 0, a process called “sugov” is peaking at 100% CPU.

I changed the CPU governor to ondemand, and the problem seems to have vanished.

Is this a bug, or expected behavior?

I haven’t used it so I am not sure what is expected from this governor.

Maybe @MichaIng could have a look

Indeed the sugov process is from the kernel when schedutil it used: raspberry pi - What's the process "sugov:0" - Unix & Linux Stack Exchange

Seems like the CPU usage is not really added by that process. When you use ondemand, is the same CPU utilisation probably at a different process?

100% might be because schedutil is clocking up/down much faster, so at low utilisation is clocks down.

What I recognised is that the large cores seem to be generally at lowest clock during I/O, also when doing e.g. a RAM benchmark, affecting it negatively, which is why for dietpi-benchmark we switch to performace governor since a while. But it was still at several 100 MiB/s, so I cannot imagine it would limit a download to eMMC, and USB seems to be unaffected (/mnt/dietpi_userdata?).

I’ll try to replicate on my N2+, with eMMC as well, also interesting whether it’s the same with an SD card (MMC bus?).