From Newsgroup: comp.protocols.time.ntp

Hi group,

On one of the networks I run, some of the NTP servers have failed and
proven difficult to get back up and running. This has resulted in the
usual ensemble consisting of one working server and two not running servers.

Unfortunately, some ntpd-based NTP clients have decided that having
only one time source means they should stop adjusting the local clock,
thus causing machines to drift apart rather than fall back to using
the surviving server.

Is there a way (via ntp.conf or similar) to tell the ntpd algorithms
to not give up in this scenario.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 S|+borg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

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

On Wed, Jan 7, 2026, 03:32 Jakob Bohm <jb-usenet@wisemo.invalid> wrote:

Hi group,

On one of the networks I run, some of the NTP servers have failed and
proven difficult to get back up and running. This has resulted in the
usual ensemble consisting of one working server and two not running
servers.

Unfortunately, some ntpd-based NTP clients have decided that having
only one time source means they should stop adjusting the local clock,
thus causing machines to drift apart rather than fall back to using
the surviving server.

Is there a way (via ntp.conf or similar) to tell the ntpd algorithms
to not give up in this scenario.

"tos orphan" will tell ntpd to serve time even without time sources.

IIRC "tos minsane" and "tos minclock" are probably what you are looking for.

See the ntp_conf (?) web or man page for specifics.



--000000000000e246db0647cb1056
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 Wed, Jan 7, 2026, 03:32 Jakob Bohm &l= t;jb-usenet@wisemo.invalid&gt; wrote:<br></div><blockquote class=3D"gmail_q= uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e= x">Hi group,<br>

On one of the networks I run, some of the NTP servers have failed and <br> proven difficult to get back up and running.=C2=A0 This has resulted in the=

usual ensemble consisting of one working server and two not running servers= .<br>

Unfortunately, some ntpd-based NTP clients have decided that having<br>
only one time source means they should stop adjusting the local clock,<br>
thus causing machines to drift apart rather than fall back to using<br>
the surviving server.<br>

Is there a way (via ntp.conf or similar) to tell the ntpd algorithms<br>
to not give up in this scenario.<br></blockquote></div></div><div dir=3D"au= to"><br></div><div dir=3D"auto">&quot;tos orphan&quot; will tell ntpd to se= rve time even without time sources.=C2=A0</div><div dir=3D"auto"><br></div>= <div dir=3D"auto">IIRC &quot;tos minsane&quot; and &quot;tos minclock&quot;=
are probably what you are looking for.</div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">See the ntp_conf (?) web or man page for specifics.</div><d=
iv dir=3D"auto"><div class=3D"gmail_quote gmail_quote_container"><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol= id;padding-left:1ex">
</blockquote></div></div></div>

--000000000000e246db0647cb1056--

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

On 07/01/2026 10:33, Jakob Bohm wrote:

Unfortunately, some ntpd-based NTP clients have decided that having
only one time source means they should stop adjusting the local clock,
thus causing machines to drift apart rather than fall back to using
the surviving server.

Do the problem clients have the local clock driver configured? I seem
to remember that this will be treated normally, as far as rejecting
outliers is concerned, so if there is one other source, and the error
bounds don't overlap, both will be rejected. (Pure clients should not
be using this.)
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

On 07/01/2026 15:40, David Woolley wrote:

On 07/01/2026 10:33, Jakob Bohm wrote:

Unfortunately, some ntpd-based NTP clients have decided that having
only one time source means they should stop adjusting the local clock,
thus causing machines to drift apart rather than fall back to using
the surviving server.

Do the problem clients have the local clock driver configured?-a I seem
to remember that this will be treated normally, as far as rejecting
outliers is concerned, so if there is one other source, and the error
bounds don't overlap, both will be rejected.-a (Pure clients should not
be using this.)

No, they don't reference the local clock driver.

Also, the affected clients seem to be running the ntpsec modification of
ntpd, but I was hoping it would be a setting not specific to ntpsec.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 S|+borg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

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

On Wed, Jan 7, 2026, 09:43 Jakob Bohm <jb-usenet@wisemo.invalid> wrote:
On 07/01/2026 15:40, David Woolley wrote:

On 07/01/2026 10:33, Jakob Bohm wrote:

Unfortunately, some ntpd-based NTP clients have decided that having
only one time source means they should stop adjusting the local clock,
thus causing machines to drift apart rather than fall back to using
the surviving server.

Do the problem clients have the local clock driver configured? I seem
to remember that this will be treated normally, as far as rejecting
outliers is concerned, so if there is one other source, and the error
bounds don't overlap, both will be rejected. (Pure clients should not
be using this.)

No, they don't reference the local clock driver.

Also, the affected clients seem to be running the ntpsec modification of
ntpd, but I was hoping it would be a setting not specific to ntpsec.

It is probably specific to NTPsec, which has greater default values for minclock and minsane. You will probably want to decrease both to (probably)
1 on the clients.

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

<div dir=3D"auto">On Wed, Jan 7, 2026, 09:43 Jakob Bohm &lt;jb-usenet@wisem= o.invalid&gt; wrote:<br>On 07/01/2026 15:40, David Woolley wrote:<br>&gt; O=
n 07/01/2026 10:33, Jakob Bohm wrote:<br>&gt;&gt; Unfortunately, some ntpd-= based NTP clients have decided that having<br>&gt;&gt; only one time source=
means they should stop adjusting the local clock,<br>&gt;&gt; thus causing=
machines to drift apart rather than fall back to using<br>&gt;&gt; the sur= viving server.<br>&gt;<br>&gt; Do the problem clients have the local clock = driver configured?=C2=A0 I seem<br>&gt; to remember that this will be treat=
ed normally, as far as rejecting<br>&gt; outliers is concerned, so if there=
is one other source, and the error<br>&gt; bounds don&#39;t overlap, both = will be rejected.=C2=A0 (Pure clients should not<br>&gt; be using this.)<br= ><br>No, they don&#39;t reference the local clock driver.<br><br>Also, the = affected clients seem to be running the ntpsec modification of<br>ntpd, but=
I was hoping it would be a setting not specific to ntpsec.<br><br>It is pr= obably specific to NTPsec, which has greater default values for minclock an=
d minsane. You will probably want to decrease both to (probably) 1 on the c= lients.<br></div>

--000000000000d1174b0647d07ee9--

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

On 07/01/2026 17:04, Jakob Bohm wrote:

Also, the affected clients seem to be running the ntpsec modification of ntpd, but I was hoping it would be a setting not specific to ntpsec.

What is the reason, reported by ntpq, for rejecting the server (the
tally character, from the peers sub-command)?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

On 08/01/2026 13:32, David Woolley wrote:

On 07/01/2026 17:04, Jakob Bohm wrote:

Also, the affected clients seem to be running the ntpsec modification
of ntpd, but I was hoping it would be a setting not specific to ntpsec.

What is the reason, reported by ntpq, for rejecting the server (the
tally character, from the peers sub-command)?

"+" rather than "*", and the offset diverges slowly but surely far from
0 (some clients reached multiple seconds of error).

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 S|+borg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

On 13/01/2026 07:09, Jakob Bohm wrote:

"+" rather than "*", and the offset diverges slowly but surely far from
0 (some clients reached multiple seconds of error).

If it is showing "+", it should be included in the solution for the
offset and used to adjust the clock. My assumption would be that it was
an ntpsec bug, but I'm not aware of any expertise on ntpsec on this newsgroup/mailing list.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

On 13/01/2026 12:54, David Woolley wrote:

On 13/01/2026 07:09, Jakob Bohm wrote:

"+" rather than "*", and the offset diverges slowly but surely far
from 0 (some clients reached multiple seconds of error).

If it is showing "+", it should be included in the solution for the
offset and used to adjust the clock.-a My assumption would be that it was
an ntpsec bug, but I'm not aware of any expertise on ntpsec on this newsgroup/mailing list.

Yes, I know it should be included, problem is that if there is only one
time source that qualifies, some ntpd versions (at least my copy of
ntpsec) finds no solution and doesn't discipline the local clock.

Work around for now is to make some low quality local servers (lots of
jitter) selectable, thus letting ntpd select a solution with both good
and bad sources.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 S|+borg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp


On 1/15/26 4:04 AM, Jakob Bohm wrote:

On 13/01/2026 12:54, David Woolley wrote:

On 13/01/2026 07:09, Jakob Bohm wrote:

"+" rather than "*", and the offset diverges slowly but surely far
from 0 (some clients reached multiple seconds of error).

If it is showing "+", it should be included in the solution for the
offset and used to adjust the clock.-a My assumption would be that it
was an ntpsec bug, but I'm not aware of any expertise on ntpsec on
this newsgroup/mailing list.

Yes, I know it should be included, problem is that if there is only one
time source that qualifies, some ntpd versions (at least my copy of
ntpsec) finds no solution and doesn't discipline the local clock.

Work around for now is to make some low quality local servers (lots of jitter) selectable, thus letting ntpd select a solution with both good
and bad sources.

If you use ntpd then we may be able to help you. ntpsec cut out anything
that they think they could remove without understanding the consequences.

Danny


--- Synchronet 3.21a-Linux NewsLink 1.2