Separate data table
The benchmark numbers live in a small structured table, separate from the marketing copy. Adding a new device means appending a row with CPU, OS, .NET version, profile, source file, and measured MB/s values.
Benchmarks
Benchmarks that explain real deployment ceilings.
A throughput number only matters when you know what it actually measured. Cotton publishes reviewed baseline rows beside common network ceilings and uses the slowest local write stage for public network-fit claims.
Benchmark scope
The benchmark suite exercises real Cotton storage components: SHA-256 hashing for content addressing, Zstd compression/decompression, AES-GCM crypto processors, filesystem backend I/O, and a synthetic compression-plus-encryption pipeline.
- Machine mode baselines do not include browser upload, HTTP multipart, PostgreSQL, chunk ownership, manifest creation, progress machinery, TLS, or app-level concurrency.
- Machine mode baselines do not require PostgreSQL.
- Quick profiles are cheaper for low-power devices.
- Standard profiles give stronger local regression evidence.
Network ceiling context
100 MbE, 1 GbE, 2.5 GbE, and 10 GbE are listed as MB/s ceilings because that is how storage benchmarks are easier to read. Around 280 MB/s is the practical target for 2.5 GbE; 10 GbE needs roughly 1.1 GB/s after overhead.
How to read the table
The strongest number is not always the right number. AES-GCM can be fast while compression, hashing, or disk is the real limiter. The network-fit column therefore uses the slowest measured local write stage, not the synthetic pipeline average and not an isolated crypto result.
What to add next
The useful future rows are weak ARM NAS, low-end cloud VM, midrange mini PC, SATA SSD NAS, NVMe desktop, and 10 GbE server. Those rows will show where Cotton stays network-bound and where hardware starts to matter.
What the baselines measure
The benchmark page keeps local stage measurements separate: SHA-256, Zstd compression, AES-GCM encryption, filesystem I/O, synthetic pipeline, and read-side stages. Public coverage uses the slowest write-path stage.
Speed without hand waving
Cotton can talk about speed without hand waving. The table shows whether a machine is likely to cover common network ceilings and names the stage that actually limits ingest processing.
Still not live upload math
Machine baselines are not live end-to-end upload promises. Browser behavior, HTTP, TLS, PostgreSQL, manifest creation, storage backend latency, file mix, and concurrency still shape production throughput.
Measured baselines
Reviewed numbers, not a hero claim.
Each row is loaded from committed Cotton JSON baselines under performance/baselines, with site fallback rows for network or cache failures. New machine-standard baselines appear after the five-minute revalidation window; rows are ordered from weakest to strongest estimated write-path processing limit.
Choose your link
Match Cotton baselines to your network.
Pick the network you actually run. The comparison uses the slowest measured local write stage, because isolated crypto speed does not matter if hashing, compression, or filesystem I/O is slower.
These rows are real machine-standard runs from the Cotton benchmark harness, not hand-entered hero numbers. The public baseline JSON files live on GitHub, and the site revalidates them every five minutes.
Selected network1 GbE
Practical ceiling112 MB/s
Raw line rate125 MB/s
Common home NAS and small office baseline. Compression, crypto, and disk only need low hundreds of MB/s to stay ahead.
Intel Celeron J3355 NAS82.2 MB/slimited by Zstd compression
covers 0.7x
Estimated write-path processing limit versus 1 GbE practical ceiling of 112 MB/s. Uses the slowest measured local stage: SHA-256, Zstd compression, AES-GCM encryption, or filesystem I/O.
Intel N100 mini server150 MB/slimited by Zstd compression
covers 1.3x
Estimated write-path processing limit versus 1 GbE practical ceiling of 112 MB/s. Uses the slowest measured local stage: SHA-256, Zstd compression, AES-GCM encryption, or filesystem I/O.
Intel Xeon E-2236 server448 MB/slimited by Zstd compression
covers 4.0x
Estimated write-path processing limit versus 1 GbE practical ceiling of 112 MB/s. Uses the slowest measured local stage: SHA-256, Zstd compression, AES-GCM encryption, or filesystem I/O.
Intel Core i5-12450H laptop572 MB/slimited by Zstd compression
covers 5.1x
Estimated write-path processing limit versus 1 GbE practical ceiling of 112 MB/s. Uses the slowest measured local stage: SHA-256, Zstd compression, AES-GCM encryption, or filesystem I/O.
Intel Core i7-14700F desktop593 MB/slimited by Zstd compression
covers 5.3x
Estimated write-path processing limit versus 1 GbE practical ceiling of 112 MB/s. Uses the slowest measured local stage: SHA-256, Zstd compression, AES-GCM encryption, or filesystem I/O.
Intel Core i9-13900K desktop884 MB/slimited by Zstd compression
covers 7.9x
Estimated write-path processing limit versus 1 GbE practical ceiling of 112 MB/s. Uses the slowest measured local stage: SHA-256, Zstd compression, AES-GCM encryption, or filesystem I/O.
| Machine | Profile | Network fit | Write-path limit | SHA-256 hashing | Zstd compression | AES-GCM encrypt | Filesystem I/O | Synthetic pipeline | Zstd decompression | AES-GCM decrypt | Source |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Intel Celeron J3355 NASIntel(R) Celeron(R) CPU J3355 @ 2.00GHz / 2 threads / Ubuntu 24.04.4 LTS | standard.NET 10.0.8 / May 24, 2026 | 100 MbEby slowest local write stage | 82.2 MB/slimited by Zstd compression | 536 MB/s | 82.2 MB/s | 251 MB/s | 629 MB/s | 369 MB/s | 188 MB/s | 286 MB/s | performance/baselines/linux-x64-intel-r-celeron-r-cpu-j3355-2-00ghz-dotnet10.machine.standard.json |
| Intel N100 mini serverIntel(R) N100 / 4 threads / Ubuntu 24.04.4 LTS | standard.NET 10.0.7 / May 24, 2026 | 1 GbEby slowest local write stage | 150 MB/slimited by Zstd compression | 1.24 GB/s | 150 MB/s | 447 MB/s | 1.14 GB/s | 817 MB/s | 308 MB/s | 471 MB/s | performance/baselines/linux-x64-intel-r-n100-dotnet10.machine.standard.json |
| Intel Xeon E-2236 serverIntel(R) Xeon(R) E-2236 CPU @ 3.40GHz / 12 threads / Ubuntu 24.04.3 LTS | standard.NET 10.0.8 / May 24, 2026 | 2.5 GbEby slowest local write stage | 448 MB/slimited by Zstd compression | 541 MB/s | 448 MB/s | 1.32 GB/s | 2.31 GB/s | 2.05 GB/s | 801 MB/s | 1.29 GB/s | performance/baselines/linux-x64-intel-r-xeon-r-e-2236-cpu-3-40ghz-dotnet10.machine.standard.json |
| Intel Core i5-12450H laptop12th Gen Intel(R) Core(TM) i5-12450H / 12 threads / Ubuntu 24.04.3 LTS | standard.NET 10.0.8 / May 24, 2026 | 2.5 GbEby slowest local write stage | 572 MB/slimited by Zstd compression | 2.00 GB/s | 572 MB/s | 1.49 GB/s | 2.72 GB/s | 2.45 GB/s | 966 MB/s | 1.53 GB/s | performance/baselines/linux-x64-12th-gen-intel-r-core-tm-i5-12450h-dotnet10.machine.standard.json |
| Intel Core i7-14700F desktop14th Gen Intel(R) Core(TM) i7-14700F / 28 threads / Microsoft Windows 10.0.26200 | standard.NET 10.0.7 / May 22, 2026 | 2.5 GbEby slowest local write stage | 593 MB/slimited by Zstd compression | 2.39 GB/s | 593 MB/s | 2.06 GB/s | 1.91 GB/s | 3.07 GB/s | 1.14 GB/s | 2.38 GB/s | performance/baselines/windows-x64-14th-gen-intel-r-core-tm-i7-14700f-dotnet10.machine.standard.json |
| Intel Core i9-13900K desktop13th Gen Intel(R) Core(TM) i9-13900K / 32 threads / Microsoft Windows 10.0.26200 | standard.NET 10.0.8 / Jun 01, 2026 | 2.5 GbEby slowest local write stage | 884 MB/slimited by Zstd compression | 2.53 GB/s | 884 MB/s | 2.14 GB/s | 1.45 GB/s | 3.04 GB/s | 1.26 GB/s | 2.11 GB/s | performance/baselines/windows-x64-13th-gen-intel-r-core-tm-i9-13900k-dotnet10.machine.standard.json |
Older low-power Celeron baseline. Useful for showing where the local write path can fall below 1 GbE on compressible ingest.
Small mini-server baseline. The conservative write-path limit covers 1 GbE, while 2.5 GbE needs more compression headroom.
Server CPU baseline. The slowest measured write stage clears practical 2.5 GbE, but it is not a 10 GbE ingest claim.
Mobile CPU baseline. The conservative write-path limit clears practical 2.5 GbE with room for normal deployment overhead.
Desktop baseline. Compression is the conservative write-path limiter, still above practical 2.5 GbE.
High-end desktop baseline. The slowest write stage has strong 2.5 GbE headroom, while 10 GbE remains a full-system target.
FAQ
Direct answers
Why show network ceilings on a benchmark page?
Because users think in network speed when they deploy a file cloud. The public comparison uses the estimated write-path processing limit: the slowest measured SHA-256, Zstd compression, AES-GCM encryption, or filesystem I/O stage. About 280 MB/s covers practical 2.5 GbE; 10 GbE needs about 1.1 GB/s or more after overhead.
Are these benchmark numbers promises?
No. They are reviewed baselines for specific machines and profiles. Real deployments depend on CPU, disk, filesystem, S3 latency, network, TLS, Docker settings, file types, and concurrency.
Why use the slowest write-path stage for coverage?
Because it avoids turning a synthetic pipeline number into a public upload promise. SHA-256, Zstd compression, AES-GCM encryption, and filesystem I/O all need enough local headroom.