Post a reply

Before posting, please read how to report bug or request support effectively.

Bug reports without an attached log file are usually useless.

Options
Add an Attachment

If you do not want to add an Attachment to your Post, please leave the Fields blank.

(maximum 10 MB; please compress large files; only common media, archive, text and programming file formats are allowed)

Options

Topic review

retardate

Did some more transfer today with the new version.
Download speed to SSD is ~9 MB/s, pause resume made no big difference, basically stabled at ~9MB/s.
When download to the sdcard the pause and resume only increased the speed to ~20 MB/s shortly then the speed stabled at ~9 MB/s eventually, buffer on/off makes no obvious difference.
Task manager & Wifi status shows 400 mbps bandwidth got utilized accordingly(9MB/s transfer shows ~72 mbps receive).
Previous conclusions were made from multiple 10MB ~ 3GB file transfers multiple times, resulting patterns were very stable, I don't know why today's transfer yield different results. I did not change any configuration, only difference was on client side, which was having multiple torrent downloads going on, other than winscp file transfer the whole client system was using 3.1 mbps bandwidth ~2% CPU ~1% Disk which was very far from saturating the system.
I don't know anymore.
Retardate

For both new and old version of the winscp, when downloading files to sdcard, cancel then resume the transfer increased transfer speed from ~8 MB/s to ~23 MB/s still stands true. Without the intervention transfer speed still remained at ~8 MB/s even on new version.
retardate

So it's not the new version improved it.

Download from server to client's sdcard(through usb cardreader) resulting 4~8 MB/s transfer speed, instead of that if I download to client SSD it's ~23 MB/s.

Still, it's over an ~400 mbps(/8 = ~50 MB/s) wifi and not saturating the wifi during the transfer so it's not the overhead, and the sdcard got ~60 MB/s read/write when doing transfers with ssd.

Is there something reserving/rationing the bandwidth?
retardate

5.21 seems to have improved the transfer speed.
Downloads are slowly rise and stabled at ~21 MB/s without the pause and resume(task manager shows ~200 mbps Receive on a 433 mbps bandwidth 5G wifi, nothing is occupying significant amount of bandwidth), server CPU utilization was at 30~40 %, and the pause and resume made no difference this time.
Uploads were at ~33 MB/s(task manager shows ~300 mbps Send).
Optimize buffer on/off makes no obvious difference.
I have downloaded and uploaded to the same server through USB cable before, read/write was 40+ MB/s.
martin

Re: 5.19.6 - sftp, Cancel then resume transfer increase transfer speed from 7~8 MB to ~20MB

Please post session logs as level Debug 1 for both scenarios.
retardate

Uploading at ~20MB/s though it's still not enough to saturate the bandwidth
retardate

It seems to affect only the downloading from server to client, not uploading from client to server.
Retardate

None of the other methods have more consistent and significant impact on transfer speed than this. (Tested Optimise buffer size On/Off, edit raw config SFTPdownloadQueue=128, etc)

Server CPU got utilized ~40% when transfer speed hit ~20 MB/s(with compression on CPU utilization hit 90+% and the transfer speed reduced to 13~17 MB/s), CPU still got more room for it with compression off.

Copy files from server to client through USB cable can transfer at 40~50 MB/s, so it's definitely not saturating servers storage read speed.
SCP capped at 10 MB/s after disable Optimise buffer.
Guest

Android hotspot + Termux OpenSSH SFTP on an Android device as server(if I typed ssl before that was a mistake)
retardate

over 5G wifi ~400 Mbps bandwidth, Task Manager shows ~200 Mbps got utilized when the transfer speed reach ~20 MB, still not enough to saturate the bandwidth.
retardate

5.19.6 - sftp, Cancel then resume transfer increase transfer speed from 7~8 MB to ~20MB

Android termux openssl sftp as server