transmission-daemon TCP uploads capped to ~ 300 kBps per peer

Maintainer: @dangowrt
Environment: ARMV7, IPQ806x, 23.05.2
Version: 4.0.4-1
Description: TCP uploads from Transmission seem to be capped at around 300 kBps (most commonly between 270-320 kBps). μTP uploads, as well as all downloads, are unaffected and seem to only be capped at my installed bandwidth of 500 mbps (symmetric).

The uploads are from a USB 3.0 SSD that is attached to the device. Read speeds from the USB device, and the attached network are all otherwise nominal, as tested locally within the device and over the LAN (using SMBD).

Here's a redacted copy of my /etc/config/transmission.conf file:

config transmission
        option config_overwrite '1'
        option mem_percentage '70'
        option nice '5'
        option blocklist_enabled 'true'
        option blocklist_url 'https://github.com/Naunter/BT_BlockLists/raw/master/bt_blocklists.gz'
        option peer_port 'xxxx'
        option peer_port_random_on_start 'false'
        option preallocation '0'
        option rename_partial_files 'true'
        option rpc_enabled 'true'
        option upload_slots_per_torrent '5'
        option ratio_limit_enabled 'true'
        option umask '"000"'
        option port_forwarding_enabled 'false'
        option config_dir '/mnt/sda1/Transmission'
        option user 'root'
        option group 'root'
        option encryption '0'
        option torrent_added_verify_mode 'fast'
        option trash_original_torrent_files 'false'
        option download_dir '/mnt/sda1/'
        option scrape_paused_torrents_enabled 'false'
        option enabled '1'
        option peer_limit_global '190'
        option peer_limit_per_torrent '5'
        option message_level '2'
        option start_added_torrents 'true'
        option download_queue_enabled 'false'
        option queue_stalled_enabled 'false'
        option ratio_limit '1.03'
        option cache_size_mb '4'
        option web_home '/mnt/sda1/xxxx'
        option rpc_host_whitelist_enabled 'false'
        option rpc_whitelist_enabled 'true'
        option rpc_whitelist '127.0.0.*,192.168.xxxx.*'
        option rpc_authentication_required 'false'
        option rpc_port 'xxxx'
        option default_trackers 'udp://93.158.213.92:1337/announce\n\nudp://102.223.180.235:6969/announce\n\nudp://23.134.88.6:1337/announce\n\nudp://193.189.100.187:6969/announce\n\nudp://185.243.218.213:80/announce\n\nudp://91.216.110.52:451/announce\n\nudp://208.83.20.20:6969/announce\n\nudp://23.157.120.14:6969/announce\n\nudp://156.234.201.18:80/announce\n\nudp://185.102.219.163:6969/announce\n\nudp://185.50.159.149:6969/announce\n\nudp://209.141.59.16:6969/announce\n\nudp://38.7.201.142:6969/announce\n\nudp://73.170.204.100:6969/announce\n\nudp://176.31.250.174:6969/announce\n\nudp://82.156.24.219:6969/announce\n\nudp://83.102.180.21:80/announce\n\nudp://185.230.4.150:1337/announce\n\nudp://tracker.opentrackr.org:1337/announce\n\nudp://opentracker.i2p.rocks:6969/announce\n\nudp://open.demonii.com:1337/announce\n\nhttp://tracker.openbittorrent.com:80/announce\n\nudp://tracker.openbittorrent.com:6969/announce\n\nudp://open.stealth.si:80/announce\n\nudp://tracker.torrent.eu.org:451/announce\n\nudp://exodus.desync.com:6969/announce\n\nudp://explodie.org:6969/announce\n\nudp://tracker1.bt.moack.co.kr:80/announce\n\nhttps://tracker.tamersunion.org:443/announce\n\nudp://uploads.gamecoast.net:6969/announce\n\nudp://tracker.tiny-vps.com:6969/announce\n\nudp://tracker.theoks.net:6969/announce\n\nudp://tracker.cubonegro.lol:6969/announce\n\nudp://thinking.duckdns.org:6969/announce\n\nudp://tamas3.ynh.fr:6969/announce\n\nudp://ryjer.com:6969/announce\n\nudp://retracker01-msk-virt.corbina.net:80/announce\n\nudp://p4p.arenabg.com:1337/announce'

TCP send buffers don't seem to affect the problem one way or another, and I've tried tweaking all the other TCP settings too. Here's my current /etc/sysctl.d/20-transmission.conf file:

# Transmission requests large buffers by default
net.core.rmem_max = 8388608
net.core.wmem_max = 20971520
net.ipv4.tcp_rmem = 4096 16384 8388608
net.ipv4.tcp_wmem = 4096 16384 20971520
net.ipv4.tcp_no_metrics_save = 1

# net.ipv4.tcp_mem = 8919 11892 17838
net.ipv4.tcp_mem = 8919 23784 26757

# Some firewalls block SYN packets that are too small
net.ipv4.tcp_adv_win_scale = 2
net.ipv4.tcp_reflect_tos = 1

The TCP congestion control algorithm doesn't seem to matter. I've tried cubic, reno, bbr, and scalable.

When a TCP upload is in progress, ss shows a large Send-Q for the connection (as expected), but it doesn't show any memory information even with the -m option set.

Given all the steps that I've described above, I currently suspect this to be a bug in the package. I'm open to trying out any other troubleshooting ideas to help narrow down the cause.

Start by reviewing the Transmission package configuration represented by /etc/config/transmission.conf and the sysctl overrides in /etc/sysctl.d/20-transmission.conf. Reproduce a TCP upload while comparing it with μTP, inspect the connection with ss -m, and verify whether package settings explain the per-peer cap. Done means identifying a reproducible package cause or ruling it out with documented evidence.