• Test Reports
• ›
• Comparative battery 2026-10-03

Comparative battery 2026-10-03 ​

Three command-line clients, the same four servers, the same files, the same link, back to back. Every download was checked against its source before its time was counted. The method is described in Comparative benchmarks.

How to read these numbers ​

• Ratios are the other tool's median seconds over AeroFTP's median seconds. Above 1.00, AeroFTP was faster in this battery; below 1.00, slower.
• Each cell shows every counted run. Two runs per tool are a pair, not a statistic: on this link identical FTP runs differed by up to 42 percent in the September review, so a ratio near 1.00 is a tie.
• A time is counted only if the integrity check passed. For the 300 MiB file that is a SHA-256 of the download against the source; for the tree it is a SHA-256 of every file. A failed check is shown as a failure, not as a time: a client that gives up early looks fast.
• This is one link and one set of servers. A wired fibre line and a lab server about 47 ms away. It is not a ranking of clients in general.

Setup ​

• Station: one Linux desktop, 12 cores, wired gigabit to a fibre line. Each pass started only after the station had been quiet for 45 seconds (no compiler or test runner from other work, CPU under 35 percent), and every row records the load at its start.
• Servers: one remote lab server running MinIO (S3), Apache mod_dav behind nginx (WebDAV), OpenSSH (SFTP) and vsftpd with explicit TLS (FTP).
• Payloads: one 300 MiB file of random bytes, and a tree of 200 random files of 20 to 80 KB in three folders (about 9.9 MB). New random data for every pass.
• Configuration: the rclone remotes and the Cyberduck bookmarks were exported from the same AeroFTP profiles with aeroftp-cli export rclone and aeroftp-cli export cyberduck, so the three tools reached the same endpoints with the same credentials and TLS mode.
• Commands, defaults unless stated:

With their default settings, AeroFTP and rclone both ask for 4 ranges on a single download larger than about 250 MiB, so the 300 MiB download is meant to be multi-stream for both. For S3 the section below checks it with a connection count.

Results ​

Seconds, lower is better. Each cell lists the counted runs of both passes. Every run in these tables passed its integrity check; the load average at the start of each run stayed between 0.57 and 4.62 on 12 cores, and each pass started only once the CPU had been under 35 percent for 45 seconds.

S3 (MinIO) ​

WebDAV ​

SFTP ​

FTP, explicit TLS ​

What these tables show on this link:

• Many small files: AeroFTP was faster on every tree upload (S3 2.18, WebDAV 2.47, SFTP 2.30, FTP 5.04) and on the SFTP tree download (1.83). The FTP and WebDAV tree downloads were about level (1.07, 0.91). The S3 tree download was the one tree cell where rclone was clearly faster (0.74).
• One large file: the S3, WebDAV and FTP uploads were level or ahead (1.02, 0.95, 1.20) and the WebDAV and FTP downloads about level (1.07, 0.93). rclone was faster on the S3 download (0.72) and on both SFTP directions (0.50 upload, 0.79 download).
• Cyberduck CLI was slower than AeroFTP in every cell it completed except the SFTP upload of the large file (0.87), and completed no FTP transfer (see below).

Peak memory ​

Resident memory at its peak, in MB, the highest of the counted runs.

AeroFTP stayed between 79 and 84 MB on every cell but two: the S3 upload of the large file, which is a multipart upload (211 MB here; 262 MB in September, before aeroftp#882), and the SFTP download of the large file (162 MB). rclone stayed between 55 and 79 MB. Cyberduck CLI runs on a Java runtime and peaked between 224 and 572 MB.

S3: one stream against four ​

One 300 MiB object on MinIO, downloaded by AeroFTP with --multi-thread-streams 1 and with 4 (its default), two runs each in alternating order, with rclone and its defaults as the control in the same window. During every AeroFTP run a sampler counted the TCP connections the process held to the S3 endpoint, so an arm labelled four streams is shown to open four.

Four streams were faster than one by about 37 percent on the medians (30.88 s to 19.48 s). Four connections were open during each four-stream run and one during each single-stream run, which is consistent with the four range requests the code plans for this size; the requests themselves were not logged. The two four-stream runs differ by half, so the size of the gain is uncertain; its direction is not. With four streams AeroFTP stayed behind rclone on this object (ratio 0.73 on the medians), consistent with the S3 download row above.

Interoperability findings ​

FTP with TLS: Cyberduck CLI cannot transfer against this server ​

duck 9.5.4 connects, authenticates and lists over explicit TLS, then fails every transfer, in both passes. On download the server answers 522 SSL connection failed: session reuse required: vsftpd requires each data connection to resume the TLS session of the control connection, and duck's data connections do not. On upload the server closes the connection without a message, which is consistent with the same requirement. duck exits 1 on every FTP cell, so no duck time is reported for FTP. In September a failed duck upload left a zero-byte file on the server, which another client then reads as a real file.

AeroFTP and rclone both complete over explicit TLS against the same server, the lab's vsftpd 3.0.5, which requires every data connection to reuse the control connection's TLS session (require_ssl_reuse, on by default). rclone completes only with TLS 1.3 disabled (disable_tls13): in September, rclone v1.74.0 with TLS 1.3 enabled failed with 426 Failure reading network stream, and on one tree download it exited 0 after delivering 16 of 200 files. That is what this server and these versions did, not a property of TLS 1.3 in general. AeroFTP caps FTP over TLS at TLS 1.2 because, with its TLS library, a TLS 1.3 session ticket is consumed when used and a second data connection would resume a different session than the control connection; aeroftp-cli export rclone writes disable_tls13 for every FTP remote with TLS since 4.2.0.

WebDAV: a redirect from HTTPS to HTTP ​

The lab's WebDAV server sits behind a TLS-terminating proxy, and it answered a folder path without a trailing slash with a redirect to the same path over plain http://. rclone 1.75.1 refuses to follow it, because it would send the credentials in cleartext; rclone 1.74.0, used in September, completed the same cells against this server. AeroFTP 4.2.1 did not hit the redirect in these operations. Since aeroftp#1011, merged after 4.2.1, AeroFTP also refuses to follow a redirect from HTTPS to HTTP and names the server misconfiguration in the error. The proxy was corrected before the WebDAV cells were measured (one proxy_redirect line), so every tool ran against the same, correct server.

The previous run, 19 September 2026 ​

The same harness ran on 19 September on a build between 4.1.9 and 4.2.0 (the head of aeroftp#880 at f9eaa87b), with rclone v1.74.0 and duck 9.5.4, one run per cell. Three of its findings changed the code before 4.2.0 shipped, which is why it is kept here rather than as its own page:

• S3 downloads never split. The 300 MiB S3 download read 31.51 s against rclone's 16.95 s. The multi-stream path took the object size from a HEAD response through a call that always returns 0 for HEAD, so every S3 download ran on one stream while the client announced four. aeroftp#881 fixed it, and also pins every range request to the object's ETag so a file replaced during the download cannot be assembled from two versions. That 31.51 s describes the broken path and is not a before for the table above.
• S3 multipart upload memory. The same upload peaked at 262 MB of RSS against rclone's 68 MB, while every other AeroFTP cell stayed between 77 and 81 MB. Part buffers came from glibc per-thread arenas and were kept after release. aeroftp#882 sends them to mmap: on a 1 GiB upload with 16 MiB parts, three runs went from 295 to 312 MB down to 139 to 141 MB, with the same wall time.
• FTP with TLS needed an exporter fix to be comparable at all. In the first FTP session the exported rclone remote used explicit TLS without disable_tls13, and rclone failed against vsftpd, which requires the data connection to resume the control connection's TLS session. It exited 0 on a tree download that delivered 16 of 200 files. aeroftp#880 makes the exporter write disable_tls13 for every FTP remote with TLS. That session is not counted anywhere.

Declared limits ​

• One station, one link, one lab server. Results on another link or against commercial providers can differ in both directions.
• Two runs per tool and cell. They show the spread of this window; they are not enough for a confidence interval.
• The tools run in sequence inside each operation, and the order was reversed in the second pass so that a drift over time does not always land on the same tool.
• AeroFTP unlocks its encrypted profile vault on every invocation, a cost rclone and Cyberduck do not pay with plain configuration files. It is included in every AeroFTP time.
• Cyberduck CLI is the command-line build of Cyberduck. These numbers say nothing about the Cyberduck desktop application.