• Test Reports
• ›
• Community Benchmark
• ›
• 2026-05-07 baseline

Community Benchmark, first round (v3.7.3 / v3.7.4) ​

This page is the maintainer-side reference run for the AeroFTP Community Benchmark initiative announced in issue #177. It is a single-host, single-residential-uplink sample published as a baseline, not as a population-level benchmark. Selection bias is explicit in section 9.

Downloads ​

• REPORT.pdf: 7-page A4 maintainer-side report.
• aeroftp-bench-2026-05-07-baseline.zip: full sanitized dataset (35 JSON, 4 CSV, rankings, manifests).

1. Why this round exists ​

When AeroFTP claims that one protocol is faster than another on a given provider, that claim should be defensible. A single fiber line in a single timezone is not a credible base for a public protocol comparison page. Issue #177 invites the community to run the same matrix against their own profiles and submit a sanitized JSON report.

Before asking other people to do that, the maintainer ran the matrix on every profile saved on the development host. The output of that exercise is the dataset and bar charts below, plus the bug fixes the sweep surfaced.

2. Matrix ​

The main sweep uses the new benchmark custom subcommand introduced in v3.7.3:

aeroftp-cli --profile "<name>" benchmark custom \
  --sizes 1M,10M,100M,1G --runs 3 \
  --consent-publish --report <out>.json

Each (size, run) tuple exercises five operations: upload, download, list, stat, delete. Numbers are reported as p50/p95/min/max/stddev per operation, not as arithmetic means. The CLI runs a sanitization pass before writing the JSON: if any path, hostname, account, bucket name, IP, MAC, token or fingerprint slips through, the report is rejected, not anonymized post-hoc.

3. Coverage ​

4. Bug fixes shipped because of this sweep ​

The sweep itself acted as a stress test of the rest of the codebase. Every defect surfaced was fixed before publishing the dataset. The fixes are split between the v3.7.3 patch queue (commits 253f2cc2 + 8e0f0b8f) and the v3.7.4 release (22a4bd8f, d16a63cc, cb1e80b6).

5. Throughput rankings ​

Bars are p50 across 3 runs, scaled per chart (the longest bar in each chart is the chart's max, not an absolute Mbps). The number after the bar is p50, the right-aligned smaller number is p95.

Payload 1 MiB

Payload 10 MiB

Payload 100 MiB

Payload 1 GiB

Two non-obvious takeaways:

1. Asymmetry is real. The same provider can rank top-3 on upload and bottom-3 on download (Azure Blob), or vice-versa (Google S3). A single-direction benchmark would mislead.
2. The S3 protocol is not universally fastest. Native APIs (pCloud, Jotta, Dropbox) win the 1 GiB upload bracket. The S3-as-backend assumption breaks here.

6. Verification round (post-v3.7.4) ​

Three profiles failed in the main v3.7.3 sweep with errors that were AeroFTP bugs, not provider limits. The v3.7.4 release plus one in-queue commit (cb1e80b6) fixed them. The verify round below was run on a v3.7.4 build that includes that pending commit, with the 100 MiB cap matrix (custom --sizes 1M,10M,100M --runs 2) to confirm the fixes hold without re-burning bandwidth on 1 GiB payloads.

While re-running Drime, a smaller bug was surfaced and fixed in the same session: Drime's mkdir() returned a generic ServerError when the API answered 422 Unprocessable Entity with "Folder with same name already exists.", so the benchmark command logged a cosmetic warning even though the directory existed and the run continued normally. The provider now maps that exact response to ProviderError::AlreadyExists, which the benchmark already treats as idempotent. Pending in queue for the next release.

7. Known open bugs not in this round ​

8. How to reproduce ​

# Same CLI binary or rebuild from main post-v3.7.4
CLI=/path/to/aeroftp-cli

# Single profile
"$CLI" --profile "AWS" benchmark custom \
  --sizes 1M,10M,100M,1G --runs 3 \
  --consent-publish --report ./AWS.json

The --consent-publish flag wraps the JSON in BEGIN AEROFTP BENCHMARK REPORT / END AEROFTP BENCHMARK REPORT markers and runs the sanitization sweep. If anything that would identify the host or the account makes it past the per-provider redactor, the command refuses to write the report. You will not produce a poisoned report by accident.

9. Selection bias and disclaimers ​

This dataset was produced on:

• Single host (Linux x86_64, kernel 6.8, Ubuntu 24.04 LTS)
• Single uplink (residential WE fiber, asymmetric ~4 MB/s up / ~3.5 MB/s down nominal)
• Single timezone (UTC+02, all runs in one ~36 h window)
• Single AeroFTP version (v3.7.3 build for the main sweep, v3.7.4 build for the verify round)

It is a baseline for what one developer measures from one location with one binary. The community benchmark page on docs.aeroftp.app will only draw protocol-level conclusions after aggregating community submissions across at least three regions and two connection types. Any conclusion drawn from this dataset alone is provisional.