martin wrote:

@6433567: Would you please describe what the "information" should represent? Thanks.

Only this:

@6433567: Would you please describe what the "information" should represent? Thanks.

There is such information:

txt C.20 classical stream cipher, without Poly1305.

The guest is x86-64, not ARM.

I can show again, but it's not required. The speed starts from high and drops to 500-200 KB/s, but rises to 200-7000 KB/s for a short time and falls again. If I take a larger example file, the speed on some segment of the downloaded file will drop to 500-200 KB/s for a constant time and the average speed will be lower in the log. I think in the log, the average download speed is shown. But I'm not sure 100%.

Everything is the same as in the previous examples 500-200 KB/s (except guest). With SFTP (ARM) between AES and C.20, not only the speed is different, but the CPU load is different. Which is not the case with SCP between AES and C.20.

Sorry, I do not know.
Though in your last log, there actually is a big speed difference between AES and ChaCha20 (AES being 70% faster – what might not be the expected result). And actually the speed (1,2–2 MB/s) is much higher than what you claim.

AES hardware encryption in my CPU (AMD) has.

PC, CPU created in 2014 year.

I don't know how hardware encryption works in CPUs. CPU created in 2014 year.

This is not a problem for me as I can also use ftp, sftp, ftps. For me, the only thing that is not clear is why there is no difference between AES and C.20 with SCP. In SFTP, there is a difference between AES and C.20 in download speed and CPU load where there is no hardware AES in the CPU. PCs have hardware AES encryption in the CPU, but hardware encryption works in the CPU, when I did the example in virtualization, I don't know.

Ok, I do not see any configuration problem in the log. So indeed it looks like the CPU is the limiting factor. Not much we can do about this atm. We plan to use better compiler in the next major release, what hopefully makes this better. But it will take time to upgrade.

x86-64

SCP. Guest Linux openssh 1:8.9p1-3ubuntu0.6, lan bridge, router. Downloading from guest VB.exe (host) the CPU is 40% loaded, guest the CPU is 100% loaded one core (4 cores guest), htop. I've been changing encryption methods, download speed and CPU (x4 1500MHz 86_64) the loads are identical. I forgot when I made the log that the settings for directories have been changed. The rest is default.

It doesn't matter that the file is downloaded from shm or USB Flash, the speed still drops to ~500-256 KB/s.

There's no file transfer in the logs.
Also, please use Normal logging level for now.

I opened a few folders and went out. Does it fit? D.2

Please post logs both with defaults and C.20.

"From what I see..." I'm not 100% sure about that. This is an assumption.

Yes, but it's not a network problem. From what I can see. The processor core (1) is not powerful enough to process AES encryption, which slows down the transfer rate. But, if for SFTP (SSH) changing the encryption to C.20 helps. The load on the CPU core drops significantly and the file transfer speed does not drop, then for SCP (SSH) changing the encryption method from AES to C.20 does not change anything, or it doesn't change much. I did it. Nothing has changed.

I assume you have transfer speed problem, right?
As the CPU seems to be the bottleneck, did you try to use transfer queue/background transfer to make use of multiple CPU cores?
https://winscp.net/eng/docs/faq_slow#transfer_queue

I have already done this, changed the encryption algorithm for SCP (ssh) to C.20, nothing has changed. I changed the encryption algorithm for SFTP (ssh), it got better. FTP without encryption for my hardware is still faster to transfer files and less CPU load if encryption is unnecessary.

SFTP. CPU: one core load 80–100%.

I confused the example made with FileZilla this is FTPS, not SFTP.

openssh-server 1:8.4p1-5+deb11u3. I didn't know it was openssh-sftp-server 1:8.4p1-5+deb11u3 installed. With WinSCP sftp speed ~7,20 - 6,20 MB/s.

Which I saw and did. FTP is fine with me, but in order to use FTP, I needed to install and configure vsftpd — done. Encryption is unnecessary for me, for transferring files over a local network between my devices.