Latency Statistics

---
name: latency-statistics
description: Evaluates the real-time performance and observability accuracy of an eBPF-based tracing library by measuring request throughput and tail latency under inference workloads. It verifies the framework's ability to disambiguate request boundaries from streaming system calls without application instrumentation. Use when the user has predictions and gold and needs to compute latency statistics.
metadata:
  skill_kind: metric
  source_arxiv: 2603.25067
  bibtex_key: ibnath2026ebee
  confidence: medium
---

# latency-statistics

> eBeeMetrics: An eBPF-based Library Framework for Feedback-free Observability of QoS Metrics — Ibnath et al. (2026) (arXiv:2603.25067, 2026)

## What this evaluates

Evaluates the real-time performance and observability accuracy of an eBPF-based tracing library by measuring request throughput and tail latency under inference workloads. It verifies the framework's ability to disambiguate request boundaries from streaming system calls without application instrumentation.

## Datasets

- **Triton client workload** — total ?; splits: test (-1)

## Metrics

- `RPS` — range: other
  - Requests per second calculated over the total experiment duration.
- `latency statistics` **(primary)** — range: other
  - Server-side request latency percentiles (specifically tail latency) computed from collected request timestamps.

## Input / output format

**Input**: Inference requests generated by the Triton client workload sent to the Triton server.

**Output**: Real-time QoS metrics (RPS and latency statistics) reported via the eBeeMetrics API, with final server-side latency data stored in lib/latencies/.

## Scoring recipe

```python
# Pseudo-code for metric computation
requests = load_data("lib/latencies/")
duration = requests[-1].end_time - requests[0].start_time
rps = len(requests) / duration
latencies = [req.end_time - req.start_time for req in requests]
p99_latency = percentile(latencies, 99)
return {"RPS": rps, "p99_latency": p99_latency}
```

## Common pitfalls

- Request boundary disambiguation from streaming system calls is critical; misalignment skews latency measurements.
- Client-reported latency often differs from server-side latency due to network and client processing overhead.
- eBPF tracing overhead must be isolated to ensure QoS metrics reflect actual workload performance rather than instrumentation cost.

## Evidence (verbatim from paper)

> During execution, the library reports QoS metrics (RPS and latency statistics) via its API in real time.

## Citation

```bibtex
@misc{ibnath2026ebee,
  title={eBeeMetrics: An eBPF-based Library Framework for Feedback-free Observability of QoS Metrics},
  author={Ibnath et al. (2026)},
  year={2026},
  note={arXiv:2603.25067}
}
```

- arXiv: 2603.25067