---
title: "Starlink stratum 1 NTP over WiFi — results and limits — PToB Blog"
description: "Investigating Starlink’s local GPS-based NTP server, WiFi beacon timing, calibrated results, wired expectations and how SpaceX could improve the access point clock."
url: "https://ptob.dev/blog/starlink-local-stratum-1-ntp/"
language: "en"
robots: "index, follow, max-image-preview:large, max-snippet:-1, max-video-preview:-1"
representations: {"application/json":"https://ptob.dev/blog/starlink-local-stratum-1-ntp/?format=json","text/markdown":"https://ptob.dev/blog/starlink-local-stratum-1-ntp/?format=markdown"}
format_description: "https://ptob.dev/agent-formats.json"
---

# Your Starlink as a local stratum 1 time server

An existing dish offers a local time source. We investigate what ordinary WiFi can deliver, what beacon timing adds, and where a cable or a better-disciplined access point could take it.

[Jonathan Yantis](https://github.com/yantisj2/PToB/blob/main/CREDITS.md) 3 November 2026  7 min read

![Painted concept scene with a SpaceX-branded satellite above Earth, a rooftop terminal and a workshop clock reading 20 µs beside a WiFi router.](https://ptob.dev/blog/starlink-stratum-1-investigation-v2.png)

Concept artwork for our Starlink timing investigation. The 20 µs clock reading is illustrative, not a measured result or guarantee. The NTP service is local to the terminal.

In this post

If you already have Starlink, you may already have the most expensive part of a local time source installed outdoors. [Starlink documents a GPS-based NTP server at ` 192.168.100.1 `](https://ptob.dev/blog/starlink-local-stratum-1-ntp/#source-starlink-ntp). A local client can ask the terminal for time without sending that NTP query to an internet time server over the satellite link. The service is best effort, with no accuracy guarantee.

That is an appealing starting point for a workshop, home lab or remote installation. We wanted to know how far inexpensive client hardware could take it: first with ordinary NTP, then with the fine clock information already present in WiFi beacons. The results make a useful local source worth investigating, while showing why a stratum number and a smooth timing display are only the beginning.

## Start with the time server you already own

Our first capture accepted **37 NTP replies, all reporting stratum 1**. Their round-trip delays ranged from **3.289 to 26.439 ms**. Stratum 1 identifies a primary server in the [NTP hierarchy](https://ptob.dev/blog/starlink-local-stratum-1-ntp/#source-ntp-standard); it does not certify a particular error at your computer. A host synchronizing to that server normally becomes stratum 2. If it serves other machines, those clients add another level.

For an existing chrony installation, the basic source entry is:

```
server 192.168.100.1 iburst
```

This is a source entry to add to an appropriate existing configuration, not a complete server setup. Check that the terminal is reachable from your LAN, record its reported state and compare it with other references. ` iburst ` speeds initial acquisition; it does not provide the custom beacon estimator used below. There is no reason to force a stratum number or turn on chrony’s unrelated ` local stratum ` option.

Keeping other suitable time sources gives you a cross-check when the terminal changes state. We have not qualified this installation through loss of GNSS, WAN outages or every router mode, and have not established its authentication capabilities. A local address alone does not establish trustworthy time.

## The second clock hiding in WiFi beacons

An access point regularly broadcasts a beacon containing its **Timing Synchronization Function**, or TSF, counter. That gives a compatible receiver an observation of the AP’s local clock. It does not, by itself, say which UTC second that clock represents.

We used an **ESP32-S3 W12** with driver receive-event timestamps and power saving disabled. A model built from earlier beacon/receive pairs predicted each new observation before adding it to the fit. This avoids treating a late software callback as the radio event.

In the roughly ten-minute [beacon experiment](https://ptob.dev/blog/starlink-local-stratum-1-ntp/#source-beacon-study), **5,858 logged observations** gave **0.409 µs relative prediction RMS**, **0.969 µs absolute P99** and a **1.346 µs maximum**. All 40 residuals above one microsecond remain. A separate fit using software callback time had **5.427 µs RMS**: the timestamp path matters.

Those are local predictive residuals, not UTC accuracy. The capture also missed one raw record among 5,859 accepted sample numbers, so its strict no-gap gate failed. Independent replay reconstructed 5,602 predictions; 256 logged rows lacked complete prior history. Neither those gaps nor fixed delays disappear because the fit looks good.

The experiment showed that beacons carry useful fine clock information. It did **not** show that the AP was GPS-disciplined. The terminal’s NTP clock, the AP counter and the client’s counters are different observable clocks, and their physical relationships remain unresolved.

## What to expect over WiFi, with and without tuning

For an ordinary software NTP client on an uncharacterized WiFi link, our conservative **planning estimate is a sub-millisecond to few-millisecond budget**, allowing larger excursions under load. That is an engineering allowance, not a measured stock-client result or a Starlink specification. In the later runs, individual accepted NTP observations had about **3.9–4.6 ms residual scatter**. A disciplined client can average noisy observations, but averaging cannot identify a constant one-way delay bias.

Practical tuning starts with a steady client, a clean radio path, sensible polling and a mature clock discipline. Compare quiet and busy periods, investigate power saving and avoid changing several settings at once. Shorter polls can track drift sooner, while longer averaging suppresses noise; the right balance depends on the clock and link. Our custom path additionally needs receive-event timestamp access that ordinary phone and laptop apps may not expose.

Our [paired follow-up](https://ptob.dev/blog/starlink-local-stratum-1-ntp/#source-paired-study) used 900 seconds of training followed by 900 seconds of evaluation in each of two runs. The NTP-only control was already tuned: an AP-free, 900-second weighted least-squares local-clock estimate, called WLS900. The hybrid combined NTP with AP clock information and a robust filter. These were **not default chrony versus tuned chrony tests**.

Each method first received its own fixed, GNSS-measured phase correction. With that prior correction, the same 900 future PPS witnesses per run gave:

| Run / method | RMS (µs) | Abs. P99 (µs) |
| --- | --- | --- |
| R1 · NTP only | 37.180 | 67.329 |
| R1 · NTP + beacons | 19.226 | 43.079 |
| R2 · NTP only | 35.662 | 54.767 |
| R2 · NTP + beacons | 8.240 | 20.069 |

The hybrid improved RMS in both runs. In the first, that gain came from lower bias while centered scatter slightly worsened; the second improved both. Ordinary AP fits and servos had mixed results. Two windows on one boot are encouraging observations, not a general performance distribution.

The calibration qualification changes what an owner should expect. **Without the prior GNSS phase correction**, NTP-only raw phase RMS was **224.160/226.778 µs**, and hybrid raw phase RMS was **217.046/218.521 µs**. These raw values are observations of this setup, not a portable UTC bound either. Reproducing the tens-of-microseconds corrected results requires measuring the client/path/model phase base; it cannot simply be copied to another installation.

GNSS supplied that phase base and the validation witness, never frequency training. No future recentering or detrending improves the scores. Complete 900/900 scoring does not establish continuous service availability. The continuously updated models retain a 60-second source lease; a good frozen-clock forecast does not extend it. Earlier failed and incomplete experiments remain in the paper.

## What a cable could change

Ethernet should remove WiFi contention, retries and radio power-save effects from the client path. It can also support better packet timestamping. It cannot remove a biased server timestamp, a terminal clock error or asymmetric delay elsewhere in the path.

**Our wired estimate, still untested on this Starlink installation:** a quiet wired software client could plausibly make **tens of microseconds of relative clock agreement** a useful first target, with roughly **10–100 µs as an initial engineering target band**, rather than a predicted RMS or P99. Improvement could be small if the terminal’s timestamping or clock dominates. We would not promise a corresponding absolute UTC result, or a fixed improvement factor over WiFi.

There is precedent for substantially better Ethernet time transfer when the server, client and timestamp path are designed for it. [Chrony’s independently measured wired examples](https://ptob.dev/blog/starlink-local-stratum-1-ntp/#source-chrony-accuracy) show about 2 µs stability with a roughly 5 µs bias in one software-client setup, and much finer transfer with hardware timestamps at both ends. Those are different systems. A capable client NIC alone does not give a Starlink terminal a calibrated hardware-timestamped NTP service.

The useful next test is the same terminal with WiFi and Ethernet clients, fixed calibration, matched quiet/load windows and an independent PPS reference. Retain RMS, P99, maximum, gaps and recovery. Then we can replace the target band with a result.

## How SpaceX could make the AP a better clock

The opportunity is to connect two things already present in the installation: a GPS-based terminal time source and frequent AP beacon events. We have not established how SpaceX currently relates those clocks. The following is a proposed design, subject to the hardware exposing suitable timing signals.

First, carry the terminal’s reference into the router with a measured clock bridge: hardware-timestamped exchange, a PPS connection where available, or another calibrated cross-timestamp path. Reading a software clock occasionally would leave unknown delay in that transfer.

Second, gently discipline the AP oscillator or maintain a continuously tracked mapping from its TSF counter to reference time. Preserve WiFi synchronization semantics rather than arbitrarily stepping TSF to a UTC epoch. Correcting a constant frequency difference is not enough; the system must track wander and recognize resets.

Third, expose that mapping to capable clients, tied to the **actual MAC transmit event**. It needs a reference epoch, offset/rate relationship, uncertainty, age and a clear reference-loss/holdover state. NTP can remain the broadly compatible entry point while fine-event metadata serves clients that can capture it. The terminal’s NTP receive/transmit timestamp path deserves the same calibration attention.

That could let frequent beacons carry the pace of a referenced clock while a slower exchange establishes its time coordinate. Our **0.409 µs relative beacon residual makes microsecond-class transfer a worthwhile research target** for such a design; it does not supply the missing UTC calibration, client independence or physical-output measurement.

For an owner today, the inexpensive first step is to evaluate the NTP service already in the dish. For us, the next step is to measure what survives the complete terminal-to-AP-to-client chain. A disciplined AP could make that chain much more useful without putting a separate GNSS antenna beside every indoor device.

Every timestamp needs a reference.
**Which event did you capture?**

## Explore the details

[Starlink timing research and paired results The approved seven-page draft, equipment requirements, RMS, P99 and calibration limits.](https://ptob.dev/research/starlink-wifi-timing/)[A Raspberry Pi time gateway Connecting mesh time to Linux, NTP and proposed wired PTP paths.](https://ptob.dev/blog/raspberry-pi-ptp-ntp-ble/)[The timing research library Separate measurement populations, methods, uncertainty and public sources.](https://ptob.dev/research/)

## Sources and further reading

Primary references for the hardware and methods discussed.

1. [Starlink · Does Starlink provide time synchronization or NTP servers?](https://starlink.com/ke/support/article/0873e885-831a-9f4e-4808-2838a28f2e69)

   GPS-based NTP at 192.168.100.1, provided on a best-effort basis without an accuracy guarantee.
2. [PToB · Paired Clock Time Transfer from Starlink over Wi-Fi](https://github.com/yantisj2/PToB/tree/main/papers/starlink-wifi-hybrid-timing)

   The approved 3 November draft, two locked validation runs, selected predictions and reproducible statistics.
3. [PToB · Starlink Wi-Fi timing feasibility](https://github.com/yantisj2/PToB/tree/main/papers/starlink-wifi-timing)

   The earlier author-review study and aggregate beacon evidence, including its failed no-gap capture gate.
4. [IETF · NTPv4 protocol and algorithms, RFC 5905](https://www.rfc-editor.org/rfc/rfc5905.html)

   Primary and secondary server strata, packet timestamps and the offset/delay model.
5. [chrony · Configuration manual](https://chrony-project.org/doc/4.8/chrony.conf.html)

   Client server configuration, filtering, polling and hardware timestamping; no Starlink-specific qualification.
6. [chrony · Configuration examples and accuracy](https://chrony-project.org/examples.html)

   Independently measured wired examples, with distinct software/hardware timestamp paths and retained asymmetry.
7. [chrony · How accurate is my system clock?](https://chrony-project.org/faq.html#_how_accurate_is_my_system_clock)

   Why stable offsets and an internal estimator cannot independently establish clock accuracy.
8. [Espressif · Pinned ESP-IDF WiFi receive timestamp definition](https://github.com/espressif/esp-idf/blob/b774170ff46c393eeb5e495ea37936038d3f4f4f/components/esp_wifi/include/local/esp_wifi_types_native.h)

   Microsecond receive timestamps and the modem/light-sleep conditions used by the beacon experiment.

## Cite this article

Jonathan Yantis. Your Starlink as a local stratum 1 time server PToB Blog. Published 3 November 2026.

Article permalink: [https://ptob.dev/blog/starlink-local-stratum-1-ntp/](https://ptob.dev/blog/starlink-local-stratum-1-ntp/)

[Back to the blog](https://ptob.dev/blog/)[Inspect the project evidence](https://github.com/yantisj2/PToB/blob/main/evidence/README.md)

## Structured data

```json
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "WebSite",
      "@id": "https://ptob.dev/#website",
      "url": "https://ptob.dev/",
      "name": "PToB",
      "alternateName": [
        "Precision Time over BLE",
        "Precision Time over Bluetooth"
      ],
      "description": "Bluetooth and USB software clocks: W12 60.3 ns relative-PPS RMS over 522/600 observations, separate 64 s sampled holdover, and CoreSE diagnostics.",
      "inLanguage": [
        "en",
        "de"
      ],
      "publisher": {
        "@id": "https://ptob.dev/#jonathan-yantis"
      }
    },
    {
      "@type": "Person",
      "@id": "https://ptob.dev/#jonathan-yantis",
      "name": "Jonathan Yantis",
      "url": "https://github.com/yantisj2/PToB/blob/main/CREDITS.md"
    },
    {
      "@type": "Project",
      "@id": "https://ptob.dev/#project",
      "name": "PToB",
      "alternateName": "Precision Time over BLE",
      "url": "https://ptob.dev/",
      "description": "An independent protocol project researching precision time transfer across Bluetooth-enabled microcontrollers and USB clients.",
      "sameAs": "https://github.com/yantisj2/PToB",
      "member": {
        "@id": "https://ptob.dev/#jonathan-yantis"
      },
      "knowsAbout": {
        "@id": "https://ptob.dev/#protocol"
      }
    },
    {
      "@type": "Thing",
      "@id": "https://ptob.dev/#protocol",
      "name": "Precision Time over BLE",
      "alternateName": "PToB",
      "description": "An experimental PTP-inspired protocol proposal for wireless clock synchronization over Bluetooth Low Energy."
    },
    {
      "@type": "WebPage",
      "@id": "https://ptob.dev/blog/starlink-local-stratum-1-ntp/#webpage",
      "url": "https://ptob.dev/blog/starlink-local-stratum-1-ntp/",
      "name": "Starlink stratum 1 NTP over WiFi — results and limits — PToB Blog",
      "description": "Investigating Starlink’s local GPS-based NTP server, WiFi beacon timing, calibrated results, wired expectations and how SpaceX could improve the access point clock.",
      "inLanguage": "en",
      "keywords": [
        "Starlink",
        "stratum 1 NTP",
        "WiFi timing",
        "TSF beacons",
        "ESP32-S3"
      ],
      "isPartOf": {
        "@id": "https://ptob.dev/#website"
      },
      "author": {
        "@id": "https://ptob.dev/#jonathan-yantis"
      },
      "about": {
        "@id": "https://ptob.dev/#protocol"
      },
      "dateModified": "2026-11-03T00:00:00.000Z",
      "image": "https://ptob.dev/blog/starlink-stratum-1-investigation-v2.png",
      "breadcrumb": {
        "@id": "https://ptob.dev/blog/starlink-local-stratum-1-ntp/#breadcrumbs"
      },
      "mainEntity": {
        "@id": "https://ptob.dev/blog/starlink-local-stratum-1-ntp/#article"
      }
    },
    {
      "@type": "BreadcrumbList",
      "@id": "https://ptob.dev/blog/starlink-local-stratum-1-ntp/#breadcrumbs",
      "itemListElement": [
        {
          "@type": "ListItem",
          "position": 1,
          "name": "PToB",
          "item": "https://ptob.dev/"
        },
        {
          "@type": "ListItem",
          "position": 2,
          "name": "Blog",
          "item": "https://ptob.dev/blog/"
        },
        {
          "@type": "ListItem",
          "position": 3,
          "name": "Your Starlink as a local stratum 1 time server",
          "item": "https://ptob.dev/blog/starlink-local-stratum-1-ntp/"
        }
      ]
    },
    {
      "@type": "Blog",
      "@id": "https://ptob.dev/blog/#blog",
      "url": "https://ptob.dev/blog/",
      "name": "PToB Blog",
      "description": "Engineering notes on shared time, inexpensive hardware and the experiments behind PToB.",
      "inLanguage": "en",
      "publisher": {
        "@id": "https://ptob.dev/#jonathan-yantis"
      },
      "isPartOf": {
        "@id": "https://ptob.dev/#website"
      },
      "blogPost": [
        {
          "@id": "https://ptob.dev/blog/esp32-wireless-softpll/#article"
        },
        {
          "@id": "https://ptob.dev/blog/esp32-clock-fundamentals/#article"
        },
        {
          "@id": "https://ptob.dev/blog/firmware-stability-time-mesh/#article"
        },
        {
          "@id": "https://ptob.dev/blog/lab-sensor-timing-economics/#article"
        },
        {
          "@id": "https://ptob.dev/blog/starlink-local-stratum-1-ntp/#article"
        },
        {
          "@id": "https://ptob.dev/blog/raspberry-pi-ptp-ntp-ble/#article"
        },
        {
          "@id": "https://ptob.dev/blog/gnss-resilient-time-mesh/#article"
        },
        {
          "@id": "https://ptob.dev/blog/passive-lora-channel-hopping/#article"
        },
        {
          "@id": "https://ptob.dev/blog/esp32-sub-microsecond-holdover/#article"
        },
        {
          "@id": "https://ptob.dev/blog/local-time-utc-mesh/#article"
        },
        {
          "@id": "https://ptob.dev/blog/grandmaster-failover-multi-master-ensemble/#article"
        },
        {
          "@id": "https://ptob.dev/blog/ble-clocks-indoor-navigation/#article"
        },
        {
          "@id": "https://ptob.dev/blog/passive-ble-esp32/#article"
        },
        {
          "@id": "https://ptob.dev/blog/why-utc/#article"
        },
        {
          "@id": "https://ptob.dev/blog/why-ptob/#article"
        }
      ]
    },
    {
      "@type": "BlogPosting",
      "@id": "https://ptob.dev/blog/starlink-local-stratum-1-ntp/#article",
      "url": "https://ptob.dev/blog/starlink-local-stratum-1-ntp/",
      "headline": "Your Starlink as a local stratum 1 time server",
      "description": "Investigating Starlink’s local GPS-based NTP server, WiFi beacon timing, calibrated results, wired expectations and how SpaceX could improve the access point clock.",
      "mainEntityOfPage": {
        "@id": "https://ptob.dev/blog/starlink-local-stratum-1-ntp/#webpage"
      },
      "isPartOf": {
        "@id": "https://ptob.dev/blog/#blog"
      },
      "author": {
        "@id": "https://ptob.dev/#jonathan-yantis"
      },
      "publisher": {
        "@id": "https://ptob.dev/#jonathan-yantis"
      },
      "inLanguage": "en",
      "dateCreated": "2026-11-03T00:00:00.000Z",
      "dateModified": "2026-11-03T00:00:00.000Z",
      "datePublished": "2026-11-03T00:00:00.000Z",
      "image": "https://ptob.dev/blog/starlink-stratum-1-investigation-v2.png",
      "articleSection": "Starlink and local network time",
      "keywords": [
        "Starlink",
        "stratum 1 NTP",
        "WiFi timing",
        "TSF beacons",
        "ESP32-S3"
      ],
      "wordCount": 1511,
      "citation": [
        {
          "@type": "CreativeWork",
          "name": "Starlink · Does Starlink provide time synchronization or NTP servers?",
          "url": "https://starlink.com/ke/support/article/0873e885-831a-9f4e-4808-2838a28f2e69"
        },
        {
          "@type": "CreativeWork",
          "name": "PToB · Paired Clock Time Transfer from Starlink over Wi-Fi",
          "url": "https://github.com/yantisj2/PToB/tree/main/papers/starlink-wifi-hybrid-timing"
        },
        {
          "@type": "CreativeWork",
          "name": "PToB · Starlink Wi-Fi timing feasibility",
          "url": "https://github.com/yantisj2/PToB/tree/main/papers/starlink-wifi-timing"
        },
        {
          "@type": "CreativeWork",
          "name": "IETF · NTPv4 protocol and algorithms, RFC 5905",
          "url": "https://www.rfc-editor.org/rfc/rfc5905.html"
        },
        {
          "@type": "CreativeWork",
          "name": "chrony · Configuration manual",
          "url": "https://chrony-project.org/doc/4.8/chrony.conf.html"
        },
        {
          "@type": "CreativeWork",
          "name": "chrony · Configuration examples and accuracy",
          "url": "https://chrony-project.org/examples.html"
        },
        {
          "@type": "CreativeWork",
          "name": "chrony · How accurate is my system clock?",
          "url": "https://chrony-project.org/faq.html#_how_accurate_is_my_system_clock"
        },
        {
          "@type": "CreativeWork",
          "name": "Espressif · Pinned ESP-IDF WiFi receive timestamp definition",
          "url": "https://github.com/espressif/esp-idf/blob/b774170ff46c393eeb5e495ea37936038d3f4f4f/components/esp_wifi/include/local/esp_wifi_types_native.h"
        }
      ],
      "about": {
        "@id": "https://ptob.dev/#protocol"
      }
    }
  ]
}
```