| Summary: | Dolphin is too slow when upload a file on a SSH server | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] kio-extras | Reporter: | Francesco <muziofg> |
| Component: | SFTP | Assignee: | Andreas Schneider <asn> |
| Status: | REPORTED --- | ||
| Severity: | normal | CC: | alepik, alpha_one_x86, andrej.halv, bruno+kde, contact, emrecio, ivnitsky.a, kishore96, konstantin, mail, martin+kde, michiel, musikolo, nate, postix, regime_unsold498, scott.deagan, sitter, suse, tetja, zhx |
| Priority: | NOR | ||
| Version: | 18.04.3 | ||
| Target Milestone: | --- | ||
| Platform: | Debian testing | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
sftp console utility upload speed
dolphin upload speed kubuntu 22.04 scp console kubuntu 22.04 upload speed dolphin kubuntu 22.04 upload speed Dolphin / kio-extra/sftp transferring below expected speed Dolphin / kio-extra/sftp transferring at expected speed with libssh 0.11 |
||
|
Description
Francesco
2012-03-21 22:42:09 UTC
an upgrade: sftp on dolphin (upload) with KDE 4.8.3 the transfers run at a speed between 3 MB/sec and 4 MB/sec better than before, but you can do more Same here 4.11.1, on 100MBit just reaching 800 - 900kb/s. I just tried with dolphin 15.08.3, it's definitely an issue. On a gigabit network, dolphin copies up at about 6MB/s, sftp at around 45MB/s. The source of slowness is definitely cpu-bound : in htop, kio-scp runs at 100% of one core during the transfer. We do not have an async sftp upload API yet. It is on the TODO list ... Is it still in the TODO list ? ;) I've experienced the same issue with Dolphin 17.12 (KDE Neon user Edition) The upload transfer rate is about 2/3 MB/s with Dolphin and 18/19 MB/s with command line. *** Bug 320231 has been marked as a duplicate of this bug. *** Two PCs, both with gigabit LAN cards, both connected to a gigabit hub/switch/router, both with OpenSSH Server installed. Steps to replicate: 1. PC-1 has IP address 192.168.0.101 2. PC-2 has IP address 192.168.0.102 3. On PC-1, open Konsole (or whatever terminal application you use). 4. cd ~ (in my case, my home directory is /home/scott). 5. fallocate -l 1G test.img 6. On PC2: Open Dolphin, press CTRL + L (to make address bar editable). 7. On PC2, enter the following in the address bar: sftp://192.168.0.101/home/scott 8. On PC2, drag the file test.img to the desktop. 9. OBSERVE: it's painfully slow (around 6MB/s). It's pretty much the same result whether the transfer is done using sftp://192.168.0.101 or smb://192.168.0.101 within Dolphin. Now repeat the above, only this time using scp from the terminal: 1. On PC2, open Konsole (or whatever terminal application you use). 2. Enter: scp 192.168.0.1:/home/scott/test.img /tmp 3. OBSERVE: It utilizes the bandwidth of the network, around 110MB/s. It's approximately 22 times faster using scp from the terminal! What needs to be done to confirm this issue? Confirming doesn't really help; what helps is investigating and fixing it! :) Thanks Nate. Are there any good resources/references for someone with some C/C++ experience to get involved (perhaps with KIO to start with)? I'd love to get involved, even if it takes a while (this was was reported over 6 years ago after all). I'm pretty desperate to find someone willing to dig into these kinds of KIO issues and would be happy to personally help you get started! Check out https://community.kde.org/Get_Involved/development Feel free to send me email too whenever you need a hand. Nice one - and thank you very much! I should warn you that I'm probably quite "rusty" at the moment, but I've been keen to find something I can sink my teeth in to. I have fixed this sync API problem into Ultracopier, you can look source to see algorithm Would you be interesting in submitting a patch for KIO? I'd be happy to help guide you through the process! libssh-0.8.1 has been released and kio_sftp will be updated to gain performance improvements. Fixed with libssh 0.8 https://www.libssh.org/2018/09/21/libssh-0-8-3/ Reply to comment #14: I am not convinced that this bug should be closed based on "performance improvements" in libssh. If libssh was the cause of this issue, then using SFTP from the terminal would also suffer from the same performance issue (i.e. on a wired gigabit network, we'd be seeing transfer rates of 10MB/s instead of 60+MB/s). We would also see similar performance issues in other file managers (that also use the same version of libssh). Reply to comment #13: > Would you be interesting in submitting a patch for KIO? I'd be happy to help guide you through the process! If this question was directed at me - yes, I definitely would. First step for me will be setting up a development environment. I'll read through the links you provided. As others have experienced, dolphin transfers my files roughly 6 times slower than using pure scp or any other modern protocol. This should not be marked as resolved due to some minor upstream protocol changes. (In reply to Scott Deagan from comment #16) > Reply to comment #14: > > If libssh was the cause of this issue, then using > SFTP from the terminal would also suffer from the same performance issue Alas, it wouldn't. sftp, the terminal application, is based on openssh, not libssh. > We would also see similar performance issues in other > file managers (that also use the same version of libssh). I do not know of any other file managers that use libssh. I'm honestly not sure what you want to happen here. I, personally, haven't seen libssh perform on the same level as openssh, so I figure the biggest fixes need to be made in libssh. Having a bug open here will not make that happen. I'm seeing comparisons being made with scp, which is a completely different protocol to begin with. Apples and oranges. We can't really use openssh because openssh has no library interface to build integrated GUIs on top of. So what's to be done here exactly? Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! What info is needed here? I'm interested to know if the problem affect only small file, or big file too. If somebody can give me a simple KIO file transfer based on KUrl I can implement to Ultracopier to see if have same problem (to determine if the problem is KIO layer, Ultracopier have multiple mechanism of performance that's mostly fix the common GUI slow down) > So what's to be done here exactly?
Hi, Async open/close and of course read/write (but I think you have do this). http://ultracopier-wiki.first-world.info/wiki/General_documentation As you can see here: https://ultracopier.first-world.info/articles/security-speed-ultracopier-supercopier-teracopy-copyhandler.html You can by this way transfert over network. In general the copy software just do lineare transfer without prepare the next copy with previous opening file. And wait the end of close() call before start the next file. Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! New information was added with comment 23; changing status for inspection. Can confirm this. I'm uploading zip archive 128MB via SFTP to remote server. The results: 1) sftp console utility upload speed is 3.2 MB/s 2) dolphin upload speed is 350 KB/s Created attachment 149131 [details]
sftp console utility upload speed
sftp console utility upload speed
Created attachment 149132 [details]
dolphin upload speed
dolphin upload speed
Kubuntu 20.04, Plasma 5.18 LTS Unfortunately Kubuntu 20.04 ships outdated software that is no longer supported. Notably kio-extras and probably also libssh. I also tested Ubuntu 22.04 with Plasma 5.24. Bug still exists Created attachment 149137 [details]
kubuntu 22.04
Same issue here, always present in Manjaro KDE (3+ years). It seems in my case the upload speed is actually capped at ~274kb/s. SSH directly is 3-4Mb/s. November 2022, kubuntu 22.04, bug still exists, scp is faster than dolphin approximately 20 times. SCP upload speed 10.7 Mb/s and dolphin speed 500-600 Kb/s Created attachment 153550 [details]
scp console kubuntu 22.04 upload speed
Created attachment 153551 [details]
dolphin kubuntu 22.04 upload speed
I have tested it myself using openSUSE TW with Plasma 5.26.2, Frameworks 5.99, where I copied a ~ 300 MB png file via a wired ethernet connection to a local RaspberryPi server: * Dolphin 22.08.3: ~ 10 MB/s * scp: ~ 41 MB/s Note to the comment above: * Dolphin 22.08.3: ~ 10 MB/s ---> with fish:// * Dolphin 22.08.3: ~ 17 MB/s ---> with sftp:// Same issue over here. Using Dolphin with fish, it uploads files at 100 KB/s. However, using scp over command line, it uploaded files at 8 MB/s. This occurred while accessing the remote server over a WireGuard VNP connection. When I'm on the same network as the remote server and I don't need VPN connection, things improve quite a bit, but it's still significantly slower than scp command. Using Arch Linux and Dolphin 23.04.2. If there is anything else I can do to provide the info needed sort this issue out, please let me know. Alright, I was trying to clean up my disk and move stuff to the file server, and this time I wanted to do it with Dolphin instead of with rsync commands. Call me lazy... My setup is decent: [ Desktop: 12 core, 64 GB, fast SSD ] -- Gbit LAN -- [ Server: 8 core, mediocre SSD as bcache + big HDD ] With scp I usually see 80+ MB/s (>650 MBit/s) transfer rates. However with Dolphin / kio-extras/sftp I only got 14.6 MB/s (a bit over 100 MBit/s). That might feel ok if you transfer some pictures, but if there are many 60+ GB videos this is really slow. And many 60+ GB videos are definitely a reality in 2024. I'll attach a screenshot of the Dolphin transfer to back this up. So that's when I started googling for what's wrong, and I found this ticket. Having seen Harald's complaint that apples are being compared with oranges, I set out to make an apples-to-apples comparison: I cloned the libssh repo (commit 48d474f78c5f68471bf412a7dbf508ef52f77664), configured with CMake (mkdir build && cd build && cmake -DCMAKE_BUILD_TYPE=Release -DWITH_SFTP=True -DWITH_BENCHMARKS=True ..), installed some missing deps (cmocka, socket_wrapper, nss_wrapper, uid_wrapper, pam_wrapper) and built (make -j12). That gave me a neat "tests/benchmarks/benchmarks" executable. Its help text says "-9, --async-sftp-aio-upload Upload data using asynchronous SFTP AIO api (fast)", so I thought that must be what Dolphin / kio is using. But when I ran it, I got 3x the speed - 46 MB/s / 370 MBit/s: $ ./benchmarks --host pn-test@data --size 1000 --async-sftp-aio-upload ping RTT : 0.489000 ms SSH request times : 3.508000 ms ; 3.955000 ms ; 3.974000 ms SSH RTT : 3.812333 ms. Theoretical max BW (win=128K) : 33.575241 Mbps pn-test@data : benchmark_async_sftp_aio_upload : 370.660278 Mbps That was already much better than expected. But when I started tinkering with the "--chunk" size and "--prequests" (parallel requests) parameters I found that I could essentially saturate my Gigabit link by doubling either parameter (chunk size is 32k by default, found that in the source code, parallel requests is 20 by default): $ ./benchmarks --host pn-test@data --size 1000 --chunk=64000 --async-sftp-aio-upload ping RTT : 0.600000 ms SSH request times : 3.452000 ms ; 3.984000 ms ; 3.995000 ms SSH RTT : 3.810333 ms. Theoretical max BW (win=128K) : 33.592865 Mbps pn-test@data : benchmark_async_sftp_aio_upload : 767.680969 Mbps $ ./benchmarks --host pn-test@data --size 1000 --prequests=40 --async-sftp-aio-upload ping RTT : 1.421000 ms SSH request times : 3.476000 ms ; 3.996000 ms ; 3.987000 ms SSH RTT : 3.819667 ms. Theoretical max BW (win=128K) : 33.510777 Mbps pn-test@data : benchmark_async_sftp_aio_upload : 750.160156 Mbps Hope that helps narrowing down the issue. I might dig deeper into the source some time in winter and maybe I can find it, but since I've never done serious KDE development that will be a steep learning curve for me. I'd be happy to assist in any tests and benchmarking endeavours, if someone tries a fix and tells me how to build it. :) Created attachment 173496 [details]
Dolphin / kio-extra/sftp transferring below expected speed
libssh got a new async sftp API with version 0.11.0. See https://www.libssh.org/2024/08/08/libssh-0-11-0-release/ https://www.libssh.org/2023/09/07/wrapping-up-2023-gsoc/ There wont be a lot of distributions offering that version yet. However we plan to move KDE to the new API. I'm currently on vacation so I haven't started working on it yet. (In reply to Andreas Schneider from comment #42) > libssh got a new async sftp API with version 0.11.0. See > > https://www.libssh.org/2024/08/08/libssh-0-11-0-release/ > https://www.libssh.org/2023/09/07/wrapping-up-2023-gsoc/ Oh, I didn't realize it's that new! But that means either the old async API didn't work, or it's not used right by kio-extras. > There wont be a lot of distributions offering that version yet. Yep, that takes a while. Maybe a fallback would be an option, so that those with fast/up-to-date distros can already benefit, but it will still work for all others? I know, that's a lot of work... In any case, I've just filed a request for Gentoo, so I hope they will add libssh 0.11.0 soon (https://bugs.gentoo.org/939413). > However we plan to move KDE to the new API. I'm currently on vacation so I haven't > started working on it yet. Enjoy your vacation :) Let me know if there is anything I can do to help once you're back. FYI, Gentoo now has libssh in version 0.11.1 (see https://packages.gentoo.org/packages/net-libs/libssh ). So at least *some* KDE users could now profit from a vastly improved SFTP transfer speed if the new async API were to be adopted/used by kio-extra/sftp. As another data point and 1:1 comparison: # Using current kio-extra/sftp to upload 2000M via 2.5 GBit network $ head -c 2000M /dev/urandom >random_data $ echo "$(echo "scale=3; $(stat -c %s random_data) * 8 / (1024*1024*1000) / $(/usr/bin/time -f "%e" kioclient copy --overwrite random_data sftp://pn-test@data/data_cached/temp/random_data 2>&1)" | bc -l) Gbps" .734 Gbps # Using libssh 0.11.1 benchmark (default params) to upload 2000M via 2.5 GBit network pn@vision ~/git/libssh-mirror/build/tests/benchmarks $ ./benchmarks -9 -s 2000M -h pn-test@data ping RTT : 0.243000 ms SSH request times : 0.360000 ms ; 0.361000 ms ; 0.379000 ms SSH RTT : 0.366667 ms. Theoretical max BW (win=128K) : 349.090912 Mbps pn-test@data : benchmark_async_sftp_aio_upload : 2.246955 Gbps Result: 0.73 vs. 2.25 Gbps, a factor of 3. Created attachment 175715 [details] Dolphin / kio-extra/sftp transferring at expected speed with libssh 0.11 Sorry for the noise! But I just hadn't expected that the problem is already solved for everyone who has libssh 0.11 on their system! When I ran my test today, I had libssh 0.11.1, however by kio wasn't linked against it, yet. When I had a look at the source, I saw that Harald had already implemented a check for the availability of the new async API ( https://github.com/KDE/kio-extras/commit/0acc82a91f247e0171cbbb54bb1408b907542112#diff-77bd8595c0f059a3f86db48c0c9ff5307330f67f39ace668ea211c11985453a6R9 ) and its usage. So after I rebuilt kde-apps/kio-extras - voila: moving files to my NAS with Dolphin at >200 MiB/s. Thanks!! Patrick, what distro do you use? |