Does the -g apply to sync the daemon to the local clock driver with this configuration, if external server takes longer time to become reachable?

ntpd.config.param=restrict default noquery nomodify notrap;restrict 127.0.0.1;server 127.127.1.0 minpoll 3 maxpoll 3 iburst;tos orphanwait 8 minclock 6;server 192.168.1.14 iburst minpoll 6;
ntpd.init.param=-g -f /tffs0/ntpd_driftfile

If for example the local system clock is defaulted to Jan 01, 2000; then when system is started, the daemon will synch up with the local clock driver first as it will likely take longer time for the external server to become
reachable. Thus, when the external server is reachable, and daemon detects a large offset, the daemon will exit (since the -g applies only once).

How can we make the -g option apply only when external server becomes reachable and not when it synch's to the local clock?

If we keep the orphanwait time to default of 300 seconds, the daemon will not have this issue as it should not take that long to reach the external server and synch up with it under normal conditions. But this 5 minutes delay will make the daemon (server part) not ready to serve clients for at least 5 minutes, which is problematic in our case.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

To: questions@lists.ntp.org

First...

- why do you have 'tos orphanwait 8' in your config file? orphan mode
is not configured there.

- why are you configuring a local refclock in the first place?

Thanks...

On 3/27/2025 3:30 PM, rcheaito (via questions Mailing List) wrote:

Does the -g apply to sync the daemon to the local clock driver with this configuration, if external server takes longer time to become reachable?

ntpd.config.param=restrict default noquery nomodify notrap;restrict 127.0.0.1;server 127.127.1.0 minpoll 3 maxpoll 3 iburst;tos orphanwait 8 minclock 6;server 192.168.1.14 iburst minpoll 6;
ntpd.init.param=-g -f /tffs0/ntpd_driftfile

If for example the local system clock is defaulted to Jan 01, 2000; then when system is started, the daemon will synch up with the local clock driver first as it will likely take longer time for the external server to become reachable. Thus, when the external server is reachable, and daemon detects a large offset, the daemon will exit (since the -g applies only once).

How can we make the -g option apply only when external server becomes reachable and not when it synch's to the local clock?

If we keep the orphanwait time to default of 300 seconds, the daemon will not have this issue as it should not take that long to reach the external server and synch up with it under normal conditions. But this 5 minutes delay will make the daemon (server part) not ready to serve clients for at least 5 minutes, which is problematic in our case.

--
Harlan Stenn <stenn@nwtime.org>
https://www.nwtime.org/ - be a member!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Using the orphanwait to reduce the time it takes ntpd to synch up with the local system clock, as in this configuration, we need to have the server part of ntpd to be ready as soon as possible to serve some other devices
(regardless of whether the time is valid or not, or has synch'ed or not with the external server). If we keep the default orphanwait (300 seconds), the daemon won't be able to serve the other devices while trying to synch with the external server and may take up to 5 minutes before it can start serving them if the external server was not reachable/could synch with earlier.

Configuring a local refclock as we want ntpd to be a server for other devices, and so we want this server to become available asap and sync with a time
source quickly.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

rcheaito via questions Mailing List wrote:

Using the orphanwait to reduce the time it takes ntpd to synch up with the local system clock, as in this configuration, we need to have the server part of ntpd to be ready as soon as possible to serve some other devices (regardless of whether the time is valid or not, or has synch'ed or not with the external server). If we keep the default orphanwait (300 seconds), the daemon won't be able to serve the other devices while trying to synch with the
external server and may take up to 5 minutes before it can start serving them if the external server was not reachable/could synch with earlier.

Configuring a local refclock as we want ntpd to be a server for other devices,
and so we want this server to become available asap and sync with a time source quickly.

All that sounds reasonable, IFF you don't know anything about how NTPD
actually works!

What you need is iburst, possibly along with burst and minpoll 4,
against a network-locally ntpd server.

You really, really, really does not want your NTP server to provide
bodus time to any client, at any point in time! It is far better to not
reply than to be a falseticker for several minutes.

If you cannot guarantee WAN network connectivity, then I strongly
encourage you to setup a local GPS reference for your server. I don't
know what the current best/cheapest option is but more than 10 years ago
you could buy a Sure reference board for ~$80, solder a single line to
route the PPS signal to the RS232 Carrier Detect pin, and you would have
a clock that was accurate to maybe 25 ns RMS.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 28/03/2025 11:48, rcheaito via questions Mailing List wrote:

Configuring a local refclock as we want ntpd to be a server for other devices,
and so we want this server to become available asap and sync with a time source quickly.

It will take a variable time for the clients to step to the right time,
so you are still going to end up in an extended period in which machines
are on different times.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-03-28, Terje Mathisen <terje.mathisen@tmsw.no> wrote:

rcheaito via questions Mailing List wrote:

Using the orphanwait to reduce the time it takes ntpd to synch up with the >> local system clock, as in this configuration, we need to have the server part
of ntpd to be ready as soon as possible to serve some other devices
(regardless of whether the time is valid or not, or has synch'ed or not with >> the external server). If we keep the default orphanwait (300 seconds), the >> daemon won't be able to serve the other devices while trying to synch with the
external server and may take up to 5 minutes before it can start serving them
if the external server was not reachable/could synch with earlier.

Configuring a local refclock as we want ntpd to be a server for other devices,
and so we want this server to become available asap and sync with a time
source quickly.

All that sounds reasonable, IFF you don't know anything about how NTPD actually works!

What you need is iburst, possibly along with burst and minpoll 4,
against a network-locally ntpd server.

You really, really, really does not want your NTP server to provide
bodus time to any client, at any point in time! It is far better to not
reply than to be a falseticker for several minutes.

If you cannot guarantee WAN network connectivity, then I strongly
encourage you to setup a local GPS reference for your server. I don't
know what the current best/cheapest option is but more than 10 years ago
you could buy a Sure reference board for ~$80, solder a single line to
route the PPS signal to the RS232 Carrier Detect pin, and you would have
a clock that was accurate to maybe 25 ns RMS.

I think the biggest problem is that most computers no longer have a
serial or parallel input port and
I don't think usb has the needed interrupt accuracy.
The price of gps receivers is less than $50, but am not sure of their
timing capability

Terje

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

William Unruh <unruh@invalid.ca> wrote:

On 2025-03-28, Terje Mathisen <terje.mathisen@tmsw.no> wrote:

rcheaito via questions Mailing List wrote:

Using the orphanwait to reduce the time it takes ntpd to synch up with the >>> local system clock, as in this configuration, we need to have the server part
of ntpd to be ready as soon as possible to serve some other devices
(regardless of whether the time is valid or not, or has synch'ed or not with
the external server). If we keep the default orphanwait (300 seconds), the >>> daemon won't be able to serve the other devices while trying to synch with the
external server and may take up to 5 minutes before it can start serving them
if the external server was not reachable/could synch with earlier.

Configuring a local refclock as we want ntpd to be a server for other devices,
and so we want this server to become available asap and sync with a time >>> source quickly.

All that sounds reasonable, IFF you don't know anything about how NTPD
actually works!

What you need is iburst, possibly along with burst and minpoll 4,
against a network-locally ntpd server.

You really, really, really does not want your NTP server to provide
bodus time to any client, at any point in time! It is far better to not
reply than to be a falseticker for several minutes.

If you cannot guarantee WAN network connectivity, then I strongly
encourage you to setup a local GPS reference for your server. I don't
know what the current best/cheapest option is but more than 10 years ago
you could buy a Sure reference board for ~$80, solder a single line to
route the PPS signal to the RS232 Carrier Detect pin, and you would have
a clock that was accurate to maybe 25 ns RMS.

I think the biggest problem is that most computers no longer have a
serial or parallel input port and
I don't think usb has the needed interrupt accuracy.
The price of gps receivers is less than $50, but am not sure of their
timing capability

Terje

These days you can get a ntp server appliance for around $70 to $80.

These things have a GNSS receiver, an active antenna, power supply and a 10/100Mbps wired ethernet port.

Their intrinsic accuracy is on the order of about 100 nanoseconds and
can handle many hundreds of clients, so three of these things can easily provide ntp time for a huge local network.

They are available from amazon, ebay, walmart and all the Chinese on
line sellers such as Alibaba.

Do a search for FC-NTP-Mini Network Time Server.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: questions@lists.ntp.org

On Fri, Mar 28, 2025 at 04:37:09PM -0500, Steven Sommars wrote:

Caution advised. When I monitored a FC-NTP-Mini 1.5 years ago the
timestamp resolution was only 1 msec.
Additionally once in 2000 NTP responses the time stamp was in error by 1 second (top of the second problem).

Things may have improved since then.

I have been running a pair of them for 995 days, do extensive graphing
of all the ntp servers here, and have noticed nothing strange.

remote refid st t when poll reach delay offset jitter ============================================================================== *127.127.28.0 .SHM. 0 l 5 16 377 0.000 +3.562 2.434 -192.168.0.21 .PPS. 1 u 19 64 377 1.326 -2.751 1.908 +192.168.0.100 .PPS. 1 u 48 64 377 0.077 -3.755 0.878 +192.168.0.101 .PPS. 1 u 56 64 377 1.150 -3.295 1.724 -192.168.0.185 .PPS. 1 u 2 64 377 1.120 -1.329 0.890


The SHM server is a ublox USB GNSS.

The .21 server is a Raspberry Pi with a late model GNSS HAT.

The .100 and .101 servers are FC-NTP-Minis.

The .185 server is a precision steared, temperature controlled
oscillator box with a GNSS receiver and a specified PPS accurace of +/-
1 nanosecond.


--
Jim Pennino

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 29/03/2025 14:47, Jim Pennino wrote:

C:\Users\win-8>ntpq -pn oslo
remote refid st t when poll reach delay offset jitter
==============================================================================
127.127.20.1 .NMEA. 0 l - 16 0 0.000 +0.000 0.000
o127.127.22.1 .uPPS. 0 l 14 16 377 0.000 +0.033 0.002
*192.168.0.20 .GPS. 1 u 21 32 377 0.462 -0.106 0.028
+192.168.0.3 .PPS. 1 u 6 32 377 0.463 -0.142 0.030
+192.168.0.71 .PPS. 1 u 9 32 377 0.693 -0.139 0.029

I note that you are not processing NMEA data at all. You might want to
fix that.

I hope the new values you post will help others to determine the performance of the FC-NTP-Minis.

You are correct about the NMEA. In the configuration I used above there is only
the PPS line in use from the GPS. The other servers provide the date information, and are marked as "prefer" in the NTP configuration.

Cheers,
David
--
SatSignal Software - Quality software for you
Web: https://www.satsignal.eu
Email: davidtaylor@writeme.com
BlueSky: @gm8arv.bsky.social, Twitter: @gm8arv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 28/03/2025 21:54, Jim Pennino wrote:

On Fri, Mar 28, 2025 at 04:37:09PM -0500, Steven Sommars wrote:

Caution advised. When I monitored a FC-NTP-Mini 1.5 years ago the
timestamp resolution was only 1 msec.
Additionally once in 2000 NTP responses the time stamp was in error by 1
second (top of the second problem).

Things may have improved since then.

I have been running a pair of them for 995 days, do extensive graphing
of all the ntp servers here, and have noticed nothing strange.

remote refid st t when poll reach delay offset jitter
==============================================================================
*127.127.28.0 .SHM. 0 l 5 16 377 0.000 +3.562 2.434
-192.168.0.21 .PPS. 1 u 19 64 377 1.326 -2.751 1.908
+192.168.0.100 .PPS. 1 u 48 64 377 0.077 -3.755 0.878
+192.168.0.101 .PPS. 1 u 56 64 377 1.150 -3.295 1.724
-192.168.0.185 .PPS. 1 u 2 64 377 1.120 -1.329 0.890

The SHM server is a ublox USB GNSS.

The .21 server is a Raspberry Pi with a late model GNSS HAT.

The .100 and .101 servers are FC-NTP-Minis.

The .185 server is a precision steared, temperature controlled
oscillator box with a GNSS receiver and a specified PPS accurace of +/-
1 nanosecond.

Jim,

May I suggest making comparisons on a device with (working) PPS synchronisation.
This should make the jitter and offset values more consistent.

As an example, here I'm looking at a Win-11 PC (Oslo) with PPS sync for its NTP,
viewing its remote servers:

C:\Users\win-8>ntpq -pn oslo
remote refid st t when poll reach delay offset jitter ==============================================================================
127.127.20.1 .NMEA. 0 l - 16 0 0.000 +0.000 0.000 o127.127.22.1 .uPPS. 0 l 14 16 377 0.000 +0.033 0.002 *192.168.0.20 .GPS. 1 u 21 32 377 0.462 -0.106 0.028 +192.168.0.3 .PPS. 1 u 6 32 377 0.463 -0.142 0.030 +192.168.0.71 .PPS. 1 u 9 32 377 0.693 -0.139 0.029

.20 - LeoNTP (old version)
.3 - Linux box (x86) with PPS feed
.71 - Raspberry Pi with PPS feed

The delays are higher than I would wish, but likely due to multiple switches in the paths and some parts be just 100 Mbps links

Cheers,
David

--
SatSignal Software - Quality software for you
Web: https://www.satsignal.eu
Email: davidtaylor@writeme.com
BlueSky: @gm8arv.bsky.social, Twitter: @gm8arv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

David Taylor via questions Mailing List <questions@lists.ntp.org> wrote:

On 28/03/2025 21:54, Jim Pennino wrote:

On Fri, Mar 28, 2025 at 04:37:09PM -0500, Steven Sommars wrote:

Caution advised. When I monitored a FC-NTP-Mini 1.5 years ago the
timestamp resolution was only 1 msec.
Additionally once in 2000 NTP responses the time stamp was in error by 1 >>> second (top of the second problem).

Things may have improved since then.

I have been running a pair of them for 995 days, do extensive graphing
of all the ntp servers here, and have noticed nothing strange.

remote refid st t when poll reach delay offset jitter
==============================================================================
*127.127.28.0 .SHM. 0 l 5 16 377 0.000 +3.562 2.434
-192.168.0.21 .PPS. 1 u 19 64 377 1.326 -2.751 1.908
+192.168.0.100 .PPS. 1 u 48 64 377 0.077 -3.755 0.878
+192.168.0.101 .PPS. 1 u 56 64 377 1.150 -3.295 1.724
-192.168.0.185 .PPS. 1 u 2 64 377 1.120 -1.329 0.890


The SHM server is a ublox USB GNSS.

The .21 server is a Raspberry Pi with a late model GNSS HAT.

The .100 and .101 servers are FC-NTP-Minis.

The .185 server is a precision steared, temperature controlled
oscillator box with a GNSS receiver and a specified PPS accurace of +/-
1 nanosecond.

Jim,

May I suggest making comparisons on a device with (working) PPS synchronisation.
This should make the jitter and offset values more consistent.

remote refid st t when poll reach delay offset jitter =============================================================================== *NMEA(0) .GPS. 0 l 2 16 377 0.0000 -5.0594 0.9532 oPPS(0) .PPS. 0 l 1 16 377 0.0000 0.0010 0.0007 +192.168.0.100 .PPS. 1 u 20 64 377 0.1318 -2.5307 0.0226 +192.168.0.101 .PPS. 1 u 25 64 377 0.1462 -2.5510 0.0241

OK, there you go.

As an example, here I'm looking at a Win-11 PC (Oslo) with PPS sync for its NTP,
viewing its remote servers:

C:\Users\win-8>ntpq -pn oslo
remote refid st t when poll reach delay offset jitter
==============================================================================
127.127.20.1 .NMEA. 0 l - 16 0 0.000 +0.000 0.000
o127.127.22.1 .uPPS. 0 l 14 16 377 0.000 +0.033 0.002
*192.168.0.20 .GPS. 1 u 21 32 377 0.462 -0.106 0.028
+192.168.0.3 .PPS. 1 u 6 32 377 0.463 -0.142 0.030
+192.168.0.71 .PPS. 1 u 9 32 377 0.693 -0.139 0.029

I note that you are not processing NMEA data at all. You might want to
fix that.

.20 - LeoNTP (old version)
.3 - Linux box (x86) with PPS feed
.71 - Raspberry Pi with PPS feed

The delays are higher than I would wish, but likely due to multiple switches in
the paths and some parts be just 100 Mbps links

Cheers,
David

--
SatSignal Software - Quality software for you
Web: https://www.satsignal.eu
Email: davidtaylor@writeme.com
BlueSky: @gm8arv.bsky.social, Twitter: @gm8arv

--
penninojim@yahoo.com

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

David Taylor via questions Mailing List <questions@lists.ntp.org> wrote:

On 29/03/2025 14:47, Jim Pennino wrote:

C:\Users\win-8>ntpq -pn oslo
remote refid st t when poll reach delay offset jitter
==============================================================================
127.127.20.1 .NMEA. 0 l - 16 0 0.000 +0.000 0.000
o127.127.22.1 .uPPS. 0 l 14 16 377 0.000 +0.033 0.002
*192.168.0.20 .GPS. 1 u 21 32 377 0.462 -0.106 0.028
+192.168.0.3 .PPS. 1 u 6 32 377 0.463 -0.142 0.030
+192.168.0.71 .PPS. 1 u 9 32 377 0.693 -0.139 0.029

I note that you are not processing NMEA data at all. You might want to
fix that.

I hope the new values you post will help others to determine the performance of
the FC-NTP-Minis.

You are correct about the NMEA. In the configuration I used above there is only
the PPS line in use from the GPS. The other servers provide the date information, and are marked as "prefer" in the NTP configuration.

Cheers,
David
--
SatSignal Software - Quality software for you
Web: https://www.satsignal.eu
Email: davidtaylor@writeme.com
BlueSky: @gm8arv.bsky.social, Twitter: @gm8arv

So why bother to have a configuration line for something that doesn't
exist?

You could of course attach a USB device to provide NMEA data.

New values for what?

--
penninojim@yahoo.com

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 30/03/2025 15:27, Jim Pennino wrote:

So why bother to have a configuration line for something that doesn't
exist?

You could of course attach a USB device to provide NMEA data.

New values for what?

Jim,

It was probably history just copying from a previous configuration. I might add
NMEA later but it's not needed in my configuration.

New values for the comparison of the FC-NTP-Minis you presented.

Cheers,
David
--
SatSignal Software - Quality software for you
Web: https://www.satsignal.eu
Email: davidtaylor@writeme.com
BlueSky: @gm8arv.bsky.social, Twitter: @gm8arv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

David Taylor via questions Mailing List <questions@lists.ntp.org> wrote:

On 30/03/2025 15:27, Jim Pennino wrote:

So why bother to have a configuration line for something that doesn't
exist?

You could of course attach a USB device to provide NMEA data.

New values for what?

Jim,

It was probably history just copying from a previous configuration. I might add
NMEA later but it's not needed in my configuration.

New values for the comparison of the FC-NTP-Minis you presented.

Cheers,
David
--
SatSignal Software - Quality software for you
Web: https://www.satsignal.eu
Email: davidtaylor@writeme.com
BlueSky: @gm8arv.bsky.social, Twitter: @gm8arv

I'm assuming you are interested in how well the FC-NTP-Mini performs.

Here's the ntpq output for the server with a serial attached GNSS GPSDO
which uses the FC-NTP-Minis so ntpd has 4 sources.

remote refid st t when poll reach delay offset jitter =============================================================================== *NMEA(0) .GPS. 0 l 6 16 377 0.0000 -1.0293 0.4732 oPPS(0) .PPS. 0 l 5 16 377 0.0000 0.0022 0.0012 +192.168.0.100 .PPS. 1 u 59 64 377 0.1387 -2.5460 0.0305 +192.168.0.101 .PPS. 1 u 24 64 377 0.1454 -2.5504 0.0058

The FC-NTP-Minis are connected through 100M wired ethernet. The machine
shown previously connects through WIFI which makes the server delays and jitters look quite a bit worse.

IMHO ntpq tells very little about how well ntpd is performing so I use
ntpviz from the ntpsec distribution. ntpviz is a python script that
requires trivial tweaks to run with either flavor of ntpd.

What it produces is about 2 dozen files of graphs and analysis of
jitters, delays, offsets, etc. as a web page.

I could produce a gzip directory containing a day's worth of data where you just point a browser to the contained index.html file. Zipped the file
is about 2 MB.

The only issue is that I have nowhere public to put it so if you want
such, send me a private email.


--
penninojim@yahoo.com

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thanks Gents for your replies. I will try the orphan mode as suggested.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)