From Newsgroup: comp.protocols.time.ntp

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.

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

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!

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

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.

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

--000000000000bc6bbc063165f8c7
Content-Type: text/plain; charset="UTF-8"

On Thu, Mar 27, 2025, 17:30 rcheaito <questions@lists.ntp.org> 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

How can we make the -g option apply only when external server becomes

reachable and not when it synch's to the local clock?

Add "tos orphan", drop "minclock 6" and drop "server 127.127.1.0".

Or not, your choice.



--000000000000bc6bbc063165f8c7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><div class=3D"gmail_quote gmail_quote_container"><di=
v dir=3D"ltr" class=3D"gmail_attr">On Thu, Mar 27, 2025, 17:30 rcheaito &lt= ;<a href=3D"mailto:questions@lists.ntp.org">questions@lists.ntp.org</a>&gt;=
wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8= ex;border-left:1px #ccc solid;padding-left:1ex">Does the -g apply to sync t=
he daemon to the local clock driver with this<br>
configuration, if external server takes longer time to become reachable?<br=


ntpd.config.param=3Drestrict default noquery nomodify notrap;restrict<br> 127.0.0.1;server 127.127.1.0 minpoll 3 maxpoll 3 iburst;tos orphanwait 8<br=

minclock 6;server 192.168.1.14 iburst minpoll 6;<br>
ntpd.init.param=3D-g -f /tffs0/ntpd_driftfile<br></blockquote></div></div><= div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote gmai= l_quote_container"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = .8ex;border-left:1px #ccc solid;padding-left:1ex">How can we make the=C2=A0=
-g option apply only when external server becomes<br>
reachable and not when it synch&#39;s to the local clock?<br></blockquote><= /div></div><div dir=3D"auto"><br></div><div dir=3D"auto">Add &quot;tos orph= an&quot;, drop &quot;minclock 6&quot; and drop &quot;server 127.127.1.0&quo= t;.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Or not, your choice.= </div><div dir=3D"auto"><div class=3D"gmail_quote gmail_quote_container"><b= lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px = #ccc solid;padding-left:1ex">
</blockquote></div></div></div>

--000000000000bc6bbc063165f8c7--

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

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.
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

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"
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

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

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

--000000000000a18c1b063169b384
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I have the instructions for using a Raspberry Pi as ntp server.

Contact me for these instructions.

Chip

On Fri, Mar 28, 2025 at 11:59=E2=80=AFAM Terje Mathisen <terje.mathisen@tms= w.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 serve=

r

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 servin=

g

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 tim=

e

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"

--=20
Ralph "Chip" Blach
(919) 260-0097

--000000000000a18c1b063169b384
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I have the instructions for using a Raspberry Pi as ntp se= rver.<div><br></div><div>Contact me for these instructions.</div><div><br><= /div><div>Chip</div></div><br><div class=3D"gmail_quote gmail_quote_contain= er"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Mar 28, 2025 at 11:59=E2= =80=AFAM Terje Mathisen &lt;<a href=3D"mailto:terje.mathisen@tmsw.no">terje= .mathisen@tmsw.no</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote"=
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p= adding-left:1ex">rcheaito via questions Mailing List wrote:<br>
&gt; Using the orphanwait to reduce the time it takes ntpd to synch up with=
the<br>
&gt; local system clock, as in this configuration, we need to have the serv=
er part<br>
&gt; of ntpd to be ready as soon as possible to serve some other devices<br=

&gt; (regardless of whether the time is valid or not, or has synch&#39;ed o=
r not with<br>
&gt; the external server).=C2=A0 If we keep the default orphanwait (300 sec= onds), the<br>
&gt; daemon won&#39;t be able to serve the other devices while trying to sy= nch with the<br>
&gt; external server and may take up to 5 minutes before it can start servi=
ng them<br>
&gt; if the external server was not reachable/could synch with earlier.<br> &gt; <br>
&gt; Configuring a local refclock as we want ntpd to be a server for other = devices,<br>
&gt; and so we want this server to become available asap and sync with a ti= me<br>
&gt; source quickly.<br>
&gt; <br>
All that sounds reasonable, IFF you don&#39;t know anything about how NTPD =

actually works!<br>

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

You really, really, really does not want your NTP server to provide <br>
bodus time to any client, at any point in time! It is far better to not <br=

reply than to be a falseticker for several minutes.<br>

If you cannot guarantee WAN network connectivity, then I strongly <br> encourage you to setup a local GPS reference for your server. I don&#39;t <=

know what the current best/cheapest option is but more than 10 years ago <b=

you could buy a Sure reference board for ~$80, solder a single line to <br> route the PPS signal to the RS232 Carrier Detect pin, and you would have <b=

a clock that was accurate to maybe 25 ns RMS.<br>

Terje<br>

-- <br>
- &lt;Terje.Mathisen at <a href=3D"http://tmsw.no" rel=3D"noreferrer" targe= t=3D"_blank">tmsw.no</a>&gt;<br>
&quot;almost all programming can be viewed as an exercise in caching&quot;<=


</blockquote></div><div><br clear=3D"all"></div><div><br></div><span class= =3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_s= ignature">Ralph &quot;Chip&quot; Blach<br>(919) 260-0097<br><br><br><br></d=


--000000000000a18c1b063169b384--

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

--000000000000c9dfec063169c9ce
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 27, 2025 at 7:30=E2=80=AFPM rcheaito <questions@lists.ntp.org> = 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?

I'm elaborating on James Browning's answer, which is the right answer.

The -g applies to the first clock adjustment, allowing its magnitude to be greater than "panic". The source of time does not matter.

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

You can drop the local clock driver 127.127.1.0 from your configuration.
Let ntpd fall back to orphan mode. In orphan mode, there is no clock discipline. When ntpd later peers to an external server, only then does the first clock adjustment take place, and therefore only then does -g apply. Before then, the orphan ntpd serves uncorrected, undisciplined local time
to its clients.

For information about how to do this, read "Orphan Mode" in the NTP documentation.

Cheers
Edward

--000000000000c9dfec063169c9ce
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thu, Mar 27, 2025 at 7:30=E2=80=AFPM rcheaito &lt;<a hr= ef=3D"mailto:questions@lists.ntp.org">questions@lists.ntp.org</a>&gt; wrote= :<br>&gt; Does the -g apply to sync the daemon to the local clock driver wi=
th this<br>&gt; configuration, if external server takes longer time to beco=
me reachable?<div><br></div><div>I&#39;m elaborating on James Browning&#39;=
s answer, which is the right answer.<br><br>The -g applies to the first clo=
ck adjustment, allowing its magnitude to be greater than &quot;panic&quot;.=
The source of time does not matter.<br><br>&gt; How can we make the =C2=A0=
-g option apply only when external server becomes<br>&gt; reachable and not=
when it synch&#39;s to the local clock?<br><br>You can drop the local cloc=
k driver 127.127.1.0 from your configuration. Let ntpd fall back to orphan = mode. In orphan mode, there is no clock discipline. When ntpd later peers t=
o an external server, only then does the first clock adjustment take place,= =C2=A0and therefore only then does -g apply. Before then, the orphan ntpd s= erves uncorrected, undisciplined local time to its clients.</div><div><div>= <br></div><div>For information about how to do this, read &quot;Orphan Mode= &quot; in the NTP documentation.</div></div><div><br></div><div>Cheers</div= ><div>Edward</div></div>

--000000000000c9dfec063169c9ce--

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

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.


--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

--0000000000000a83eb06316de08a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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.

On Fri, Mar 28, 2025 at 2:43=E2=80=AFPM Jim Pennino <jimp@gonzo.specsol.net=

wrote:

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 wit=

h

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 no=

t

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.

--0000000000000a83eb06316de08a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Caution advised.=C2=A0 When I monitored a FC-NTP-Mini 1.5 = years ago the timestamp resolution was only 1 msec.=C2=A0=C2=A0<div>Additio= nally once in 2000 NTP responses the time stamp was in error by 1 second (t=
op of the second problem).</div><div><br></div><div>Things may have improve=
d since then.</div></div><br><div class=3D"gmail_quote gmail_quote_containe= r"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Mar 28, 2025 at 2:43=E2=80= =AFPM Jim Pennino &lt;<a href=3D"mailto:jimp@gonzo.specsol.net">jimp@gonzo.= specsol.net</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style= =3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding= -left:1ex">William Unruh &lt;<a href=3D"mailto:unruh@invalid.ca" target=3D"= _blank">unruh@invalid.ca</a>&gt; wrote:<br>
&gt; On 2025-03-28, Terje Mathisen &lt;<a href=3D"mailto:terje.mathisen@tms= w.no" target=3D"_blank">terje.mathisen@tmsw.no</a>&gt; wrote:<br>
&gt;&gt; rcheaito via questions Mailing List wrote:<br>
&gt;&gt;&gt; Using the orphanwait to reduce the time it takes ntpd to synch=
up with the<br>
&gt;&gt;&gt; local system clock, as in this configuration, we need to have = the server part<br>
&gt;&gt;&gt; of ntpd to be ready as soon as possible to serve some other de= vices<br>
&gt;&gt;&gt; (regardless of whether the time is valid or not, or has synch&= #39;ed or not with<br>
&gt;&gt;&gt; the external server).=C2=A0 If we keep the default orphanwait = (300 seconds), the<br>
&gt;&gt;&gt; daemon won&#39;t be able to serve the other devices while tryi=
ng to synch with the<br>
&gt;&gt;&gt; external server and may take up to 5 minutes before it can sta=
rt serving them<br>
&gt;&gt;&gt; if the external server was not reachable/could synch with earl= ier.<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; Configuring a local refclock as we want ntpd to be a server fo=
r other devices,<br>
&gt;&gt;&gt; and so we want this server to become available asap and sync w= ith a time<br>
&gt;&gt;&gt; source quickly.<br>
&gt;&gt;&gt; <br>
&gt;&gt; All that sounds reasonable, IFF you don&#39;t know anything about = how NTPD <br>
&gt;&gt; actually works!<br>
&gt;&gt;<br>
&gt;&gt; What you need is iburst, possibly along with burst and minpoll 4, =

&gt;&gt; against a network-locally ntpd server.<br>
&gt;&gt;<br>
&gt;&gt; You really, really, really does not want your NTP server to provid=
e <br>
&gt;&gt; bodus time to any client, at any point in time! It is far better t=
o not <br>
&gt;&gt; reply than to be a falseticker for several minutes.<br>
&gt;&gt;<br>
&gt;&gt; If you cannot guarantee WAN network connectivity, then I strongly =

&gt;&gt; encourage you to setup a local GPS reference for your server. I do= n&#39;t <br>
&gt;&gt; know what the current best/cheapest option is but more than 10 yea=
rs ago <br>
&gt;&gt; you could buy a Sure reference board for ~$80, solder a single lin=
e to <br>
&gt;&gt; route the PPS signal to the RS232 Carrier Detect pin, and you woul=
d have <br>
&gt;&gt; a clock that was accurate to maybe 25 ns RMS.<br>
&gt; <br>
&gt; I think the biggest problem is that most computers no longer have a<br=

&gt; serial or parallel input port and<br>
&gt; I don&#39;t think usb has the needed interrupt accuracy.<br>
&gt; The price of gps receivers is less than $50, but am not sure of their<=

&gt; timing capability<br>
&gt; <br>
&gt;&gt;<br>
&gt;&gt; Terje<br>
&gt;&gt;<br>

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

These things have a GNSS receiver, an active antenna, power supply and a<br=

10/100Mbps wired ethernet port.<br>

Their intrinsic accuracy is on the order of about 100 nanoseconds and<br>
can handle many hundreds of clients, so three of these things can easily<br=

provide ntp time for a huge local network.<br>

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

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


</blockquote></div>

--0000000000000a83eb06316de08a--

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

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

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

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
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

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
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

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
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

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
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

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
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

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
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

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

--- Synchronet 3.20c-Linux NewsLink 1.2