StarLink as source for NTP

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

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.