On September 10, Sweden's Karlstad University presented a doctoral thesis by Simon Sundberg that investigates latency on the internet, from the access segment closest to users to the inside of web servers and satellite links. The work combines lightweight tools that observe ordinary traffic with a method that sends test packets at high frequency, measuring delays that typical speed tests struggle to capture. One concrete example is the occasional round-trip time approaching one second observed at a US wireless ISP. What the research shows is that "slowness" that cannot be fixed simply by adding bandwidth has to be investigated according to where it occurs and over what time scale.
Bandwidth is the amount of data a connection can carry per unit of time, while latency is the waiting time that arises during communication and processing. Bandwidth matters most for downloading large files, but for video calls and online games, which wait for responses from the other side, even a temporary rise in latency can damage the experience. This distinction has long been known. The significance of Sundberg's research lies in refining methods for continuously capturing such latency on networks that are actually in operation.
Rare, prolonged delays at a US wireless ISP
The study of the segment closest to users was conducted at JackRabbit Wireless in El Paso, Texas. According to research published at the 2024 ACM Internet Measurement Conference (IMC), the ISP had about 400 subscribers at the time, roughly 95% of them households. The measurement period ran from October 30 to December 1, 2023, with a gap of about five hours in the middle. It is therefore not a measurement of network conditions as of September 2026.
The research team placed a vantage point in the ISP's core network and collected more than 9 billion RTT (round-trip time) samples from ordinary traffic. They analyzed the "internal segment," running from the vantage point to the user's device, separately from the "external segment," running to communication partners on the internet. The internal segment includes not only the ISP's access network but also connections inside the home, so the measurements are not of home Wi-Fi alone.
In the internal segment, short RTTs made up the majority, but large delays occurred occasionally. The 99th percentile, the value below which 99% of observations fall, was 326 milliseconds for the internal segment and 134 milliseconds for the external segment. The external segment had longer typical waiting times, but its spread of large delays was smaller than that of the internal segment.
In addition, about 0.16% of RTTs observed in the internal segment exceeded 996 milliseconds. This is a delay approaching one second, but it is neither an average nor a share of subscribers; it is the proportion of all observed internal RTT samples. The tallying was done in 4-millisecond bins, with values above 996 milliseconds grouped into a final bin. For that reason, not every value in that bin can be strictly regarded as exceeding one second.
The ISP had already deployed AQM, which prevents packets waiting to be sent from piling up in queues too much, along with controls for allocating bandwidth fairly. Even so, large delays increased in the internal segment during evening congestion, and the researchers point to home Wi-Fi routers as a possible main cause. However, they did not measure individual households' equipment to pin down the cause. Nor can the incidence rate for home connections as a whole, including in Japan, be inferred from results obtained at a single ISP.
Where you measure changes what problems you see
"epping," a tool developed by the research team, is a passive monitoring tool that estimates RTT from packets already flowing, without generating new test traffic. It uses eBPF, which allows programs to run inside the Linux kernel, to calculate and aggregate measurements within the kernel. The design reduces the load that would come from copying packets and handing them to another program, or from sending each individual measurement result out one by one.
If the measurement itself imposes a heavy load, it can affect the traffic being observed. So epping, and "netstacklat," which examines latency inside servers, emphasize being light enough to monitor continuously. That said, generating no additional traffic is not the same as having no processing overhead at all.
The three studies target different kinds of latency, and each differs in measurement method and in what it can reveal. Last-mile RTT, receive-processing time inside a host, and one-way delay on a Starlink link are not the same kind of speed metric.
| What is observed | Main method | What it reveals and its limits |
|---|---|---|
| Between the ISP vantage point and users' devices | Estimating RTT from existing traffic with epping | Shows when and how delay increases on the user side. It cannot directly identify which device in the home is responsible |
| Receive processing inside web servers | Tracking transit times inside the kernel with netstacklat | Reveals the waiting time until packets are read by the application. This differs from the application's overall response time |
| Traffic over Starlink | Sending test packets at high frequency with nanoprobe and recording timestamps at the device | Reveals how one-way delay varies over short time scales. Measurement conditions differ from the experiment observing ordinary traffic at the ISP |
This comparison is based on the summary of research methods and results in Sundberg's doctoral thesis and on what each study observed. Even when the same word, "latency," is used, figures cannot be compared directly if the segments they cover differ. Nor does the observation of large delays on the user side make investigating server internals or satellite links unnecessary.
Delays inside servers, and how measurement changes the view of satellite links
The netstacklat study ran experiments on nginx and Apache under 144 combinations of server settings, file sizes, and numbers of concurrent connections. The team then deployed it on Cloudflare's production servers and examined the delay from when traffic reaches a server until it is read by the application. The results have been published as an accepted paper for IMC 2026.
In the Cloudflare observations described in the thesis, receive-processing delay was typically 64 to 256 microseconds. On one server, however, the tool caught an anomaly in which median delay rose over about three hours from roughly 128–256 microseconds to more than 2 milliseconds, even though traffic had not increased significantly. Looking only at the time packets spend traveling across the network would miss the time they spend waiting inside the computer after arriving at the server.
Still, it would be premature to take this result as evidence of serious delay common to all web servers. In another semi-controlled experiment, the 95th percentile of receive-processing time stayed under 1 millisecond even when the load exceeded the expected capacity. The value of this kind of monitoring lies in being able to separate a simple rise in load from a specific anomaly occurring during normal operation.
Starlink required observation at an even finer time scale. The team used "nanoprobe" to send test packets at high frequency and relied on timestamps recorded by the network card. If timestamps are recorded after passing through the operating system, the delay of the link itself tends to get mixed with waiting time inside the measuring computer.
The results showed that multiple packets arriving within a few milliseconds were delivered together in batches, according to the radio link's processing units. Packets that arrived earlier waited longer, and those arriving later waited less. Because this pattern repeats, delay seen at fine time resolution fluctuates periodically like an inverted sawtooth wave.
When measured at coarse intervals, as in the past, delay appeared to split into several bands of values. The research explains this as "aliasing," in which a pattern different from the true one appears because the measurement interval is too coarse. Not only the propagation time due to the distance to the satellite, but also packet transmission timing and radio resource allocation create waiting time. How a network's workings appear depends not only on averages but also on how fine the measurement interval was.
Before speeding up, find out where the waiting happens
epping's public code has also been incorporated into LibreQoS, a quality-of-service management platform for ISPs. netstacklat and nanoprobe are also publicly available, and these results have advanced from measuring latency in experimental settings to a means of continuously examining networks in operation.
There are, however, limits to what can be monitored. In the epping implementation covered in the thesis, the traffic for which RTT can be estimated is limited to TCP and ICMP Echo, so not every game protocol or QUIC can be observed as is. netstacklat likewise targets receive processing for TCP and UDP. And in exchange for reducing processing load by aggregating measurement results, fine-grained information about individual connections is lost. None of the tools automatically identifies the cause of delay on its own.
The operational implication of these results is that before simply upgrading a connection's speed, one needs to isolate in which segment and at what time of day delay occurs. Where to act depends on whether the problem lies on the user side or in slow receive processing inside a server.
If carriers and service providers can continuously capture not only short, typical delays but also rare, large ones, they can more precisely narrow down where to add capacity and where to revisit how processing is done.