Preprint

Preprint: Fast networks were only part of the picture in Earth-observation tests

An on-premises system built around a 100 GbE fabric moved data at high aggregate speeds, while measured throughput varied with endpoint hardware and remote network paths.

A preprint on Earth-observation data access reports that a fast local network was only part of the performance equation. In the tests, R6525 application nodes averaged 176 Gbps per node, or 44% of bond capacity, while R750 storage nodes reached 86% and an R7625 fan-out test reached 94.5% of a 400-Gbps bond.

The system was evaluated at the AIR Data Centre as a replicable on-premises setup using MinIO object storage on a 100 GbE fabric, PostGIS metadata and an OGC API-EDR access layer. The local benchmark covered eight storage nodes and three application nodes. A separate remote campaign covered 63 sites: seven institutional sites and 56 public-cloud regions.

A powerful fabric, with hardware limits

At the network level, a symmetric R750 load reached 1,379 Gbps, or 86% of theoretical capacity. The operational 3→8 configuration reached 529 Gbps. Three errors were recorded across 15.88 billion packets, an error rate of 1.9 × 10−10, and single-point link failures recovered automatically.

Network tests used iperf3 with eight parallel TCP streams, 120-second sessions and three repetitions. Storage tests used warp for sustained S3 PUT and GET runs of 120 seconds, repeated three times, at four object sizes: 4 MiB, 64 MiB, 512 MiB and 2 GiB.

Across the distributed storage tests, GET throughput stayed between 17,287 and 18,867 MiB/s, while PUT throughput reached 16,544 MiB/s for a 2-GiB object.

Changing the per-server network rate produced a steep fall in 512-MiB PUT throughput: 15,954 MiB/s at 100 Gbps, 2,334 MiB/s at 10 Gbps and 232 MiB/s at 1 Gbps. The reported network-bound regime is below 10 Gbps per server, but the exact transition was not measured; it lies somewhere between 10 and 100 Gbps in these tests.

At the lowest rate, the test also reduced client concurrency from 32 connections to four, making the 1-Gbps comparison a combined bandwidth-and-concurrency condition rather than a bandwidth-only test. In mixed workloads with a 3:1 GET-to-PUT ratio, combined throughput was 18,453–19,085 MiB/s, while GET time-to-first-byte—the delay before the first data arrived—was 2.5–6.3 ms at 100 Gbps.

The route mattered, too

For remote replication, the benchmark measured time to destination visibility, checked MD5 checksums and polled every two seconds for up to 600 seconds. The campaign included 567 runs across 63 sites; 11 runs were censored, all for 512-MiB objects.

When institutional sites were compared with cloud regions in bands within ±30 ms of round-trip time, or RTT, six of seven institutional sites exceeded the cloud-band median for 4-MiB chunks. AWS Europe medians were 20% to 37% higher than GCP Europe medians, depending on object size. The paper reports that replication rate tracked network path class more closely than RTT alone.

But the remote test did not characterize the partner-side endpoint, so the measurements cannot by themselves identify the cause of a remote replication limit.

A benchmark with boundaries

Per-node diagnostics also exposed problems that aggregate results could conceal. A CPU-boost configuration error left st04 at 84 Gbps, 22% below the cluster mean; application-workload contention was associated with 1,700 retransmits; and st06, with SACK disabled, recorded 95% lower small-object GET throughput. BBR-to-cubic drift appeared on four of eight storage nodes, and some anomalies were corrected before the final distributed GET results were collected.

The findings are best read as infrastructure benchmarks for this deployment. The application tier had three nodes, the local tests used synthetic rather than production workloads, and the reported values are infrastructure ceilings rather than quantified end-user performance. The remote measurements characterized the AIR Data Centre end rather than fully instrumenting partner endpoints.

The results therefore do not establish that the same 100-GbE design will perform similarly elsewhere. They show why network capacity, endpoint configuration and network path need to be considered together when assessing Earth-observation infrastructure, while remaining specific to the tested hardware and routes.

Paper data and sources

Original title: Design and Empirical Evaluation of a Network-Centric, On-Premises Architecture for Earth Observation Data Access
Authors: João Pinelo, João Gonçalves, Denis Willett et al.
Journal/Repository: arXiv
Status: Preprint, not yet peer-reviewed
First online: 2026-08-20
DOI: Not available
Original paper · Full text

Versions and corrections

  1. Published automatically after legal-source, freshness, evidence, and independent-verification gates passed.