Streaming Speed Score in Remote HPC

• Streaming Speed Score is a quantitative tail-latency ratio that compares worst-case observed transfer times with the theoretical minimum under ideal conditions.
• The metric integrates transfer efficiency, remote processing power, and file I/O overhead, providing a robust indicator for the feasibility of streaming in high-performance scientific workflows.
• Empirical evaluations on high-speed links reveal that low SSS values enable real-time processing, while elevated scores under congestion can lead to significant delays in remote HPC tasks.

Streaming Speed Score (SSS) is a quantitative metric introduced for evaluating whether remote high-performance computing can support timely processing of streamed scientific data relative to local processing and file-based remote workflows. In the underlying framework, SSS measures the ratio between worst-case observed transfer time and the theoretical minimum transfer time, and it is used alongside a completion-time model that incorporates transfer efficiency, remote processing power, and file input/output overhead to identify operational regimes in which streaming is beneficial (Castro et al., 23 Sep 2025).

1. Definition and problem domain

The metric arises in the context of remote HPC processing for time-sensitive scientific workflows. The motivating problem is that modern scientific instruments generate data at rates that can exceed local compute capabilities, while file-based use of remote HPC resources can become impractical because of staging and I/O overheads. The framework therefore compares three alternatives: local processing, remote processing via streaming, and remote processing via file-based transfer (Castro et al., 23 Sep 2025).

Within this setting, the central quantity is the total processing completion time, denoted $T_{pct}$. The framework is explicitly designed to assess whether streaming can provide timely processing when data must be transferred over a network and analyzed remotely. The Streaming Speed Score is not itself a full end-to-end performance model; rather, it is the network-oriented component that captures how far real transfer behavior departs from the ideal transfer baseline under congestion and other non-ideal conditions (Castro et al., 23 Sep 2025).

A plausible implication is that SSS is intended less as a generic “speed” number than as an operational feasibility indicator. In this interpretation, it is useful precisely because it encodes tail behavior rather than average behavior.

2. Formal model and parameters

The framework parameterizes the processing decision with the following quantities:

Symbol	Meaning
$S_{unit}$	Data unit size (GB)
$C$	Computation complexity coefficient (FLOP/GB)
$R_{local}$	Local processing rate (TFLOPS)
$R_{remote}$	Remote processing rate (TFLOPS)
$Bw$	Raw network bandwidth (GB/s)
$R_{transfer}$	Effective data transfer rate (GB/s)
$\alpha$	Transfer efficiency, $\alpha = R_{transfer} / Bw$
$r$	Remote to local processing power ratio, $S_{unit}$0
$S_{unit}$1	File I/O overhead factor

Local processing time is modeled as

$S_{unit}$2

For remote streaming-based processing, the total completion time is decomposed into transfer, remote compute, and I/O terms:

$S_{unit}$3

The components are expanded as

$S_{unit}$4

$S_{unit}$5

and

$S_{unit}$6

Combining these yields

$S_{unit}$7

and explicitly

$S_{unit}$8

This formulation makes the role of SSS precise: the score does not replace $S_{unit}$9, but supplies an empirical characterization of the transfer environment that informs whether the transfer term is compatible with application timing constraints (Castro et al., 23 Sep 2025).

3. Definition of the Streaming Speed Score

The Streaming Speed Score is defined as

$C$0

where $C$1 is the maximum observed flow completion time for a data unit under congestion, and $C$2 is the minimum possible transfer time with ideal conditions:

$C$3

The interpretation is direct. An $C$4 near 1 indicates near-ideal, low-latency streaming. Larger values indicate degradation due to congestion or protocol overheads. Because $C$5 is defined using worst-case completion time rather than mean or median behavior, the score is explicitly tail-sensitive (Castro et al., 23 Sep 2025).

This emphasis on tail latency is central to the framework. In time-sensitive workflows, the relevant failure mode is not a modest reduction in average throughput but occasional or persistent delay spikes that violate the application’s completion-time budget. The score therefore functions as a compact summary of worst-case transfer behavior under load. This suggests that SSS is best interpreted as a robustness metric for streaming feasibility, not simply a bandwidth-efficiency metric.

4. Measurement methodology and congestion regimes

The framework estimates SSS empirically through controlled experiments using iperf3 clients and servers with multiple concurrent data transfers. These measurements are used to determine $C$6 under different network loads, rather than relying on nominal link bandwidth alone (Castro et al., 23 Sep 2025).

An illustrative example is given for a 25 Gbps link. For a 0.5 GB transfer, $C$7 is approximately $C$8 s, but the observed $C$9 rises to above 5 s under congestion, which corresponds to more than a $R_{local}$0 increase. Under effective bandwidth reservation, by contrast, $R_{local}$1 nearly matches $R_{local}$2. Complementary cumulative analyses show substantial increases in completion times at the 90th and 99th percentiles, reinforcing the claim that tail behavior rather than mean behavior determines feasibility (Castro et al., 23 Sep 2025).

The framework identifies three operational regimes. In the low-congestion regime, $R_{local}$3, and streaming is suitable for real-time HPC processing. In the moderate-congestion regime, multi-second tail delays appear, so streaming may support near-real-time operation but not strict sub-second analysis. In the high-congestion regime, severe transfer slowdowns yield high SSS values, and remote streaming can no longer meet tight deadlines (Castro et al., 23 Sep 2025).

For stringent real-time requirements such as $R_{local}$4 s, streaming is feasible only in the first regime. As the admissible slack increases, for example to less than 10 s, streaming remains viable under higher SSS. The model therefore links SSS to deadline sensitivity rather than treating it as a standalone quality measure.

5. Comparison with file-based workflows and case-study evidence

The framework contrasts streaming with file-based remote processing. In the streaming case, data is continuously transmitted and can be processed upon arrival, which supports pipelined, low-latency operation and eliminates file staging overhead. In the file-based case, the workflow requires full file transfer, possible wait for file aggregation, disk writes and reads, and then compute. The file-based path is therefore exposed to small-file inefficiency and metadata aggregation delays, especially at high data or scan rates (Castro et al., 23 Sep 2025).

The practical significance of the score is illustrated with an LCLS-II case study. Two workflows are listed: Coherent Scattering at 2 GB/s with 34 TF of compute load, and Liquid Scattering at 4 GB/s with 20 TF. For Coherent Scattering under moderate congestion, with the network 64% utilized and worst-case stream transfer approximately 1.2 s, streaming meets Tier 2 requirements of less than 10 s and reserves 8.8 s for compute. For Liquid Scattering, the required rate exceeds the physical link, so remote streaming transmission becomes the bottleneck (Castro et al., 23 Sep 2025).

A further reported result states that streaming at 2 GB/s with moderate network utilization, corresponding to approximately $R_{local}$5, enables real-time computation under Tier 2 constraints with 97% lower end-to-end completion time than file-based methods. More generally, the measurements show that streaming can achieve up to 97% lower end-to-end completion time than file-based approaches under high data rates, while worst-case congestion can increase transfer times by over an order of magnitude (Castro et al., 23 Sep 2025).

These results make clear that the utility of SSS lies in discriminating between superficially similar network environments. Two systems with identical nominal bandwidth can differ substantially in feasibility once worst-case completion time is considered.

6. Relation to adjacent streaming-performance metrics

The term “streaming speed” is used differently across research domains, and the SSS framework is one specific instantiation. In streaming neural speech enhancement, the principal metric is the Real-Time Factor, defined as the ratio of processing time to input audio duration, with $R_{local}$6 indicating processing faster than real time (Ahn et al., 26 Sep 2025). In streaming voice conversion, latency is expressed as

$R_{local}$7

so the analysis combines chunk waiting and computation time rather than worst-case transfer behavior (Ning et al., 2023).

In HTTP video streaming, a different usage appears in which a “Streaming Speed Score” is described as the percentage of fair-share throughput achieved; in that setting, Sprint achieves above 90% of fair-share throughput, while other players often achieve markedly less (Arye et al., 2018). That formulation evaluates transport-plane throughput efficiency rather than tail-latency feasibility for remote HPC.

This comparison suggests that “Streaming Speed Score” is not a universal metric with a single meaning. In the remote-HPC framework, it is specifically a tail-latency ratio grounded in worst-case flow completion time. Its distinctiveness lies in its role as a decision criterion for remote processing feasibility under congestion, where nominal bandwidth and average throughput are insufficient descriptors of real-time capability (Castro et al., 23 Sep 2025).