### System details

AMD Ryzen 9 5900X 2.5 GbE wired Ethernet 1 Gbps symmetric Internet service Omarchy 4.x

### What's wrong?

The built-in Omarchy Network Speed Test consistently reports upload throughput
substantially higher than independent browser-based speed tests on the same
machine and connection.

Connection:
- 2.5 GbE Ethernet link
- ISP plan: 1 Gbps symmetric

Repeatable results:

Omarchy Network Speed Test:
- Download: ~1,032 Mbps
- Upload: ~1,298 Mbps

Ookla browser test:
- Download: 1,043 Mbps
- Upload: 1,077 Mbps
- Ping: 2 ms

Fast.com browser test:
- Download: ~1.0 Gbps
- Upload: ~1.0 Gbps
- Unloaded latency: 3 ms
- Loaded latency: 7 ms

The Omarchy download result is close to the browser tests, but the upload result
is consistently around 1.3 Gbps.

This is repeatable across multiple Omarchy runs and is not a one-off spike.

Relevant implementation details
===============================

1. The panel displays the last throughput sample, not an averaged result.

In:

shell/plugins/panels/speedtest/Panel.qml

each line from omarchy-network-speedtest directly replaces uploadMbps or
downloadMbps:

    if (phase === "down") downloadMbps = String(value)
    else if (phase === "up") uploadMbps = String(value)

There is no averaging, median, smoothing, or final steady-state calculation.
The last sample received before the phase ends becomes the displayed result.

This means a short burst can become the final reported speed.

2. The 5-second phase timer starts before measurements begin.

Panel.qml starts the helper process and immediately starts the 5-second timer:

    speedTestProc.running = true
    phaseTimer.restart()

However, omarchy-network-speedtest must first:

- fetch Fast.com / Netflix OCA endpoints
- spawn 8 traffic workers
- wait for the first sampling interval

This appears related to existing issue #12854, which documents that the helper
can take roughly 3-4.5 seconds to produce its first sample.

As a result, a nominal 5-second phase may contain only a small number of actual
throughput samples.

3. The helper assumes each sampling interval is exactly one second.

In:

bin/omarchy-network-speedtest

throughput is calculated from interface byte counters after:

    sleep 1

using:

    (after - before) * 8 / 1000000

The actual elapsed time between counter reads is never measured.

The calculation therefore assumes delta_t = exactly 1.000 seconds, even though
scheduler delay and shell/process overhead make the real interval longer.

The correct formula should use actual elapsed monotonic time:

    Mbps = ((after - before) * 8) / (elapsed_seconds * 1000000)

4. Upload throughput is measured from the NIC TX byte counter.

The helper reads:

    /sys/class/net/$iface/statistics/tx_bytes

This measures all transmitted interface bytes during the interval rather than
application-level payload successfully received by Fast.com.

That can include protocol overhead, retransmissions, and unrelated TX traffic
during the sampling window.

Why this may explain the observed result
========================================

On this connection:

- Ookla: ~1.08 Gbps upload
- Fast.com browser: ~1.0 Gbps upload
- Omarchy: ~1.30 Gbps upload

Because Omarchy uses short interface-level samples and displays the final sample
rather than a sustained average, it appears possible for a transient upload
burst to become the reported result.

Expected
========

The completed Omarchy speed test should report a sustained upload result that is
reasonably comparable to Fast.com / Ookla on the same connection, approximately
1.0-1.1 Gbps in this case.

Actual
======

Omarchy repeatedly reports approximately 1.3 Gbps upload.

Suggested improvements
======================

1. Start the measurement duration on the first valid sample rather than at
   process launch, as discussed in #12854.

2. Collect multiple steady-state samples and calculate a final result rather
   than displaying the last instantaneous sample.

3. Measure actual monotonic elapsed time between byte-counter reads instead of
   assuming exactly one second.

4. Consider measuring transferred application payload rather than total NIC TX
   bytes.

Related issue:
#12854 - Speed test panel reads 0 on both dials: 5s phase timer starts at
process launch, ahead of the helper's warm-up