StarLink as source for NTP

cmcdonald

@stephenw10 said in StarLink as source for NTP:

Nice! Looks like some tweaks to the data/parsing required too.

/usr/local/sbin/ntpq -pnw
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*192.168.100.1                    1 u   57   64  377    0.546   +0.120   7.203

refid is empty now

tinfoilmatt

You mean it's just not being parsed?

cmcdonald

@tinfoilmatt said in StarLink as source for NTP:

You mean it's just not being parsed?

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?

I'm not sure.

tinfoilmatt

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

No idea. Your comment piqued my curiosity only because this post seems to demonstrate that the StarLink NTP implementation does, in fact, reply with an REFID of ".XFAC."?

Can't read myself since the network I'm on at the moment has the domain www.ntp.org blocked ()—but the search engine description of whatever this page contains regarding REFID seems relevant:

https://www.ntp.org/documentation/ietf/ntp-refid-updates/

davehart

@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/

davehart

@tinfoilmatt said in StarLink as source for NTP:

Your comment piqued my curiosity only because this post seems to demonstrate that the StarLink NTP implementation does, in fact, reply with an REFID of ".XFAC."?

That's actually generated by the client ntpd to indicate the local address/interface changed for the source since the last response was received. It happens as all prior results for that peer are flushed.

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 ;)