StarLink as source for NTP

stephenw10

@davehart said in StarLink as source for NTP:

It seems reasonable to do that for refids with only unprintable/invisible characters.

You mean it could be expected to return .. if it doesn't have a printable ID value?

davehart

@stephenw10 said in StarLink as source for NTP:

@davehart said in StarLink as source for NTP:

It seems reasonable to do that for refids with only unprintable/invisible characters.

You mean it could be expected to return .. if it doesn't have a printable ID value?

Exactly. I'd like to be scolding that instead of screen-scraping the peers billboard the web UI should be using a parsing-friendly version (which ntpq calls raw), but in fact there's no raw form of the billboards. It can be done with multiple raw queries to get the list of associations and query the raw peer variables for each association, though, which is what the billboard code in ntpq is doing. Given that lots of folks have resorted to scraping it, making sure there's something in the refid field seems wise.

davehart

@davehart said in StarLink as source for NTP:

I can crank out a fixed x64 binary with that info and post it.

https://www.davehart.net/ntp/test/ntp-stable-dlh-260328.tar.gz is a private test release of mine which includes the bug 3877 fix for rejecting responses with a zero ppoll in the packet.

The issue with the empty refid is a display issue in ntpq. That has not yet been fixed. So this will allow the Starlink to be used as a NTP source, but the column-shifting may still appear.

davehart

@davehart said in StarLink as source for NTP:

@cmcdonald said in StarLink as source for NTP:

pfSense expects refid to not be empty, so it ends up shifting all other columns over.

Is there ever a legit condition where refid is indeed empty?

ntpd displays text refids bracketed by periods. It seems reasonable to do that for refids with only unprintable/invisible characters. Stratum 1 sources have text refids like .GPS.

Feel free to file a bug report at https://bugs.ntp.org/

It's actually ntpq which brackets text refids with periods. Refids are always 32 bits, either up to 4 characters or a dotted-quad a la IPv4. However, an empty refid is displayed as an empty string. To give screen-scrapers a better chance, ".." would be preferable.

I've filed https://bugs.ntp.org/4019 to track that change. For those interested, there are two lines in doprintpeers under the line:

	} else if (!strcmp("refid", name)) {

to update from:

				dstadr_refid = "";

to:

				dstadr_refid = "..";

Ramosel

@davehart Thanks for keep us current on this.

Rick

dennypage

For those of you interested, I've created a Chrony package for pfSense.

me21

This post is deleted!

me21

The NTPd behaviour seems to be caused by this bug and seems to be included in a future version:
https://bugs.ntp.org/show_bug.cgi?id=3870

Gertjan

I'm looking at this thread for a couple of months now.
I'm not a Starlink user myself, so I don't know much about them.

Not this morning.

StarLink as source for NTP

By definition, a starlink 'disk' points to the open sky.
So, it should be able / must 'see' many satellites ...
For me, that means is also sees GPS satellites.

Knowing that every two digit dollar hand hold device has a GPS receiver built in today, I asked myself : why doesn't the starlink disk include a sub one dollar GPS receiver chip ??
It would make the starlink disk a stratum 2 (1 ?) GSP device right out of the box - no more NTP traffic needed.
Afaik, these starlink satellites all have an atomic clock(or comparable) build in, needed for their exact positing and all that, so that would be a second totally free source of time.

Anyway, that's how I see the title "StarLink as source for NTP".
It could be "Starlink == real time" thus a very accurate time source.

edit : this thread is pretty long. Maybe this was already suggested.

Mission-Ghost

@Gertjan Starlink dishes do have gps receivers in them, and they do serve GPS time to the network.

The issue is the NTP client in pfsense doesn’t work properly to read that time. Chronyd does work but it’s an unsupported add-on at this point. I’m getting my network time from my Starlink dish gps receiver right now and it’s very accurate as expected.

dennypage

@Gertjan The StarLink receiver being a stratum 1 NTP time server is in the first post of the thread.

Ramosel

@Gertjan

The Starlink dish itself a Stratum 1 time source. But it's operating in "the new world of GPS time" and pfSense is yet to catch up. I'm sure they will. The gent from NTP posted the issue if you read enough of this thread.

Here is the output when using the local dish through the Galleon utility.

84169ab8-1feb-4b52-a4fc-f051ee34c9f4-Galleon10-03-2026.jpg

dennypage

@Ramosel said in StarLink as source for NTP:

operating in "the new world of GPS time"

I believe the ntpd issue has to do with nuances of newer versions of the NTP protocol rather than GPS.

FWIW, the Galleon test app looks to be pretty broken. A precision of 2.26156424291633E+74 is clearly wrong.

If you are running chrony, you can ask it directly what the advertised precision of a source is. Try chronyc ntpdata 192.168.100.1 and look for Precision. I would expect to see something in the range of -14 (61us) to -24 (61ns).

johnpoz

@dennypage mine is

Precision : -25 (0.000000030 seconds)

Well shoot clearly my clocks are going to be way out ;)

Mission-Ghost

@dennypage

Not that amazing here; from my Starlink I get, via chronyc ntpdata using the command page on pfSense:

Precision       : -9 (0.001953125 seconds)

Interesting. I wonder why it's so different that what you expect or what Johnpoz reported.

dennypage

@johnpoz said in StarLink as source for NTP:

Precision : -25 (0.000000030 seconds)

Interesting -- what is the source?

Some people (companies) use -25 and justify it because the GNSS chip they are using says <= 30ns. However, the precision statement should be about the entire system rather than just the GNSS. To really be -25, you really need to have <= 20ns on the GNSS chip itself, and a very deterministic microcode implementation or high resolution hardware timestamping on each step of the process.

I have a few real -24s and -25s, and one -26. I'd really like to have a -27, but am not sure I'll get there. I have a reference timing chip that is reliable <= 5ns, but don't have the hardware to put with it. Sad, sad, sad.

dennypage

@Mission-Ghost said in StarLink as source for NTP:

@dennypage
Not that amazing here; from my Starlink I get, via chronyc ntpdata using the command page on pfSense:
Precision       : -9 (0.001953125 seconds)
Interesting. I wonder why it's so different that what you expect or what Johnpoz reported.

To me that indicates unexpected honesty on the part of StarLink. Based on the number I'm guessing that they are using their carrier signal to communicate time rather than some form of embedded GNSS.

And to be honest, I expect 2ms is sufficient for 99% of home users.

chpalmer

@dennypage said in StarLink as source for NTP:

And to be honest, I expect 2ms is sufficient for 99% of home users.

LOL.. most home user oven clocks are >5 minutes off..

stephenw10

If they included ntp in the oven you wouldn't have these issues. Accuracy baked in.

Mission-Ghost

@dennypage the Starlink device knows where it is using GPS as the default locating technology, but there is a configuration item to use its own positioning system instead. I've always used the default GPS. It's NTP server reports it as stratum 1. Here's the rest of my pfSense's chronyc ntpdata from Starlink's (Gen 3 dish):

Remote address  : 192.168.100.1 (C0A86401)
Remote port     : 123
Local address   : 100.[redacted]
Leap status     : Normal
Version         : 4
Mode            : Server
Stratum         : 1
Poll interval   : 0 (1 seconds)
Precision       : -9 (0.001953125 seconds)
Root delay      : 0.000000 seconds
Root dispersion : 0.000000 seconds
Reference ID    : 00000000 ()
Reference time  : Sat Oct 03 22:35:19 2026
Offset          : -0.000059627 seconds
Peer delay      : 0.001953174 seconds
Peer dispersion : 0.001953174 seconds
Response time   : 0.000061035 seconds
Jitter asymmetry: -0.50
NTP tests       : 111 111 1111
Interleaved     : No
Authenticated   : No
TX timestamping : Daemon
RX timestamping : Kernel
Total TX        : 1735
Total RX        : 1735
Total valid RX  : 1735
Total good RX   : 1546
Total kernel TX : 0
Total kernel RX : 1735
Total HW TX     : 0
Total HW RX     : 0

Starlink used to furnish access to the GPS location data, but they shut that feature down for reasons.

I'm not a time wonk like johnpoz or Jeff Geerling, but accurate time is fascinating and the Starlink GPS clock is good enough for my network.