A Detailed Characterization of Starlink One-way Delay

Low Earth Orbit (LEO) satellite networks, such as Starlink, are transforming global Internet access by delivering high-speed connectivity to underserved and remote regions. Despite extensive research into Starlink’s performance, latency characteristics remain underexplored. This study presents a comprehensive analysis of one-way delay components in the Starlink network using high-frequency, high-precision measurement probes. Over a 10-day period, more than 500 million probe packets were collected and analyzed. The results reveal minor diurnal latency variation and provide means to separate out the delay components contributing to the observed one-way delay, and we sketch a delay model and provide empirical distributions. By measuring both uplink and downlink paths, the study uncovers significant differences in scheduling behavior, with uplink delays more affected by Starlink’s periodic 15-second reconfiguration cycles. The results also highlight the limitations of using too coarse measurement intervals, which can introduce aliasing effects. Our OWD data set and traffic generation tool are made available to support further research in the area.

低地球轨道 (LEO) 卫星网络，如 Starlink，正通过为服务欠缺和偏远地区提供高速连接，改变全球的互联网接入方式。尽管对 Starlink 的性能已有广泛研究，但其延迟特性仍未得到充分探索。

本研究利用高频率、高精度的测量探针，对 Starlink 网络中的单向延迟分量进行了全面分析。 在为期 10 天的测量中，我们收集并分析了超过 5 亿个探测包。结果显示，其延迟存在微小的昼夜变化，并提供了分离构成观测单向延迟的各个延迟分量的方法。我们还构建了一个延迟模型，并提供了相关的经验分布。

通过同时测量上行和下行链路路径，本研究揭示了两者在调度行为上的显著差异，其中 上行链路的延迟更容易受到 Starlink 15 秒周期性重构周期的影响。 研究结果还突显了使用过于粗糙的测量间隔可能引入混叠效应的局限性。我们公开了所用的单向延迟 (OWD) 数据集和流量生成工具，以支持该领域的进一步研究。

Introduction

Low Earth Orbit (LEO) satellite communication systems have the ability to provide high-speed Internet connectivity across the globe, serving remote and sparsely populated areas that previously faced considerable challenges in terms of Internet access. The primary LEO satellite operator is Starlink, which currently has more than 5 million customers [39]. Starlink has been the subject of a number of studies aimed at characterizing performance aspects in general, and in relation to specifics such as the effects of weather [4, 25, 28], the impact of mobility [3, 13, 17, 23, 24, 42], the interaction with TCP congestion control [7, 8, 11, 22] and the use of multiconnectivity [3, 17, 26, 27]. So far, there has been no detailed and fine-grained study of delay aspects. In this study, we utilize high-frequency, high-precision measurement probes to perform a detailed characterization of the one-way delay components in the Starlink network.

We perform a 10-day measurement campaign encompassing more than half a billion probe packets. Analyzing these measurements, we find that there are indications of only minor amounts of diurnal variations in latency. We further provide a sketch of a delay model incorporating several Starlink-specific delay components. As we simultaneously measure both the uplink and downlink, we can compare their latency characteristics. Our measurements show that the scheduling behavior differs considerably between uplink and downlink, and that the delay impacts of the periodic 15-second reconfigurations are larger for the uplink than the downlink.

低地球轨道 (LEO) 卫星通信系统能够为全球提供高速互联网连接，服务于以往在互联网接入方面面临巨大挑战的偏远和人口稀疏地区。主要的 LEO 卫星运营商是 Starlink，目前拥有超过 500 万用户 [39]。Starlink 已成为多项研究的对象，这些研究旨在刻画其总体性能，以及与特定方面相关的特性，例如天气影响 [4, 25, 28]、移动性影响 [3, 13, 17, 23, 24, 42]、与 TCP 拥塞控制的交互 [7, 8, 11, 22] 以及多连接技术的使用 [3, 17, 26, 27]。然而，迄今为止，尚无针对延迟方面的详细且精细的研究。在本研究中，我们利用高频率、高精度的测量探针，对 Starlink 网络中的单向延迟分量进行了详细的特征分析。

我们进行了一次为期 10 天的测量活动，涵盖了超过 5 亿个探测包。通过分析这些测量数据，我们发现延迟仅存在微小的昼夜变化迹象。我们进一步构建了一个延迟模型草图，该模型包含了几个 Starlink 特有的延迟分量。

由于我们同时测量上行和下行链路，因此可以比较它们的延迟特性。我们的测量结果表明， 上行和下行链路的调度行为差异很大，并且周期性的 15 秒重构对上行链路的延迟影响大于下行链路。

We provide the following contributions:

• a characterization of Starlink one-way delay across multiple time-scales,

• a delay model detailing the components of observed delay variations and empirical distributions related to three major delay components,

• an analysis showing that using a 10 or 20 ms measurement interval may result in misleading aliasing effects.

We believe that the insights on delay characteristics provided by this work can be helpful when designing simulation or emulation tools that aim to reproduce the behavior of Starlink or other LEO systems.

我们的贡献如下：

• 对 Starlink 在多个时间尺度上的单向延迟进行了特征刻画。
• 建立了一个延迟模型，详细说明了观测到的延迟变化的组成部分，并提供了与三个主要延迟分量相关的经验分布。
• 一项分析表明，使用 10 毫秒或 20 毫秒的测量间隔可能导致误导性的混叠效应。

我们相信，本研究提供的关于延迟特性的见解，对于设计旨在复现 Starlink 或其他 LEO 系统行为的仿真或模拟工具将大有裨益。

Background and Related Work

Previous research has established that the Starlink network characteristics vary over time in terms of available capacity, round-trip time, and packet loss [12, 22, 30]. Starlink uses a 15 second reconfiguration interval [12, 30] and schedules transmissions in 1.33 ms link layer frames [10, 18]. On short timescales the throughput of Starlink is dependent on the physical transmission rate, and the allocation structure of the link layer frames [9].

Many studies report Starlink delay results by characterizing the distribution of observed RTT by means of boxplots, ECDFs, or evolution over time [3, 5, 15, 26, 33, 34, 38, 45, 47]. Early RTT results were reported in [29], and a large-scale examination of Starlink latency with more than 2400 vantage points was performed in [19] to examine aspects such as inter-satellite-link (ISL) delay impact. The impact of the global 15-second reconfiguration events on measured RTT is examined in [22], and they also examine the RTT impact from local reconfigurations where satellites are switched within a 15 s period. In relation to previous work that considers delay or latency, our study differs mainly in terms of the measurement resolution and the number of collected observations, which allows for better characterization and modeling of the delay components.

Some studies have used simulation or emulation to evaluate Starlink performance [2, 16, 20–22, 41]. Since modeling the delays is in many cases important for simulation and emulation fidelity, the results presented here can be beneficial when setting up future simulation or emulation studies. that aim to faithfully represent Starlink connectivity. In the context of 5G, other work has examined approaches for delay measurements [14, 31], or characterized the delay in 5G networks [1, 36].

以往的研究已经证实，Starlink 网络在可用容量、往返时间 (RTT) 和丢包率方面会随时间变化 [12, 22, 30]。Starlink 使用 15 秒的重构间隔 [12, 30]，并以 1.33 毫秒的链路层帧来调度传输 [10, 18]。在短时间尺度上，Starlink 的吞吐量取决于物理传输速率和链路层帧的分配结构 [9]。

许多研究通过箱形图、经验累积分布函数 (ECDF) 或随时间演变的图表来报告 Starlink 的延迟结果，以刻画观测到的 RTT 分布 [3, 5, 15, 26, 33, 34, 38, 45, 47]。早期的 RTT 结果在 [29] 中有报道，而 [19] 则利用超过 2400 个观测点对 Starlink 的延迟进行了大规模研究，以检验星间链路 (ISL) 延迟影响等方面。文献 [22] 研究了全局 15 秒重构事件对测得 RTT 的影响，并探讨了在 15 秒周期内切换卫星的局部重构对 RTT 的影响。与之前考虑延迟或时延的研究相比，我们的研究主要在测量分辨率和采集的观测数量上有所不同，这使得我们能够更好地对延迟分量进行特征分析和建模。

一些研究使用仿真或模拟来评估 Starlink 的性能 [2, 16, 20–22, 41]。由于延迟建模在很多情况下对仿真和模拟的保真度至关重要，因此本文提出的结果对于未来建立旨在忠实代表 Starlink 连接性的仿真或模拟研究是有益的。在 5G 的背景下，其他工作研究了延迟测量的方法 [14, 31]，或对 5G 网络中的延迟进行了特征分析 [1, 36]。

Measurement collection

For our measurements, we use a Gen-2 Starlink user terminal (UT) connected via Ethernet to our measurement computer which is equipped with an Intel X550-T2 Network Interface Card (NIC). This NIC has two Ethernet ports and is capable of providing hardware timestamps for both received and transmitted packets. To generate the traffic, we utilize a custom traffic generator, nanoprobe, which is loosely based on the existing nanoping tool. Nanoprobe has been designed to allow high-frequency generation of probe packets while also extracting the hardware timestamps for both received and transmitted packets 1 . We set up the measurements so that one port of the NIC is connected to the Starlink terminal, and the other port has a public IP address.

Nanoprobe is configured in a client-server setup. The nanoprobe client is attached to the port connected to the Starlink UT, and the nanoprobe server is attached to the port connected to the Internet. We configure nanoprobe to simultaneously, and independently, send probe packets from server to client (downlink, DL) and from client to server (uplink, UL). Probe packets are sent with an interpacket time of 266 𝜇 s, which corresponds to a packet rate of 3750 packets per second. As the packets are 150 bytes including the UDP and IP headers, this corresponds to a bit rate of 4.5 Mbps.

The objective here is to characterize latency aspects under a lightly loaded scenario, where the offered measurement load is well below Starlink capacity. Typical applications generating such latency-sensitive and non-greedy traffic would be video-conferencing, gaming, etc. Greedy and capacity-seeking traffic, as is the case for long-lived TCP connections, would result in higher rates, and additional queuing delay. A number of studies report Starlink downlink throughput in the range of 50 to 250 Mbps, and thus the offered rate for our latency measurements is well below what the system is capable of providing. For the uplink, there are fewer studies, but here too the observed empirical throughput is significantly above our measurement traffic rate.

The measurements are collected in separate runs, where each run is 50 seconds long, and a new run is performed every 10 minutes during the measurement period. The 50-second run duration enables the study of effects at the 15-second reconfiguration interval. Over a 10-day period in April 2025 we collected 1440 measurement runs, of which 3 could not be successfully completed due to spurious issues with the nanoprobe initial handshake negotiation 2 .

With our measurement setup, one-way delay measurements can be performed with very high precision. Since both the transmit and receive timestamps are hardware-generated and derived from the same on-NIC 80 MHz oscillator, there is no relative clock skew between sending and receiving timestamps, and the timing measurements have a precision in the order of tens of nanoseconds. While our measurement setup includes the traversal of the regular Internet from our server to the Starlink Point of Presence (PoP) in Frankfurt, this connection is well-provisioned and does not significantly hinder our ability to detect Starlink-specific timing patterns with sub-millisecond precision, as illustrated later.

在我们的测量中，我们使用一台第二代 Starlink 用户终端 (UT)，通过以太网连接到我们的测量计算机，该计算机配备了 Intel X550-T2 网络接口卡 (NIC)。该 NIC 有两个以太网端口，并能为接收和发送的数据包提供硬件时间戳。为了生成流量，我们使用了一款名为 nanoprobe 的定制流量生成器，它大致基于现有的 nanoping 工具。nanoprobe 旨在允许高频率地生成探测包，同时提取发送和接收数据包的硬件时间戳。我们将测量设置如下：NIC 的一个端口连接到 Starlink 终端，另一个端口拥有一个公网 IP 地址。

nanoprobe 被配置为客户端-服务器模式。nanoprobe 客户端连接到与 Starlink UT 相连的端口，而 nanoprobe 服务器则连接到与互联网相连的端口。我们配置 nanoprobe 以同时且独立地从服务器向客户端（下行链路，DL）和从客户端向服务器（上行链路，UL）发送探测包。探测包的发送包间间隔为 \(266\) 微秒 (μs)，相当于每秒 \(3750\) 个数据包的速率。由于数据包大小（包括 UDP 和 IP 头部）为 \(150\) 字节，这对应的比特率为 \(4.5\) Mbps。

https://github.com/simosund/nanoprobe

https://github.com/iij/nanoping

此举的目标是在轻度负载场景下刻画延迟特性，此时我们提供的测量负载远低于 Starlink 的容量。产生此类延迟敏感且非贪婪型流量的典型应用包括视频会议、在线游戏等。对于长时 TCP 连接等贪婪型和寻求容量的流量，会产生更高的速率和额外的排队延迟。多项研究报告 Starlink 的下行链路吞吐量在 \(50\) 到 \(250\) Mbps 之间，因此我们用于延迟测量的负载速率远低于系统所能提供的能力。对于上行链路，虽然研究较少，但观测到的经验吞吐量也显著高于我们的测量流量速率。

测量数据分次收集，每次运行持续 \(50\) 秒，在测量期间每 \(10\) 分钟进行一次新的运行。\(50\) 秒的运行持续时间使得我们能够研究 \(15\) 秒重构间隔带来的影响。在 2025 年 4 月为期 10 天的测量中，我们共收集了 \(1440\) 次测量运行，其中 3 次因 nanoprobe 初始握手协商中出现的偶发问题而未能成功完成。

通过我们的测量设置，可以以非常高的精度进行单向延迟测量。由于发送和接收的时间戳均由硬件生成，且源自同一个板载 \(80\) MHz 振荡器，因此发送和接收时间戳之间不存在相对时钟偏移，计时测量的精度可达数十纳秒级别。尽管我们的测量设置包括了从我们的服务器到位于法兰克福的 Starlink 接入点 (PoP) 的常规互联网路径，但该连接配置良好，不会显著影响我们以亚毫秒级精度检测 Starlink 特定时间模式的能力，这一点将在后文详述。