Research · Report

August–October 2026 Research Report

UR’s research has one aim: to give everyone the best encryption and the best speed, for everyday use, that makes your internet better. From August 24 to October 24, 2026, that work measured 39 changes and experiments in Connect, the SDK and the server packet path. This report puts each one on a timeline with what it measured, follows how far each kind of gain went, and explains how the research was done.

October 24, 2026 · Dates are those of the research records, which can differ from the merge dates. Updated 2026-10-30.

At a glance

≈4.73×faster with adaptive windows in their model, 202.752 to 958.259–958.362 Mbps; 939–943 Mbps of useful payload on a 1-Gbps local test path

4.7–7.3×faster median Wikipedia load, from the Aug 24 baselines to the latest phone cell

6.7×controlled H1 bulk recovery, from about 6.1 to 41 Mbps

2.81×the largest packet-path gain, sending a provider’s packets as one group

−26.4%runtime memory in an exact physical replay, 29.59 to 21.77 MiB

8stalls and failures fixed

Each figure is its own workload. They cannot be added or multiplied into one app speedup, and the report claims none. Why there is no single number

The 39 entries, by date

Gainmeasured and kept
Recoverya stall or failure fixed
Observationa phone or public measurement, not an A/B
Mixedhelped in one case, hurt in another
Rejectedmeasured and not adopted, or no change
Groundworkcorrectness, policy or measurement, no speed claim

Why it matters

The best encryption and the best speed, without the tradeoff

Encryption is not what gets traded away. The speed has to come from doing the work better: less work for every packet, less memory on the phone, and no stalls. Someone using the network should only notice that the internet works.

Each meter on this page follows one part of that, as it is felt in everyday use.

Page load
Pages open without waiting
The median Wikipedia load went from 2,552.3 or 3,967.8 ms on Aug 24 to 545.7 ms in the latest phone cell, a historical observation rather than an A/B.
Bulk speed
Full speed for streams and downloads
Adaptive windows took a local TCP path to gigabit-class delivery, 939–942 Mbps sustained, and the controlled H1 phone path recovered from about 6.1 Mbps to Fast.com runs of 38, 41 and 52 Mbps.
Packet path
Encrypted traffic that costs less work
The carriers that move encrypted traffic do less work per packet: grouped sends 2.81×, the Framer’s single-frame path 2.02×, H1+ 1.19–1.36×, each measured alone; adaptive windows (≈4.73× in their model) keep a fast path full.
Memory
Light enough for a phone
A phone gives the network a small memory budget, 32 MiB in the iOS profile and 64 MiB on Android. Fixes like the retained-byte accounting (−26.4%) keep the work inside it.
Recoveries
No stalls to notice
Eight stalls and failures were fixed, from dropped H1 handoffs in August to pages that paused 5 s or more in October.

It is not finished: the cold first page and the full phone qualification are still open. What is not yet shown

Timeline

39 changes and experiments

Each entry leads with its result in plain words and one figure. Open it for the exact measurements, what they mean for the test suites, and the evidence. Entries that were rejected or made no difference stay on the timeline, marked as such.

The meters replay the evidence as you read. Each one moves only when you reach the entry that recorded it, and none of them is ever combined with another.

August

Aug 24–27 · 9 entries

5 gains
2 recoveries
1 mixed
1 rejected

Aug 24Gain
Rebalance mobile memory and speed settings together
3,967.8 → 745.0 msmedian Wikipedia load on the low-bar phone test
Document first byte 1,575.2 → 248.1 ms · Cloudflare 1 MiB in 33.279 → 3.892 s
Four settings changed at once, so this is one bundled result, not four separate gains.
Moves
Exact figures and what they mean
In the report
Low-bar mobile memory/performance rebalance
Measured
The accepted bundle moved Wikipedia median load 3,967.8→745.0 ms, document TTFB 1,575.2→248.1 ms, and Cloudflare 1-MiB completion 33.279→3.892 s (0.25→2.16 Mbps).
What it means for the test suites
A bundled device improvement: target 20→24 MiB, quality/speed window 3/1→4/1, GOGC 10→25 and warm set 256→512 KiB changed together. Peak 24.73 MiB passed that experiment's 28-MiB active / 24-MiB steady rule; it does not pass the later absolute 24-MiB rule.
Evidence
LOWBAR
Aug 24Neutral
Check whether the server got slower
−0.05%server time in a same-session, six-repetition A/B (geomean)
PERFVAR −0.17% · server/proxy +0.05% · allocation counts unchanged
No real change. An earlier apparent slowdown was drift on the test host, so no server tuning was needed.
Exact figures and what they mean
In the report
Rebalance mobile memory after the tighter 20-MiB direction; isolate server cost
Measured
Exact same-session, six-repetition A/B: server/connect time geomean −0.05%, PERFVAR −0.17%, server/proxy +0.05%; allocation counts unchanged.
What it means for the test suites
Server neutrality, not a throughput win. The earlier cross-day apparent slowdown was host drift. No server-specific reclaim tuning was warranted.
Evidence
Server PERFVAR measurements
Aug 24Mixed
Find the limiter with deeper sequence queues
2,552.3 → 543.7 msmedian Wikipedia load on a public H1 route, depth 16 → 32
1 MiB goodput 0.73 → 4.65 Mbps · depth 64 reached 457.6 ms
A real limiter, found on unpaired public routes. Bigger queues and more memory alone did not help, and were rejected.
Moves
Exact figures and what they mean
In the report
Sequence-depth and allocation/admission experiments
Measured
Public H1 depth 16→32: Wikipedia load median 2,552.3→543.7 ms, 1-MiB goodput 0.73→4.65 Mbps, runtime peak 20.34 MiB in the depth-32 arm. Global depth 64 improved the page median to 457.6 ms, but larger receive-only/both-data queues did not reproduce the bulk gain.
What it means for the test suites
Useful limiter discovery, unpaired public-route diagnostics, not a universal 6.4× release gain. A 4,096-root gate removed pressure drops but did not improve speed; more memory alone was rejected.
Evidence
MEMSTEADY
Aug 25Gain
Send a provider’s packets as one group
2.81×throughput draining 16 packets (25,579 → 9,105 ns per drain)
19,440 → 4,024 B allocated per drain · 147 → 51 allocations · 16 → 8 wire Packs · ACK fast path 577.8 → 596.5 MB/s
A local packet-path gain, measured inside one process. It is not Internet speed or phone memory.
Moves
Exact figures and what they mean
In the report
Whole-group provider sends and pure-TCP-ACK fast path
Measured
Grouping: 25,579→9,105 ns/drain, 19,440→4,024 B/drain, 147→51 allocations, 16→8 wire Packs. ACK fast path: 577.8→596.5 MB/s, approximately 5,351→2,560 B/op, 46→37 allocations.
What it means for the test suites
Retained local packet-path efficiency improvements. Same-process boundaries; not Internet throughput or mobile peak-memory measurements.
Evidence
MEMSTEADY
Aug 25Gain
Write ready H1 frames without waiting
+85.2%ACK-sized local TLS throughput (167.03 → 309.30 MB/s)
Full payload +12.9% · TCP writes per frame −25% and −75% · still two allocations per op
It batches only what is already ready, so it adds no delay. Balanced server checks stayed neutral.
Moves
Exact figures and what they mean
In the report
Nonblocking ready-drain H1 writes, cap 8→32
Measured
Full-payload local TLS throughput 1,305.04→1,473.51 MB/s (+12.9%); ACK-sized 167.03→309.30 MB/s (+85.2%). TCP writes/frame decreased 25% / 75%, respectively; allocations stayed at two/op.
What it means for the test suites
Directly measured batching gain without a timer or larger socket storage. Balanced server PERFVAR/proxy checks were effectively neutral (−0.46% / +0.64% time geomean), rejecting the apparent previous-day ~20% regression.
Evidence
Server PERFVAR measurements
Aug 25Recovery
Stop H1 handoffs from dropping under load
38 / 41 / 52 MbpsFast.com on the exact-provider phone path, from about 6.1 Mbps
Active peak 17.60 MiB · 762/762 Pack waits completed · zero carrier or Pack drops · Wikipedia median load 439.2 ms
Strong evidence that the fixed-size H1 path can meet the 40 Mbps goal without spending more memory.
Moves
Exact figures and what they mean
In the report
Reliable H1 handoff/backpressure and logical-flow isolation
Measured
Exact-provider physical H1: Fast.com 38/41/52 Mbps, Wikipedia median TTFB/load 181.5/439.2 ms, active runtime peak 17.60 MiB; quiet p95 17.61 MiB over 345 seconds. 762/762 Pack waits completed, zero carrier/Pack drops. An impaired synthetic four-flow lane comparison measured 20.247→29.058 Mbps (+43.5%).
What it means for the test suites
Strong evidence that fixed-capacity H1 can meet the 40-Mbps objective without spending more memory. The lane comparison is a scenario signal; public current–baseline–current brackets were provider-variable and do not support one percentage speedup. Later receive-custody work refines overload handling; this is historical evidence, not permission to block all shared receive work.
Evidence
MEMSTEADY PERFVAR measurement ledger (private; summarized here)
Aug 25–26Gain
Count retained memory separately from data in flight
29.59 → 21.77 MiBruntime in an exact physical replay (−26.4%)
Packet roots 6.15 → 1.78 MiB · quiet p95 20.16 MiB · ACK bookkeeping about 44 → 20 ns per op, no allocations
The budget now charges what is actually held. A variant that mixed the two caused timeouts and was rejected.
Moves
Exact figures and what they mean
In the report
Charge retained allocation separately from logical flight; reduce ACK bookkeeping churn
Measured
Exact retained-byte accounting physical replay: runtime 29.59→21.77 MiB, packet roots 6.15→1.78 MiB, ten 1-MiB transfers completed; quiet p95 20.16 MiB. RTT ring/min-deque ACK work changed approximately 44→20 ns/op, 64→0 B/op, 1→0 allocations.
What it means for the test suites
Memory/ownership and microkernel gains in their recorded workloads. Charging allocation capacity as if it were the logical delivery window had caused a separate timeout and was rejected.
Evidence
MEMSTEADY
Aug 26–27Recovery
Recover from poisoned exits and choose healthier providers
92.5 Mbpscombined median of public H1 observations (47/100/110, then 68/85/130)
Wikipedia median load 478.3 ms afterwards · one runtime peak of 24.30 MiB failed that week’s 24 MiB gate
Playback came back in the documented cases. These public speeds show what is reachable; they are not a controlled A/B.
Moves
Exact figures and what they mean
In the report
Poisoned-exit recovery, fresh-flow quality selection and provider-off budget use
Measured
Recovery and provider-selection changes restored playback in the documented cases. Public four-route-floor H1 observations were 47/100/110, then 68/85/130 Mbps (combined median 92.5 Mbps); subsequent Wikipedia median load 478.3 ms. One runtime peak was 24.30 MiB.
What it means for the test suites
Availability/selection improvements and proof of attainable speed, not a controlled source-level speed effect. That peak failed the then-current 24-MiB gate and must not be retroactively passed using today's 32-MiB limit.
Evidence
PERFVAR measurement ledger (private; summarized here)
Aug 27Gain
Share UDP readiness and idle handling on providers
621 → 242goroutines on the provider host (−61%)
Runtime 27.9 → 25.8 MiB · live heap 10.4 → 9.4 MiB · UDP round trips +10.4% · TCP echo +1.9%
Fewer threads and less memory on the provider host. The physical provider was still above its 24 MiB limit then.
Moves
Exact figures and what they mean
In the report
Shared provider UDP readiness, direct writes and shared idle lifecycle
Measured
Five fresh runs/arm: TCP echo 53.1→54.1 MiB/s (+1.9%); UDP 13,960.4→15,414.3 round trips/s (+10.4%); runtime 27.9→25.8 MiB; live heap 10.4→9.4 MiB; goroutines 621→242 (−61%).
What it means for the test suites
Retained provider efficiency win. The synthetic 31-MiB host gate passed, but the physical provider remained above its historical 24-MiB limit.
Evidence
PERFVAR measurement ledger (private; summarized here)

September

Sep 4–30 · 19 entries

7 gains
3 recoveries
1 observation
3 mixed
2 rejected
3 groundwork

Sep 4Groundwork
Bound the TCP inbound handoff
No speed claim
A correctness and recovery milestone. The campaign set no new baseline, so no speed gain is inferred.
Exact figures and what they mean
In the report
Bounded TCP inbound handoff
Measured
The static campaign and its correctness/failure accounting are recorded in the measurement ledger.
What it means for the test suites
A correctness/recovery milestone. Do not infer a universal speed gain from a campaign that did not promote a baseline.
Evidence
PERFVAR measurement ledger (private; summarized here)LOWBAR
Sep 9–11Recovery
Remove the flight-gate collapse on mixed routes
2.5 → 18.5 Mbpsstock vs merged in the mixed loss/100 TCP cell
Stock failed 13/40 runs · at loss/300 stock missed all five deadlines while merged delivered 19.3 Mbps · relay timeout rewrites 19,966 → 201
A collapse on mixed routes is gone. These are specific test cells, not an app-wide multiplier.
Moves
Exact figures and what they mean
In the report
Remove mixed-route flight-gate collapse
Measured
In the recorded mixed loss/100 TCP cell, stock 2.5→18.5 Mbps; loss/300 stock failed all five deadlines while merged delivered 19.3 Mbps. Stock failed 13/40 runs. Separately, deferred relay retransmission moved 13.1→15.7 Mbps, timeout rewrites 19,966→201, dead windows 6→0.
What it means for the test suites
Functional collapse/retransmission recovery. The relay A/B is distinct from the mixed-route cells; neither is a general app multiplier. Later A/A retired many small early percentage verdicts.
Evidence
PERFVAR measurement ledger (private; summarized here)LOWBAR
Sep 12–13Recovery
Stop retransmission storms
5/40 → 0/40runs with timeout storms, 20 runs per arm in two cells
Maximum writes 3,902 → 36 · goodput medians 20.9 → 21.2 and 19.5 → 19.9 Mbps
The gain is in the worst cases, not the typical run.
Also rejected: A proposed reliable-lane rule caused wedges, 0/120 off vs 8/120 on (Fisher p = .0069), and stayed off.
Moves
Exact figures and what they mean
In the report
Bound retransmission amplification; reject harmful lane rules
Measured
Twenty runs/arm in two storm cells: timeout storms 5/40→0/40, maximum writes 3,902→36; goodput medians only 20.9→21.2 and 19.5→19.9 Mbps. A separate proposed reliable-lane rule produced mechanism wedges 0/120 off vs 8/120 on (Fisher p=.0069), and stayed off.
What it means for the test suites
Main gain is reduced tail amplification. A/A on identical source flagged 15/17 cells at five repetitions; earlier small verdicts were retired. Rejected lane-rule behavior must not be counted as an improvement.
Evidence
PERFVAR measurement ledger (private; summarized here)LOWBAR
Sep 13Mixed
Match provider socket buffers to kernel autotuning
4.63× / −20.8%paired throughput at an artificial 1 MiB floor, then at the realistic 32 MiB policy
Linux upstream-only fixture · six pairs, then five pairs
The same deletion helped one setup and hurt another, so the rule now depends on the kernel’s actual ceiling.
Exact figures and what they mean
In the report
Match provider socket-buffer requests to kernel autotuning
Measured
In a Linux upstream-only fixture at an artificial 1-MiB provider floor, removing the send-buffer pin improved paired throughput 4.63× (six pairs). At the realistic 32-MiB policy, the same deletion instead lost 20.8% (five pairs).
What it means for the test suites
The retained rule became conditional on the actual kernel/autotuning ceiling, not unconditional deletion. No universal 4.6× app gain. A claimed receive-rate gain was retired by noisy A/A; restored receive-buffer growth remained mechanistically proven.
Evidence
PERFVAR measurement ledger (private; summarized here)LOWBAR THROUGHPUTFIX THROUGHPUT-REPORT
Sep 14Gain
Size delivery windows to what is actually delivered
68.4 → 84.6 Mbpsin-process download, 12 interleaved pairs (ratio 1.233, 95% CI 1.064–1.306)
A later transfer-only instrument: 2.92× and 2.42× at 16 KiB, 200 and 400 ms
A real window-layer gain in its fixtures. It does not measure the whole chain, and no whole-chain forecast is claimed.
Moves
Exact figures and what they mean
In the report
Delivery-sized windows, independently checked
Measured
Twelve interleaved in-process download pairs: 68.4→84.6 Mbps, median paired ratio 1.233, 95% CI [1.064, 1.306]. A later transfer-only seven-pair instrument measured 2.92× / 2.42× at 16 KiB and 200/400 ms; absolute medians 71→190 / 34→88 Mbps.
What it means for the test suites
Real window-layer gains in distinct fixtures. The later instrument omits H3, gVisor, NAT, sockets and contracts; three drift-flagged pairs remain in its seven-ratio result. It does not measure derived whole-chain 425/830-Mbps forecasts. More retained flight and failover/hold-inversion risks were separately measured.
Evidence
PERFVAR measurement ledger (private; summarized here)LOWBAR THROUGHPUTFIX THROUGHPUT-REPORT
Sep 14–19Groundwork
Scale budgets with the target and share one accounting root
No speed claim
Lets larger profiles use spare headroom without losing track of old owners. Architecture, not a measured speed gain.
Exact figures and what they mean
In the report
Scale policy with target; share one transfer/topology root
Measured
Proportional sizing was introduced Sep 14; Sep 17–19 changes enforce shared client/provider/NAT/retiring-generation accounting and atomic admission.
What it means for the test suites
Provider-OFF sharing and larger future profiles can use bounded headroom without losing charges for old owners. This is architectural/correctness evidence, not an independently measured speed gain.
Evidence
MEMSTEADY LOWBAR
Sep 16–17Milestone
Reach gigabit-class throughput with adaptive windows
939–942 Mbpsuseful TCP payload sustained after startup, on a local TCP path with 1-Gbps service
Larger-buffer controls 942–943 Mbps · ACK-residence model 202.752 → 958.259–958.362 Mbps, ≈4.73× · RTT-change model 4.055 → 958.075 Mbps
A major achieved milestone: windows sized to what is delivered keep a fast path full. It was measured on a host-local path, and window resizing stays on after October’s pacing change.
Moves
Exact figures and what they mean
In the report
Gigabit-target adaptive windows and ACK-residence recovery
Measured
ACK-residence model 202.752→958.259–958.362 Mbps; RTT-change model 4.055→958.075 Mbps at 1-Gbps service. Local TCP-path checks sustained 939–942 Mbps after startup; larger-buffer controls reached 942–943 Mbps.
What it means for the test suites
A major achieved gigabit-class milestone. The host socket/TUN, virtual model and capacity-control scopes remain distinct; the dedicated section above preserves the bounds and slow/censored cases. Window resizing remains enabled after October's pacing removal.
Evidence
THROUGHPUT-PR2-RESULTS THROUGHPUT-REPORT-PR2 MEMSTEADY
Sep 17Gain
Choose a compact delivery history for each service
360 Bper service for the six-entry shape kept; the rejected 64-entry shape needed 3,608 B
Publish, estimate and rebucket all without allocation · H1 smoke 91.526 vs 91.552 Mbps, neutral
An exact bound on per-service state, with speed unchanged. It sets no new throughput baseline.
Exact figures and what they mean
In the report
Compact shared-service delivery history
Measured
Final six-entry shape 360 B/service versus 3,608 B for the rejected 64-entry shape. Publish/estimate/rebucket screens 375.5/450.0/98.21 ns versus 387.0/600.6/573.9 ns, all zero-allocation. H1 smoke 91.526 vs 91.552 Mbps was neutral.
What it means for the test suites
Exact bounded-state reduction; CPU screens ran under changing host load. Broad acceptance remained open, so neither model/race passes nor the smoke test establish a new throughput baseline.
Evidence
THROUGHPUT-REPORT-PR2
Sep 20Recovery
Count congestion-blocked P2P sends as service evidence
383 → 468 of 468synthetic fixed-offer admissions at 50 µs write service
At 1 ms service 422 → 468 of 468 · immediate ACKs alone reached only 317/468
It fixed the signal instead of raising the congestion window. It is not a high-latency speed test on phones.
Moves
Exact figures and what they mean
In the report
P2P cwnd-blocked service evidence
Measured
Synthetic fixed-offer admissions improved 383/468→468/468 at 50-µs write service and 422/468→468/468 at 1-ms service. Immediate ACKs alone had reached only 317/468.
What it means for the test suites
Retained service-evidence correction, rather than an arbitrary cwnd increase. One later clean two-phone replay recorded client/provider peaks 19.16/17.69 MiB with zero pressure drops; that fixture did not impose high RTT and is not a high-RTT physical speed A/B.
Evidence
MEMSTEADY PERFVAR measurement ledger (private; summarized here)
Sep 20Rejected
Reject lower Go memory soft limits
280.20 → 180.67 Mbpslocal echo when the soft limit went from 32 to 24 MiB
p95 RTT 6.426 → 12.629 ms · GC cycles 177 → 357 · for about 1.14 MiB less quiet runtime
Using less memory made it much slower, so the change was rejected. Lower residency alone is not better performance.
Exact figures and what they mean
In the report
Reject blanket lower Go soft limits and topology shrinking
Measured
Soft limit 32→24 MiB changed local echo 280.20→180.67 Mbps, p95 RTT 6.426→12.629 ms, GC cycles 177→357, for only about 1.14 MiB lower quiet runtime. Smaller client-window experiments had incomplete traffic arms.
What it means for the test suites
Rejected: lower residency alone was not better performance. The historical surrogate also had a later-discovered carrier-reliability limitation, so it is not a current app prediction. Failed traffic arms were not removed to improve survivor medians.
Evidence
MEMSTEADY PERFVAR measurement ledger (private; summarized here)
Sep 19–21Observation
A phone run passes a scoped 24 MiB check
22.55 MiBsampled peak in a scoped physical H1 run
Wikipedia median load 355.3 ms, first byte 127.7 ms · Fast.com median 40 Mbps
A pass for this scope only: not every carrier or role, and not a continuous-peak guarantee.
Moves
Exact figures and what they mean
In the report
P2P fixed-offer recovery, packet allocation and mobile retention/logging work
Measured
A post-glog scoped physical H1 run observed peak 23,646,240 B (22.55 MiB), Wikipedia load/TTFB medians 355.3/127.7 ms, and Fast.com median 40 Mbps.
What it means for the test suites
A passing scoped sampled 24-MiB result, not all carriers/roles or a continuous-peak guarantee. Earlier quiet passes with burst breaches remained failures.
Evidence
MEMSTEADY PERFVAR measurement ledger (private; summarized here)
Sep 21Gain
Allocate less per packet and shrink mobile log buffers
49.33 → 23.88 nsappending to an existing packet group, now with no allocations
Raw receive 193.9 → 169.3 ns and 280 → 168 B · three log buffers 256 → 32 KiB each, 688,128 B less
Less allocation and more headroom. A saturated log sink costs slightly more, and that trade-off is recorded.
Moves
Exact figures and what they mean
In the report
Packet allocation and mobile logging
Measured
Existing-group append 49.33→23.88 ns/op, 136→0 B/op, 2→0 allocations; raw receive 193.9→169.3 ns/op, 280→168 B/op. Three mobile log buffers 256→32 KiB each, exactly 688,128 B less capacity.
What it means for the test suites
Retained allocation/headroom improvements. Saturated log-sink cost increased 43.54→46.13 ns/line; the trade-off is recorded rather than described as a free CPU improvement.
Evidence
MEMSTEADY PERFVAR measurement ledger (private; summarized here)
Sep 22Gain
H1+: a leaner carrier inside H1
+32.35% / +18.68% / +36.31%upload, download and duplex throughput in the paired local cohort
CPU −24.35%, −16.78%, −22.56% · allocations per packet 3/2/2.5 → 1/1/1 · bytes per packet 82/34/57 → 6/5/5
Strong local carrier evidence. Loopback rates are not Fast.com, full-tunnel or battery results, and WebSocket fallback stays.
Moves
Exact figures and what they mean
In the report
General Framer and H1+
Measured
Implemented H1+ carrier paired medians: upload 11,388.68→15,343.40 Mbps, download 13,875.60→16,265.00 Mbps, duplex 21,374.16→29,009.96 Mbps. Paired effects +32.35%, +18.68%, +36.31%; CPU reductions 24.35%, 16.78%, 22.56%. Allocations/packet 3/2/2.5→1/1/1; bytes/packet 82/34/57→6/5/5.
What it means for the test suites
Strong local carrier evidence, with confidence intervals in H1PLUS.md. Standard WebSocket fallback remains required. These multi-gigabit loopback rates are not PERFVAR full-TUN, hosted Fast.com or measured battery scores.
Evidence
H1PLUS
Sep 22Gain
Give single frames a faster path in the Framer
+101.65%paired TLS upload throughput (2,378.50 → 4,795.79 Mbps)
CPU 7,742.85 → 3,916.74 ns per packet · TLS writes 300,000 → 150,000
Kept. Ready-batch controls were neutral.
Also rejected: A reusable read-header candidate lost 1.82% on upload and was rejected.
Moves
Exact figures and what they mean
In the report
General Framer singleton storage path
Measured
Ten paired TLS upload arms: 2,378.50→4,795.79 Mbps, paired +101.65%; CPU 7,742.85→3,916.74 ns/packet; TLS writes 300,000→150,000.
What it means for the test suites
Retained singleton-path optimization. Ready-batch controls were neutral. A reusable read-header candidate regressed upload 1.82% and was rejected.
Evidence
H1PLUS
Sep 22–23Gain
Carry device RPC over FramerXL, then reuse descriptors
142 → 107 µsmedian 64 KiB forward RPC (p95 304.40 → 242.83 µs)
Paired throughput +32.31% · near 3 MiB +43.73% · 256 B RPC allocation 3,608 → 1,816 B
Faster native RPC with both ends measured. Large frames still allocate; H1+ and RPC became default on Sep 23, with WebSocket fallback.
Moves
Exact figures and what they mean
In the report
Native device RPC over FramerXL, then descriptor reuse
Measured
Initial 64-KiB forward RPC p50 142→107 µs, p95 304.40→242.83 µs, paired throughput +32.31%; near-3-MiB forward throughput +43.73%. Descriptor reuse then reduced 256-B RPC allocation 3,608→1,816 B, 28→26 allocations, GC cycles 6→3, with +1.56% forward throughput over old XL.
What it means for the test suites
Both native mux endpoints/gob/TLS included; bounded per-mux storage repaired the small-RPC regression. Large-frame temporary allocation was not free, near-limit duplex retained a 4-MiB-budget negative case, and no material sampled-peak reduction was proven. H1+/RPC became default-on Sep 23 with WebSocket fallback.
Evidence
H1PLUS
Sep 22Not adopted
Try SIMD WebSocket masking
+3.52%forced-mask socket throughput at 1,280 bytes (1,310.045 → 1,355.200 MB/s)
Process CPU −2.67% · complete PERFVAR clean-LAN upload and download: no established gain
Research only, not adopted: the socket gain did not hold end to end, and battery energy was not measured.
Exact figures and what they mean
In the report
Portable SIMD WebSocket masking prototype
Measured
At 1,280 bytes, forced-mask socket throughput 1,310.045→1,355.200 MB/s (paired gain 3.52%), process CPU reduction 2.67%. Complete PERFVAR clean-LAN upload/download showed no established gain; multiplicity-adjusted socket tests were inconclusive.
What it means for the test suites
Research only, not adopted/promoted. No battery-energy measurement. The often-quoted 0.115% masking share belongs to one full-fixture CPU attribution, not every packet path.
Evidence
MEMSTEADY
Sep 23Mixed
Dispatch short bursts directly and fix an overconfident estimate
1,499.17 → 1,718.06 Mbpsvirtual-time SDK duplex median (+14.6%), with one phase 4.1% slower
An estimator had inferred 52.4288 MB/s from a 12.5 MB/s source; it now keeps 12.5
Deterministic sizing and recovery fixes in virtual time, not a CPU, energy or physical-speed gain. Later pacing work supersedes it.
Exact figures and what they mean
In the report
Short-path dispatch and estimator provenance
Measured
Virtual-time five-phase SDK duplex median 1,499.17→1,718.06 Mbps (+14.6%), with one phase 4.1% slower. A recovered-prefix estimator falsely inferred 52.4288 MB/s from a 12.5-MB/s serialized source; the correction preserved 12.5 and admitted later independent 25-MB/s evidence.
What it means for the test suites
Deterministic sizing/recovery improvements and guarded virtual throughput, not host CPU/energy or physical-speed gains. Later pacing-off work supersedes extrapolating this scheduling result to today's default.
Evidence
MEMSTEADY
Sep 25–26Mixed
Test shorter retransmission caps and UDP without ACKs
≈18.7% / ≈64.1%faster recovery after six and ten drops with a 2 s cap (240/240 streams correct)
Cost rose with high RTT and one loss · UDP NoAck 213.627 → 213.345 Mbps on H1, 256.042 → 256.964 Mbps on P2P
Faster after many drops, costlier on slow links, so there is no global 2 s default. UDP NoAck was kept as a policy at the same speed.
Exact figures and what they mean
In the report
Retransmission caps, TCP-collapse custody and established UDP NoAck
Measured
Ten-pair 8s-vs-2s TUN confirmation: 240/240 streams correct; six-drop recovery ~18.7% faster, ten-drop ~64.1% faster. High-RTT/one-loss cost increased, so no global 2-second default was justified. Established UDP H1 clean upload medians 213.627→213.345 Mbps (ACK→NoAck); P2P 256.042→256.964 Mbps.
What it means for the test suites
Timer research was mixed; 3/3 and 5/5 pilots were not qualified default wins. UDP NoAck was retained as a policy choice with comparable measured performance, not a speedup. A logical-group bypass regressed H3 and was removed. TCP remains ACK-required.
Evidence
RTOPT
Sep 30Groundwork
Adopt larger memory profiles and stop early Android trims
64 / 32 MiBAndroid and iOS admission budgets, up from 28 and 20 MiB
Android reclaim threshold 24 → 48 MiB · forced trims 1,1 → 0,0 · resume pool creations 44/41 → 0/0
A policy and maintenance change, not proof of higher speed. A larger cap is not a memory-efficiency gain.
Exact figures and what they mean
In the report
Adopt larger profiles and avoid premature Android64 reclaim
Measured
Android admission/soft 28/40→64/64 MiB, iOS admission 20→32 MiB with soft32. Android reclaim threshold 24→48 MiB: two-run forced trims 1,1→0,0, quiet GC CPU 0.0601/0.0707→0.0242/0.0322 s, resume pool creations 44/41→0/0.
What it means for the test suites
Retained policy/maintenance improvement, not proof of higher speed. Two noisy host repetitions at full Android capacity had quality/speed means 354.90/358.84→342.40/340.69 Mbps; roots were unsaturated. Hardware clamping still applies. Neither host screens nor partial device cells qualify the profile matrix or native iOS footprint.
Evidence
MEMSTEADY LOWBAR

October

Oct 2–24 · 11 entries

2 gains
3 recoveries
2 observations
4 groundwork

Oct 2–5Recovery
Repair NAT-stage custody so uploads finish
6/6exact 32 MiB H1 upload streams, default and mobile, three fresh processes each
About 0.377–0.381 s default · about 0.559–0.566 s mobile · the outer TCP PTO needed a separate gVisor fix
A liveness repair with diagnostic timings, not a calibrated speed effect. Two causes, two fixes.
Moves
Exact figures and what they mean
In the report
TCP PTO/reverse-traffic and provider NAT-stage custody
Measured
A distinct NAT-stage repair completed default and mobile 32-MiB H1 uploads in three fresh processes per comparison: 6/6 exact streams, approximately 0.377–0.381 s default and 0.559–0.566 s mobile. The outer-TCP PTO issue required a separate managed gVisor fix.
What it means for the test suites
Deterministic correctness/liveness repair and diagnostic timings. These are not a calibrated PERFVAR speed effect; the two causes must not be merged into one explanation.
Evidence
RTOPT
Oct 7–10Groundwork
Repair how loaded H1 traffic is measured
No speed claim
The measurement improved, not the product’s score: replies settle by their own deadlines and every one counts.
Exact figures and what they mean
In the report
H1 loaded-traffic diagnosis and measurement repair
Measured
The historical 0/64 loaded-probe failure motivated owner/trace work. Later runs had varying offer counts and calibration failures; some apparent p95/reliability improvements used different cohorts or excluded unresolved replies.
What it means for the test suites
No qualified overall H1 speed improvement can be assigned here. Better settlement, source/owner guards and full denominators improved the measurement system, not the product's score.
Evidence
PERFVAR measurement ledger (private; summarized here)
Oct 14Groundwork
Give each device owner its own low-memory policy
No speed claim
An explicit 32 MiB policy per owner, which is not a server memory cap. Policy correctness, with no speed claim.
Exact figures and what they mean
In the report
Shared iOS/proxy low-memory policy
Measured
Explicit per-owner 32-MiB policy replaced numeric-only proxy targeting; Android remains 64 MiB. Owner-settings cloning prevents unrelated devices from sharing mutable budget assignments.
What it means for the test suites
Policy/ownership correctness. The per-device proxy target is not a 32-MiB server-process RSS cap, and this change has no established speed uplift.
Evidence
MEMSTEADY LOWBAR
Oct 16–18Gain
Correct H1 memory claims and make admission allocation-free
128 B → 16 Bper canceled write on one route, 2 → 1 allocations
Two routes 368 → 144 B · three routes 1,976 → 1,640 B · ready-path allocations unchanged
Less allocation and honest memory admission. No end-to-end throughput increase is shown.
Moves
Exact figures and what they mean
In the report
Correct H1 retained-root claims and allocation-free successful admission
Measured
Measured retained H1/H1+ roots exceeded old claims. Corrected accounting retained channel sizes. Lazy byte-notification creation reduced one-route canceled-write cost 128 B/2 allocs→16 B/1 alloc, two-route 368 B/7→144 B/5, three-route 1,976 B/21→1,640 B/18. Ready-path allocations stayed unchanged.
What it means for the test suites
Retained allocation reduction plus honest memory admission; no demonstrated end-to-end throughput increase. Receive/ACK custody and refusal fixes protect unrelated flows but still require whole-path qualification.
Evidence
MEMSTEADY
Oct 19Gain
Release finished readers in gVisor TCP
7.86 → 0.54 MiBwarm-heap spread in one matched race diagnostic (−93.1%)
Closed endpoints had kept 128 KiB caller arrays · three normal and three race SDK confirmations passed
A strong local retention fix. It is not a phone runtime or throughput result.
Moves
Exact figures and what they mean
In the report
Release exhausted caller readers in gVisor TCP
Measured
One matched race diagnostic: warm-heap spread 8,243,416 B (7.86 MiB)→567,664 B (0.54 MiB). Old endpoints retained 128-KiB caller arrays through io.LimitedReader.R; clear the reader while preserving TCP lifetimes. Three normal and three race SDK-load confirmations passed.
What it means for the test suites
Strong local retention fix, not a phone runtime or throughput result. Endpoint counts remained similar, supporting reference release rather than changed TCP-close behavior.
Evidence
MEMSTEADY
Oct 20–21Groundwork
Keep busy channels and native input from blocking each other
No speed claim
Correctness and regression coverage. It is not a measured fix for the pauses seen on real devices.
Exact figures and what they mean
In the report
Preserve busy channels on local probe refusal; isolate native input admission
Measured
Deterministic tests reproduced a serialized native-read delay when a packet-send call waits; remote admission was made zero-wait while preserving reliable ownership. Earlier easy 100-page tests passed old and new code, so they did not explain the reported session.
What it means for the test suites
Correctness and regression coverage, not an independently measured real-device pause fix. Later flowing-body tests were required to expose deeper stalls.
Evidence
PERFVAR measurement ledger (private; summarized here)
Oct 21Recovery
Turn off extra application pacing
63.078 → 3.159 sslowest first byte: pacing on stopped after 49 pages, pacing off finished 100/100
Slow navigations 10 → 0 · canonical default-off replay: 100 pages, none paused 5 s or more, max 2.717 s
A major recovery without raising memory budgets. It was not a powered speed cohort, and pacing was not the only cause.
Moves
Exact figures and what they mean
In the report
Disable extra application pacing; retain delivery-window resizing
Measured
A pacing-on confirmation run completed 49 HTML, with 10 slow navigations, max first byte 63.078 s, before failure; pacing-off completed 100/100, zero slow, max 3.159 s. Canonical default-off replay: 100 pages, zero ≥5-s pauses, max 2.717 s; post-sync explicit-gate run max 3.094 s.
What it means for the test suites
A major synthetic functional recovery without raising memory budgets. Drain-only removal still failed. These were not a statistically powered same-source speed cohort; later SDK/cold-flow failures showed that pacing was not the only cause. Window-resizing correctness remains independently required.
Evidence
PERFVAR measurement ledger (private; summarized here)connect 4e99435f
Oct 21–23Groundwork
Back off provider discovery instead of retrying blindly
No speed claim
Control-plane load and availability work, separate from the packet pacing above. No measured speed gain.
Exact figures and what they mean
In the report
Discovery retry pacing and bounded live demand
Measured
Unproductive expansion backs off instead of repeatedly minting identities; admitted/lost exits or network changes end the wait. Later fixes preserve pending demand and healthy-window selection.
What it means for the test suites
Control-plane load/availability work. Do not confuse discovery backoff with the packet-byte pacing disabled above. No qualified PERFVAR/Fast.com gain is recorded for discovery backoff.
Evidence
MEMSTEADY connect ae6988d6 connect de1f7829 connect 840c801f connect 4ac950b3
Oct 22Observation
Check single hosted phone-profile cells
28.54 / 32 MiBpeak in a Wi-Fi iOS-profile cell, with a Fast median of 13 Mbps
Android 64 MiB cell: peak 39.03 / 64 MiB, Fast 40/84/13 Mbps, median 40
Single observations, not paired A/Bs. They do not show that a doubled budget made Android faster.
Moves
Exact figures and what they mean
In the report
Individual hosted mobile-profile cells
Measured
One Wi-Fi iOS-surrogate cell: peak 28.54/32 MiB, Fast median 13 Mbps. Separate Android64 cell: peak 39.03/64 MiB, Fast 40/84/13 Mbps, median 40.
What it means for the test suites
Individual memory/speed observations, not paired budget A/Bs and not complete profile qualification. They do not show that doubling the budget caused the faster Android result.
Evidence
PERFVAR measurement ledger (private; summarized here)
Oct 24Recovery
Pick providers by service health and fix SYN custody
5.675 → 3.566 sfirst byte of page 1 in one combined recovery replay
All-page median 1.136 → 0.982 s · canonical v2 SDK100: median, p95 and max 0.858, 2.066 and 3.780 s, no page 5 s or more
A meaningful recovery of this synthetic workload. The bundle was not an isolated A/B, and v1 and v2 results are not pooled.
Moves
Exact figures and what they mean
In the report
Service-aware affinity, healthy-window selection, cancellation and SYN-custody fixes
Measured
One combined recovery replay: page-1 first byte 5.675→3.566 s, all-page median 1.136→0.982 s, zero ≥5-s pages. Later canonical v2 SDK100: median/p95/max 0.858/2.066/3.780 s, 100 HTML/400 assets/99 overlaps, zero ≥5-s pages.
What it means for the test suites
Meaningful functional recovery of the named synthetic workload. The candidate bundle was not an isolated affinity A/B; v1/v2 workload changes prevent pooling results. Refused SYN offers must not start provider-silence clocks; that causal fix is not attribution of the observed physical DNS delay.
Evidence
PERFVAR measurement ledger (private; summarized here)connect 897b2321 connect e90d59eb connect 2779eec9 connect ac162a0f
Oct 24Observation
The latest phone cell
545.7 msmedian Wikipedia load in a physical H1 iOS-profile cell (first byte 206.2 ms)
Peak, quiet and teardown 29.301, 24.262 and 23.363 MiB, no 32 MiB breach · first page 33.044 s, including DNS 18.103 s · Fast 32 and 9.9 Mbps; the third attempt timed out
It passed sampled memory but failed workload eligibility, and 111 of 112 other cells were not run. The median hides a cold pause.
Moves
Exact figures and what they mean
In the report
Latest retained physical H1 iOS-surrogate cell
Measured
Peak/quiet/teardown 29.301/24.262/23.363 MiB, zero observed 32-MiB breaches; Wikipedia median TTFB/load 206.2/545.7 ms. The first page took 33.044 s, including reported DNS 18.103 s. Fast valid displays 32, 9.9 Mbps; the third attempt timed out.
What it means for the test suites
This cell passed sampled memory but failed workload eligibility; 111/112 other cells were not run. Medians hide the cold pause. Neither Android64 nor complete iOS32 qualification follows.
Evidence
PERFVAR measurement ledger (private; summarized here)

Where the meters ended

As of Oct 2439 of 39

Page loadlatest median

545.7ms

latest phone cell, Oct 244.7–7.3× faster than Aug 24, low confidence

Bulk speedcontrolled H1

41Mbps

from about 6.1, 6.7× · 6 other readings

Packet pathnever multiplied

11speed-ups

Memorynever summed

5reductions

Recoveriescount

8stalls fixed

H1 handoff dropsAug 25
Playback after poisoned exitsAug 26–27
Mixed-route flight-gate collapseSep 9–11
Retransmission timeout stormsSep 12–13
P2P fixed-offer admissionsSep 20
NAT-stage uploadsOct 2–5
100-page browsing testOct 21
SDK100 pages under 5 sOct 24

Methods

How the research was done

The program moved from exploratory tuning toward tests that tell competing causes apart. Each method has a short schematic animation, and the example beside it comes from the timeline.

Schematic. The Oct 19 fix released readers that closed endpoints kept alive: one matched diagnostic’s warm-heap spread fell from 7.86 to 0.54 MiB.
01
Find out what actually holds the memory
Split memory and time by what actually owns them before changing anything, so a fix targets what is really there.
Seen inAug 25–26: Count retained memory separately from data in flight Oct 16–18: Correct H1 memory claims and make admission allocation-free Oct 19: Release finished readers in gVisor TCP
In the report
Profile and measure the actual owners. Go allocation/heap/goroutine investigations, packet-root accounting, queue high-water/drop counters, GC cycles/CPU and process measurements distinguished live payload, free-list retention, allocator slack, goroutine topology and stale references. Memory measurements kept heap, Go runtime, RSS and iOS kernel footprint separate. Source-level capacity arithmetic was checked against actual retained roots.
Schematic. In the latest phone cell the first page took 33.044 s, 18.103 s of it in DNS; how the rest divides is drawn for illustration.
02
Find where the time goes
Trace a slow request stage by stage to find where the time goes. A stage with no instrumentation is unknown, not zero.
Seen inAug 24: Find the limiter with deeper sequence queues Oct 7–10: Repair how loaded H1 traffic is measured Oct 24: The latest phone cell
In the report
Find the limiting boundary, not merely the slow request. Packet/ACK lineage, per-lane resend and cumulative/selective ACK counters, TCP/TLS/request timing, provider selection receipts and browser CDP/NavigationTiming located pauses before admission, during carrier/queue transit, at TCP establishment or in DNS. Missing instrumentation was classified as unknown, not proof of a zero or a stall.
Schematic. A fixed clock (Go’s synctest), held queues and exact barriers pin each step, and the old code stays as the counterfactual.
03
Make failures repeat exactly
Run the code on a fixed clock with held queues, so a failure lands on the same tick every run and the fix can be proven against the old code.
Seen inOct 2–5: Repair NAT-stage custody so uploads finish Oct 20–21: Keep busy channels and native input from blocking each other Sep 23: Dispatch short bursts directly and fix an overconfident estimate
In the report
Reproduce mechanisms deterministically. Fixed clocks (synctest), held queues/receipts, exact refused admissions, controlled ACK/body-release barriers, loss injection and old-code counterfactuals pinned the causal invariant. Tests covered cancellation, sequence wrap, SYN/FIN/RST generations, legacy peers, sibling flows, zero/shared budgets and returned ownership. Normal and race modes catch different failure classes.
From the Oct 21 entry: with pacing on the run stopped after 49 pages, removing only the drain still failed, and with pacing off it finished 100 of 100. Window resizing stayed.
04
Change one thing at a time
Change one factor at a time against the old behavior, and keep the treatments that failed in the record.
Seen inOct 21: Turn off extra application pacing Aug 24: Find the limiter with deeper sequence queues Sep 13: Match provider socket buffers to kernel autotuning
In the report
Use ablations and negative controls. Change only pacing, only drains, only window sizing, only allocation ownership or only a buffer rule. Keep failed candidates and compare against old behavior. Examples include the failed drain-only browsing treatment, the root-depth increase that removed drops without increasing speed, and the socket change that helped a synthetic floor but hurt a realistic profile.
From the Sep 22 SIMD masking test: +3.52% at the socket, no established gain in the complete PERFVAR run, so it was not adopted.
05
Measure at every layer
A gain in a microbenchmark is a question for the carrier, the simulator and the phone. Each layer gets its own measurement.
Seen inAug 25: Send a provider’s packets as one group Sep 22: H1+: a leaner carrier inside H1 Sep 13: Match provider socket buffers to kernel autotuning Sep 16–17: Reach gigabit-class throughput with adaptive windows
In the report
Measure several layers. Microbenchmarks isolate cost/op and allocations; real localhost TCP/TLS and native RPC measure carrier work; full-TUN/provider simulators test composition under seeded bandwidth/RTT/jitter/loss/MTU/outage; Android browser runs exercise Wikipedia/Fast.com on Wi-Fi/cellular. None substitutes for the next layer. Linux kernel/socket conclusions require the corresponding Linux fixture.
Schematic. On identical code, an A/A check flagged 15 of 17 cells at five repetitions, so earlier small verdicts were retired.
06
Measure the noise first
Interleave old and new runs in fresh processes, and run identical code against itself, so a small difference has to beat measured noise before it counts.
Seen inAug 24: Check whether the server got slower Sep 12–13: Stop retransmission storms Sep 14: Size delivery windows to what is actually delivered
In the report
Balance comparisons and quantify noise. Same-binary switches, immutable source overlays, alternating/interleaved fresh-process blocks and baseline/candidate/candidate/baseline order reduce drift. A/A estimates establish detectable effects. Paired ratios, bootstrap intervals, exact tests and multiplicity correction are used where the cohort supports them; pilots and one-off passes remain explicitly weaker evidence.
Schematic. Failed and calibration-invalid rows stay in the record, deadlines are never silently extended, and bad providers are not dropped after the results are seen.
07
Keep every result, failures included
Keep every attempt, failed and invalid runs included, check the bytes delivered, and never drop bad runs to improve a median.
Seen inSep 19–21: A phone run passes a scoped 24 MiB check Sep 20: Reject lower Go memory soft limits Oct 7–10: Repair how loaded H1 traffic is measured Sep 16–17: Reach gigabit-class throughput with adaptive windows
In the report
Treat evidence validity as part of the test. Preserve useful-byte hashes, exact attempt counts, failed/calibration-invalid rows, source/toolchain identities and raw artifacts. Join background workers and process groups before final memory accounting. Do not force GC to create a steady-memory pass, silently extend deadlines, discard bad providers after seeing results, or compare only successful tail samples. CPU reductions are energy hypotheses until actual energy is measured.

Milestone

Gigabit-class throughput with adaptive windows

Adaptive window resizing took the network’s local TCP path to gigabit-class delivery: 939–942 Mbps of useful payload, sustained after startup on a path with 1-Gbps service, and about 942–943 Mbps in larger-buffer controls. It replaced a fixed window with one sized to what is actually delivered, and repaired the feedback that keeps a fast path full.

It is host-local evidence, not a claim that every phone or public provider delivers gigabit service. Window resizing is still on by default: turning off the extra pacing in October did not remove it.

The host TCP path, 100-ms eight-flow upload: 626.2 Mbps in the first measured second, then 939–942 Mbps for each of the next nine; the ten-second mean was 908.9 Mbps. The startup second stays in the record and is not the steady rate.

939–942 Mbpssustained after startup: the host TCP path, 100 ms, eight flows

≈4.73×the ACK-residence correction: 202.752 → 958.259–958.362 model Mbps

942–943 Mbpsfinal larger-buffer capacity controls, including a single-flow upload

4.055 → 958.075model Mbps after an RTT increase at 1 Gbps, against a 958.095 reference

What changed

Replace the fixed window with an adaptive one
Qualified delivered-byte/rate and feedback-residence evidence can grow the send window; the receiver advertises usable credit. Peer permission, explicit endpoint limits and shared memory admission remain hard bounds. A larger permitted window is not an eager allocation of that many bytes.
Preserve older providers
A peer without a receive-window advertisement keeps the historical opening-window behavior; missing compression metadata retains the legacy 10-ms assumption. Resizing cannot grant permission beyond the peer or shared budget.
Account for ACK compression in sizing
A fast path can still starve if the window covers propagation but not the delayed/compressed ACK interval. Sizing includes the relevant feedback residence while retransmission timing keeps its separate RTT semantics.
Recover after path-quality changes
Ordinary evidence grows the learned window; a bounded quality-change generation permits replacement using fresh service and RTT evidence. SDK, Android, Apple, Windows and Linux hooks propagate the quality event. Repeated noise does not repeatedly renew the generation.
Keep window sizing separate from pacing
Delivery-window resizing is still the shipping default (WindowSizingFromDelivery). The extra application byte-pacing layer was subsequently disabled to address browsing stalls. That later correction did not discard the window-resizing work or its receiver/memory guards.

Recorded impact and evidence strength

Experiment	Before → after	What it establishes
ACK-residence correction, 0.3-ms path and advertised 10-ms compression	202.752→958.259–958.362 model Mbps, about 4.73×	Three race-enabled mechanism checks on a 1-Gbps virtual FIFO. Both arms were explicitly held to the advertised compression interval after an earlier stimulus defect was corrected.
RTT increase during traffic, eight flows, 10-ms compression	At 1 Gbps: 4.055→958.075 model Mbps, versus 958.095 reference. At 100 Mbps: 7.148→95.805, matching reference.	Recovery of a severe window/feedback collapse, with every flow progressing and zero measured relay drops. This is virtual-time evidence, not a physical-device speed result.
Host TCP path, 100-ms eight-flow upload	626.2 Mbps in the first measured second, then 939–942 Mbps for the next nine; ten-second mean 908.9 Mbps	Actual local socket/NAT/TUN-path gigabit-class steady delivery. Startup is retained and must not be described as the steady rate.
Short-path SDK duplex phase study, September 23	Aggregate median 1,499.17→1,718.06 model Mbps; later short-duplex check 1,826.60 model Mbps	Capacity and feedback behavior of the SDK construction in a virtual-time instrument. Aggregate bidirectional throughput is not one-direction Internet throughput.
Final deterministic window matrix	Minimum candidate/reference 99.9% in the 36 RTT/flow/compression cells; 99.3% in 108 endpoint-mismatch cells; 98.8% in six live receiver-window changes	The benefit was exercised across window/RTT changes and asymmetric limits, not just one large clean window.

The achievement and the remaining guards both matter. Some host comparisons were calibration-censored or slow; one default-buffer 100-ms single-flow upload deteriorated to 7.7 Mbps. Those failures remain in the original reports. The headline is that gigabit-class delivery was achieved and adaptive windows removed major limits—not that every rate, host, profile or later build had already passed. The 32-MiB iOS and 64-MiB Android memory qualifications remain separate, and a desktop/capacity-control window must not be assigned to a phone without its admission budget.

In the report

Achieving gigabit-class delivery was a major result of this research. The work replaced a fixed-window bottleneck with delivery-sized windows and repaired the feedback/ACK behavior needed to keep a fast path full. It deserves to stand alongside H1+, batching and memory retention as a headline improvement, rather than appear only as an intermediate 68→85-Mbps experiment.

The result was more than an arithmetic prediction. The local TCP-path instrument—real loopback kernel origin, provider NAT, Transfer and gVisor application/TUN sockets—recorded sustained 939–942 Mbps after startup in its 100-ms, eight-flow upload check. Final larger-buffer capacity controls recorded approximately 942–943 Mbps, including the 100-ms single-flow upload. This is gigabit-class useful payload on the instrument's 1-Gbps path; protocol overhead and the payload accounting explain why these readings are below 1,000 Mbps. It is host-local TCP-path evidence, not a claim that every mobile device or public provider supplies gigabit Internet service.

THROUGHPUT-PR2-RESULTS THROUGHPUT-REPORT-PR2 MEMSTEADY THROUGHPUTFIX THROUGHPUT-REPORT

Start to end

How far each kind of gain went

The report’s own estimates, axis by axis, with the confidence each one deserves.

Page load

≈4.7–7.3×

faster median Wikipedia load (79–86% less time): from 2,552.3 or 3,967.8 ms on Aug 24 to 545.7 ms on Oct 24

Confidence Low. A historical observation across two different starting workloads, not a confidence interval or a causal A/B. The latest cell still had a 33-second cold first page.

In the report

Start-to-end evidence: Aug 24 explicit-H1 control 2,552.3 ms, or the low-bar bundled baseline 3,967.8 ms; latest Oct 24 physical cell median 545.7 ms.
Estimate and confidence: Approximately 4.7–7.3× faster median loading (79–86% less time) as a historical observation. This range reflects two different starting workloads, not a confidence interval or causal A/B. Providers, builds, profiles and memory limits differ; the latest cell still had a 33-second cold-page stall. Treat this as a low-confidence user-visible estimate, not a release guarantee.

Bulk speed

≈6.7×

recovery on the controlled H1 path: about 6.1 Mbps, then 38, 41 and 52 Mbps after the handoff fix

Confidence Stronger mechanism evidence than public-route comparisons, but not the net gain of every change through October. Public speeds still vary.

In the report

Start-to-end evidence: Aug 25 exact-provider drop-prone path about 6.1 Mbps, corrected handoffs 38/41/52 Mbps, median 41.
Estimate and confidence: Approximately 6.7× recovery in that historical experiment; stronger mechanism evidence than public-route comparisons. It is not the net gain from every change through October. Current public speed remains variable and failed/incomplete cells remain.

Adaptive windows

≈4.73×

faster in the adaptive-window model, 202.752 to 958.259–958.362 Mbps, and gigabit-class on a local TCP path: 939–942 Mbps sustained after startup, about 942–943 Mbps in larger-buffer controls

Confidence Measured on a host-local TCP path (kernel sockets, provider NAT, Transfer, gVisor and TUN), not on a phone or a public provider. Some host comparisons were calibration-censored or slow, and they stay in the record.

In the report

Packet path

2.81× · 2.02× · 1.19–1.36×

grouped provider sends, the Framer singleton path and the H1+ carrier, each measured alone

Confidence Bounded and reproducible. They overlap in the pipeline and must not be multiplied; their combined effect on page load, Fast.com or battery is not identifiable.

In the report

Start-to-end evidence: Grouping 2.81× drain throughput; Framer singleton 2.02×; production H1+ 1.19–1.36× paired carrier throughput, depending on direction.
Estimate and confidence: These are bounded, reproducible component gains. They overlap in the pipeline and must not be multiplied. Without matching start/end whole-stack profiles, their combined contribution to page load, Fast.com or battery life is not identifiable.

Memory

−26.4% · −7.5% · −93.1%

retained-byte accounting, the shared provider UDP lifecycle and the released TCP readers

Confidence Different owners and workloads, so there is no common total. The larger 32 and 64 MiB budgets are not an efficiency gain.

In the report

Start-to-end evidence: Historical retained-byte repair 29.59→21.77 MiB (−26.4%); shared UDP host runtime −7.5%; stale-reader warm-heap spread −93.1% in its matched diagnostic.
Estimate and confidence: Different owners and workloads, so no common “total memory saved.” Current 32/64-MiB limits deliberately permit more useful work than the old 24-MiB profile. A higher later runtime does not by itself negate an allocation fix, and a larger cap is not a memory-efficiency gain.

Recoveries

stalls and failures fixed, from H1 handoff drops in August to pages over 5 s in the 100-page test in October

Confidence Each is a functional recovery in its own named workload. None is a speed multiplier.

The whole app

No single number

No same-source start-to-end campaign spans the period. Several campaigns failed or stopped, and the measurement protocol changed.

Confidence The research supports large local gains and recovered functionality, not a claim that the whole app is a fixed percentage faster or that every final gate passes.

In the report

Start-to-end evidence: No same-source-compatible start/end complete campaign spans the whole period. Several campaigns failed or stopped; the measurement protocol evolved.
Estimate and confidence: No defensible aggregate percentage. The report supports large local gains and recovered functionality, not a claim that the entire app is a fixed percentage faster or that all final gates pass.

“The research substantially reduced per-packet work and restored several stalled paths; representative page-load medians improved by roughly five to seven times across recorded device observations, but cold pauses, public-provider variance and incomplete final qualification prevent treating that as a universal net product gain.”
The report’s own one-sentence summary

Instruments

What changed in the tests themselves

The test coverage improved substantially, even where performance is still open.

LOWBAR

Constrained links are now judged by useful delivery, wasted resends and finite queues, not only clean-path speed.

In the report

constrained-rate, MTU, loss, mixed-route and fixed-offer cases now check useful delivery, retransmission/wire cost and finite queues, rather than only clean-path bulk speed.

PERFVAR

Every scheduled attempt stays in the record, and noise is measured before a small gain counts.

In the report

scenario identity and A/A noise matter; every scheduled attempt and failed/calibration-invalid arm remains in the record. Five repeats cannot automatically establish a small gain. Loaded-probe cohorts must settle through their own deadlines rather than be silently discarded when bulk completes.

MEMSTEADY

Memory is measured through startup, traffic, quiet, drain and teardown, and a later low sample never erases an earlier breach.

In the report

Go soft limits and logical credit are not observed runtime caps. Startup, traffic, quiet, drain and joined teardown all count. The current iOS surrogate is tested on allowlisted Android phones at 32 MiB, while normal Android is independently tested at 64 MiB. A later low sample cannot erase an earlier breach.

Browsing

Page tests grew from easy sequential pages to 100 real pages with assets, unfinished bodies and overlapping navigation.

In the report

tests evolved from sequential/easy pages to 100 pages of 50–300 KiB with real HTML/assets, unfinished bodies and overlapping navigation, then actual SDK/public-provider recovery and verified inner TLS/H2. Those fixture generations are distinct measurements, not interchangeable score rows.

Open questions

What is not yet shown

No cumulative app-speed or battery improvement is claimed. These are the gaps the next qualification has to close.

The cold first page
In the latest phone cell the first page took 33.044 s, 18.103 s of it in DNS. Medians hide that pause, and the cold-connection and device pause investigation is still open.
The phone-profile matrix
The complete physical matrix, 32 MiB for the iOS profile and 64 MiB for Android, is not qualified. In the latest run, 111 of 112 cells were not run, and a single memory pass or a fast public exit does not qualify it.
The full campaign
The complete correctness and PERF campaign has not been qualified. Source changes interrupted later qualification, and interrupted or source-invalid runs get no performance credit.
A native iPhone
There is no native-iPhone evidence for the requested extension lifetime footprint under 50 MiB. Android and host tests cannot supply it.
Two open investigations
The cold-destination and provider-admission comparison, and an independent encoding and pool-ownership investigation.
Battery
Every CPU reduction here is an energy hypothesis until energy is measured. No battery improvement is claimed.

The latest result, summarized

After the October 24 entries, a warm 100-page synthetic run over HTTP/2 passed ten component roots and one full 100-page run, in normal and in race mode, with joined cleanup and no pause of 5 s or more. Normal median, p95 and max were 0.949, 1.905 and 2.749 s; the race-mode max was 3.364 s. It is a warm four-origin cell-edge test (5/1 Mbps, 120 ms base RTT, jitter and loss), not a public Wi-Fi comparison, a cold-provider test or a memory qualification.

Glossary

Terms used in this report

A/A test: Running identical code against itself. The spread of its results is the noise a real difference has to beat.
ACK: An acknowledgment: the receiver’s signal that data arrived, so the sender can move on instead of resending.
ACK compression: Acknowledgments that arrive bunched together after a delay, so the sender learns of delivered data later than the path’s travel time alone would suggest.
Admission: Accepting new traffic only when the memory budget has room for it.
Carrier: A connection that carries URnetwork traffic between a device and the network, such as H1, H3 or P2P.
Connect: URnetwork’s open source networking library, which carries traffic between clients and providers.
Drain: Taking every queued packet off a queue in one pass.
Fast.com: A public download speed test, run here in a phone’s browser.
Framer: The format that marks where each message starts and ends on a carrier. FramerXL is the variant for large device RPC frames.
GC: Garbage collection: Go reclaiming memory that is no longer used. GOGC and the soft limit set how often and how hard it works.
Goroutine: A lightweight Go thread. Each one holds memory, so fewer is cheaper.
gVisor: An open source user-space network stack. Connect runs TCP/IP in it on the device.
H1: The carrier family over TLS, WebSocket and TCP, which passes through ordinary web infrastructure.
H1+: An upgrade inside H1 that sends the Framer format straight over the TLS stream, with a plain WebSocket as the fallback.
H3: The carrier family over QUIC.
iOS profile: The 32 MiB memory budget that stands in for an iPhone network extension, tested on allowlisted Android phones.
LOWBAR: The test suite for constrained links: delivery and latency at low rates, small MTU, loss and mixed routes.
Median: The middle value of a set of measurements.
MEMSTEADY: The test suite for memory over time: runtime peaks, quiet behavior, teardown and which code owns the memory.
MiB: A mebibyte, 1,048,576 bytes.
Model Mbps: A rate measured in a virtual-time model of the path rather than on real sockets. It shows that a mechanism works, not what a device gets.
NAT: Network address translation: mapping between private and public addresses, here on the provider.
P2P: A direct carrier between two devices.
p95: The value that 95% of the measurements stay at or below.
Pacing: Spacing packets out over time instead of sending them as soon as they are ready.
Pack: A Connect message that carries one or more packets on the wire.
PERFVAR: The performance suite: throughput, latency, wire and retransmission cost, correctness and calibration, scenario by scenario.
Provider: A device that shares its connection with the network. Traffic leaves the network through it.
PTO: Probe timeout: the point where a TCP sender stops waiting and probes for lost data.
Race mode: A Go build with the race detector on. It runs slower and catches data races.
RPC: Remote procedure call. Device RPC is the SDK’s local channel between the app and its network service on the same device.
RTT: Round-trip time: how long a message takes to get there and back.
SDK: The URnetwork software kit that the apps build on. It runs Connect on the device.
SYN: The first packet of a new TCP connection.
synctest: Go’s test package that runs code on a fake clock, so the timing is identical on every run.
TTFB: Time to first byte: how long until the first byte of a response arrives.
TUN: A virtual network interface. Full-TUN tests send traffic through the whole tunnel.
WebSocket masking: The XOR scrambling a WebSocket client must apply to everything it sends.
Window: How much data may be in flight before the sender waits for an acknowledgment. cwnd is the congestion window.

Source: Network performance research impact, 2026-08-24 to 2026-10-24 , in urnetwork/connect. Every figure is quoted from it unrounded; percentages and ratios appear only where the report states them. Updated 2026-10-30.

At a glance

The 39 entries, by date

Why it matters

Pages open without waiting

Full speed for streams and downloads

Encrypted traffic that costs less work

Light enough for a phone

No stalls to notice

Rebalance mobile memory and speed settings together

Check whether the server got slower

Find the limiter with deeper sequence queues

Send a provider’s packets as one group

Write ready H1 frames without waiting

Stop H1 handoffs from dropping under load

Count retained memory separately from data in flight

Recover from poisoned exits and choose healthier providers

Share UDP readiness and idle handling on providers

Bound the TCP inbound handoff

Remove the flight-gate collapse on mixed routes

Stop retransmission storms

Match provider socket buffers to kernel autotuning

Size delivery windows to what is actually delivered

Scale budgets with the target and share one accounting root

Reach gigabit-class throughput with adaptive windows

Choose a compact delivery history for each service

Count congestion-blocked P2P sends as service evidence

Reject lower Go memory soft limits

A phone run passes a scoped 24 MiB check

Allocate less per packet and shrink mobile log buffers

H1+: a leaner carrier inside H1

Give single frames a faster path in the Framer

Carry device RPC over FramerXL, then reuse descriptors

Try SIMD WebSocket masking

Dispatch short bursts directly and fix an overconfident estimate

Test shorter retransmission caps and UDP without ACKs

Adopt larger memory profiles and stop early Android trims

Repair NAT-stage custody so uploads finish

Repair how loaded H1 traffic is measured

Give each device owner its own low-memory policy

Correct H1 memory claims and make admission allocation-free

Release finished readers in gVisor TCP

Keep busy channels and native input from blocking each other

Turn off extra application pacing

Back off provider discovery instead of retrying blindly

Check single hosted phone-profile cells

Pick providers by service health and fix SYN custody

The latest phone cell

Where the meters ended

Page loadlatest median

Bulk speedcontrolled H1

Packet pathnever multiplied

Memorynever summed

Recoveriescount

Find out what actually holds the memory

Find where the time goes

Make failures repeat exactly

Change one thing at a time

Measure at every layer

Measure the noise first

Keep every result, failures included

What changed

Replace the fixed window with an adaptive one

Preserve older providers

Account for ACK compression in sizing

Recover after path-quality changes

Keep window sizing separate from pacing

Recorded impact and evidence strength

Page load

Bulk speed

Adaptive windows

Packet path

Memory

Recoveries

The whole app

LOWBAR

PERFVAR

MEMSTEADY

Browsing

The cold first page

The phone-profile matrix