From Newsgroup: comp.protocols.time.ntp

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

Dear NTP Community,

We have observed a potentially unexpected behavior with ntpd version
*4.2.8p18* concerning the delay in transitioning to stratum 16 when a local reference clock (tsync) loses synchronization.

Issue Summary

When our local reference clock (tsync) becomes unsynchronized, we expect
ntpd to stop selecting it and switch the system to stratum 16 relatively quickly, indicating the system is no longer a valid time source.

However, on systems running *ntpd 4.2.8p18*, this transition appears *delay=
ed
by up to one hour*. During this time, ntpd continues to treat tsync as a
valid source and *reports stratum 1*, even though synchronization is no
longer valid.

In comparison, this behavior does *not occur* in older versions like *4.2.8p15*, where the system transitions to stratum 16 within a few minutes=
.

We suspect this may be due to internal changes in source selection and
trust logic introduced in later versions, possibly making ntpd more conservative about declassifying known sources =E2=80=94 even when they bec= ome
unreliable.

Temporary Workaround

We experimented with the following configuration adjustments, which appear
to mitigate the issue by making ntpd more responsive:





*tos orphanwait 1tos mindist 0.05tinker stepout 10tinker panic 0minpoll 3maxpoll 4*

These parameters seem to accelerate response to changes in sync status. Questions

1.

Is this delay in downgrading to stratum 16 in 4.2.8p18 an *intended
behavior*, or is it considered a *regression* compared to earlier
versions?
2.

Are there *recommended configuration settings* or best practices to
ensure timely transition to stratum 16 when a local reference becomes
unreliable?
3.

Would it be appropriate to submit this as a *bug report*?

We would appreciate any clarification or guidance you can provide on this matter.

Best regards,
--=20

*Cordialement,*
*Samir MOUHOUNE*

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

<div dir=3D"ltr"><div>Dear NTP Community,</div><div><br></div><div>We have = observed a potentially unexpected behavior with <code>ntpd</code> version <= strong>4.2.8p18</strong> concerning the delay in transitioning to stratum 1=
6 when a local reference clock (tsync) loses synchronization.<br><br><h3>Is= sue Summary</h3>
<p>When our local reference clock (tsync) becomes unsynchronized, we expect=
<code>ntpd</code> to stop selecting it and switch the system to stratum 16=
relatively quickly, indicating the system is no longer a valid time source= .</p>
<p>However, on systems running <strong>ntpd 4.2.8p18</strong>, this transit= ion appears <strong>delayed by up to one hour</strong>. During this time, <= code>ntpd</code> continues to treat tsync as a valid source and <strong>rep= orts stratum 1</strong>, even though synchronization is no longer valid.</p=

<p>In comparison, this behavior does <strong>not occur</strong> in older ve= rsions like <strong>4.2.8p15</strong>, where the system transitions to stra= tum 16 within a few minutes.</p>
<p>We suspect this may be due to internal changes in source selection and t= rust logic introduced in later versions, possibly making <code>ntpd</code> = more conservative about declassifying known sources =E2=80=94 even when the=
y become unreliable.<br><br></p><h3>Temporary Workaround</h3><p>
</p><p>We experimented with the following configuration adjustments, which = appear to mitigate the issue by making <code>ntpd</code> more responsive:<b= r><b><i>tos orphanwait 1<br>tos mindist 0.05<br>tinker stepout 10<br>tinker=
panic 0<br>minpoll 3<br>maxpoll 4</i></b><br></p><p>These parameters seem =
to accelerate response to changes in sync status.</p></div><div><h3>Questio= ns</h3>


<p>Is this delay in downgrading to stratum 16 in 4.2.8p18 an <strong>intend=
ed behavior</strong>, or is it considered a <strong>regression</strong> com= pared to earlier versions?</p>
</li>

<p>Are there <strong>recommended configuration settings</strong> or best pr= actices to ensure timely transition to stratum 16 when a local reference be= comes unreliable?</p>
</li>

<p>Would it be appropriate to submit this as a <strong>bug report</strong>?=

</li>
</ol>
<p>We would appreciate any clarification or guidance you can provide on thi=
s matter.</p>
<p>Best regards,</p></div><span class=3D"gmail_signature_prefix">-- </span>= <br><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_sign= ature"><div dir=3D"ltr"><div><b><font size=3D"2"><i><span style=3D"font-fam= ily:arial black,sans-serif">Cordialement,<br></span></i></font></b></div><b= ><font size=3D"2"><i><span style=3D"font-family:arial black,sans-serif">Sam=
ir MOUHOUNE</span></i></font></b><br></div></div></div>

--00000000000032090c06361cfe85--

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

Hi Samir,

It looks like you are aware of the complexity here.

As for is it a bug or a feature, I think the answer is "it depends", and
it really depends on each situation.

In no particular order:

- what other sources of time does ntpd see? Just because a time source
goes dark for a while shouldn't matter. PHI marches on, and at some
point the root dispersion will grow and knock the time soure out of the running.
- It seems like your scenario has an insufficient number of time sources.
- If ntpd will call tsync often enough, what is the actual difference
between letting it hit S16 faster/slower, and re-establishing tsync as a source when it is available again?
- How robust is your set of orphan servers?

The list goes on.

And from my POV, as long as ntpd has sufficiently robust "mechanism" to
allow you to tune its behavior to implement your "local policy" choices, that's sufficient. As long as the default behavior is sufficient for
enough people, that seems OK.

H

On 5/27/2025 5:13 AM, MOUHOUNE Samir wrote:

Dear NTP Community,

We have observed a potentially unexpected behavior with |ntpd| version *4.2.8p18* concerning the delay in transitioning to stratum 16 when a
local reference clock (tsync) loses synchronization.

Issue Summary

When our local reference clock (tsync) becomes unsynchronized, we expect |ntpd| to stop selecting it and switch the system to stratum 16
relatively quickly, indicating the system is no longer a valid time source.

However, on systems running *ntpd 4.2.8p18*, this transition appears *delayed by up to one hour*. During this time, |ntpd| continues to treat tsync as a valid source and *reports stratum 1*, even though
synchronization is no longer valid.

In comparison, this behavior does *not occur* in older versions like *4.2.8p15*, where the system transitions to stratum 16 within a few minutes.

We suspect this may be due to internal changes in source selection and
trust logic introduced in later versions, possibly making |ntpd| more conservative about declassifying known sources — even when they become unreliable.

Temporary Workaround

We experimented with the following configuration adjustments, which
appear to mitigate the issue by making |ntpd| more responsive:
*/tos orphanwait 1
tos mindist 0.05
tinker stepout 10
tinker panic 0
minpoll 3
maxpoll 4/*

These parameters seem to accelerate response to changes in sync status.

Questions

1.

Is this delay in downgrading to stratum 16 in 4.2.8p18 an *intended
behavior*, or is it considered a *regression* compared to earlier
versions?

2.

Are there *recommended configuration settings* or best practices to
ensure timely transition to stratum 16 when a local reference
becomes unreliable?

3.

Would it be appropriate to submit this as a *bug report*?

We would appreciate any clarification or guidance you can provide on
this matter.

Best regards,

--
*/Cordialement,
/*
*/Samir MOUHOUNE/*

--
Harlan Stenn <stenn@ntp.org>
NTP Project Lead. The NTP Project is part of
https://www.nwtime.org/ - be a member!

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

On 2025-05-28 03:08, Harlan Stenn via questions Mailing List wrote:

Hi Samir,

It looks like you are aware of the complexity here.

As for is it a bug or a feature, I think the answer is "it depends", and
it really depends on each situation.

In no particular order:

- what other sources of time does ntpd see?  Just because a time source goes dark for a while shouldn't matter.  PHI marches on, and at some
point the root dispersion will grow and knock the time soure out of the running.
- It seems like your scenario has an insufficient number of time sources.
- If ntpd will call tsync often enough, what is the actual difference between letting it hit S16 faster/slower, and re-establishing tsync as a source when it is available again?
- How robust is your set of orphan servers?

The list goes on.

And from my POV, as long as ntpd has sufficiently robust "mechanism" to allow you to tune its behavior to implement your "local policy" choices, that's sufficient.  As long as the default behavior is sufficient for enough people, that seems OK.

H

On 5/27/2025 5:13 AM, MOUHOUNE Samir wrote:

Dear NTP Community,

We have observed a potentially unexpected behavior with |ntpd| version
*4.2.8p18* concerning the delay in transitioning to stratum 16 when a
local reference clock (tsync) loses synchronization.


      Issue Summary

When our local reference clock (tsync) becomes unsynchronized, we
expect |ntpd| to stop selecting it and switch the system to stratum 16
relatively quickly, indicating the system is no longer a valid time
source.

However, on systems running *ntpd 4.2.8p18*, this transition appears
*delayed by up to one hour*. During this time, |ntpd| continues to
treat tsync as a valid source and *reports stratum 1*, even though
synchronization is no longer valid.

In comparison, this behavior does *not occur* in older versions like
*4.2.8p15*, where the system transitions to stratum 16 within a few
minutes.

We suspect this may be due to internal changes in source selection and
trust logic introduced in later versions, possibly making |ntpd| more
conservative about declassifying known sources — even when they become
unreliable.


      Temporary Workaround

We experimented with the following configuration adjustments, which
appear to mitigate the issue by making |ntpd| more responsive:
*/tos orphanwait 1
tos mindist 0.05
tinker stepout 10
tinker panic 0
minpoll 3
maxpoll 4/*

These parameters seem to accelerate response to changes in sync status.


      Questions

 1.

    Is this delay in downgrading to stratum 16 in 4.2.8p18 an *intended >>     behavior*, or is it considered a *regression* compared to earlier
    versions?

 2.

    Are there *recommended configuration settings* or best practices to >>     ensure timely transition to stratum 16 when a local reference
    becomes unreliable?

 3.

    Would it be appropriate to submit this as a *bug report*?

We would appreciate any clarification or guidance you can provide on
this matter.

Best regards,

--
*/Cordialement,
/*
*/Samir MOUHOUNE/*

You seem to have missed the point. This is clearly about the behavior
on a STRATUM 1 server when the hardware(-ish) time source fails, such as
a Maser failing. In these cases, ntpd needs to quickly lower its
announced stratum so the stratum 2 NTP servers will select a different
upstream until the issue is fixed . Orphan mode should rarely apply
except in small sites with no Internet sources and no backup hardware
sources . However the affected stratum 1 server might or might not
generally benefit from using NTP time sources as a fallback for
disciplining the local clock .

Enjoy

Jakob
--
Jakob Bohm, MSc.Eng., I speak only for myself, not my company
This public discussion message is non-binding and may contain errors
All trademarks and other things belong to their owners, if any.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

On 2025-06-23, Jakob Bohm <egenagwemdimtapsar@jbohm.dk> wrote:

On 2025-05-28 03:08, Harlan Stenn via questions Mailing List wrote:

Hi Samir,

It looks like you are aware of the complexity here.

As for is it a bug or a feature, I think the answer is "it depends", and
it really depends on each situation.

In no particular order:

- what other sources of time does ntpd see?  Just because a time source
goes dark for a while shouldn't matter.  PHI marches on, and at some
point the root dispersion will grow and knock the time soure out of the
running.
- It seems like your scenario has an insufficient number of time sources.
- If ntpd will call tsync often enough, what is the actual difference
between letting it hit S16 faster/slower, and re-establishing tsync as a
source when it is available again?
- How robust is your set of orphan servers?

The list goes on.

And from my POV, as long as ntpd has sufficiently robust "mechanism" to
allow you to tune its behavior to implement your "local policy" choices,
that's sufficient.  As long as the default behavior is sufficient for
enough people, that seems OK.

H

On 5/27/2025 5:13 AM, MOUHOUNE Samir wrote:

Dear NTP Community,

We have observed a potentially unexpected behavior with |ntpd| version
*4.2.8p18* concerning the delay in transitioning to stratum 16 when a
local reference clock (tsync) loses synchronization.


      Issue Summary

When our local reference clock (tsync) becomes unsynchronized, we
expect |ntpd| to stop selecting it and switch the system to stratum 16
relatively quickly, indicating the system is no longer a valid time
source.

However, on systems running *ntpd 4.2.8p18*, this transition appears
*delayed by up to one hour*. During this time, |ntpd| continues to
treat tsync as a valid source and *reports stratum 1*, even though
synchronization is no longer valid.

In comparison, this behavior does *not occur* in older versions like
*4.2.8p15*, where the system transitions to stratum 16 within a few
minutes.

We suspect this may be due to internal changes in source selection and
trust logic introduced in later versions, possibly making |ntpd| more
conservative about declassifying known sources — even when they become >>> unreliable.


      Temporary Workaround

We experimented with the following configuration adjustments, which
appear to mitigate the issue by making |ntpd| more responsive:
*/tos orphanwait 1
tos mindist 0.05
tinker stepout 10
tinker panic 0
minpoll 3
maxpoll 4/*

These parameters seem to accelerate response to changes in sync status.


      Questions

 1.

    Is this delay in downgrading to stratum 16 in 4.2.8p18 an *intended >>>     behavior*, or is it considered a *regression* compared to earlier >>>     versions?

 2.

    Are there *recommended configuration settings* or best practices to >>>     ensure timely transition to stratum 16 when a local reference
    becomes unreliable?

 3.

    Would it be appropriate to submit this as a *bug report*?

We would appreciate any clarification or guidance you can provide on
this matter.

Best regards,

--
*/Cordialement,
/*
*/Samir MOUHOUNE/*

And how does ntp know that a maser has failed?. The only information it
has is the return ntp packets (or lack thereof). And a return packet can
fail to arrive if your computer's connection to the net has failed,
temporarily or permanantly, or if the outside server has been
disconnected or is temporarily bad. ntp waits a while tries again.
An hour is no time at all. If you inow something has happened to the
source, you need to go in and resetup ntp to take that into account.


Make sure you have 5 or 7 independent sources, so the majority can vote
out the misbehaving source.

You seem to have missed the point. This is clearly about the behavior
on a STRATUM 1 server when the hardware(-ish) time source fails, such as
a Maser failing. In these cases, ntpd needs to quickly lower its

announced stratum so the stratum 2 NTP servers will select a different upstream until the issue is fixed . Orphan mode should rarely apply
except in small sites with no Internet sources and no backup hardware
sources . However the affected stratum 1 server might or might not
generally benefit from using NTP time sources as a fallback for
disciplining the local clock .

Enjoy

Jakob

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

On 2025-06-26 01:36, William Unruh wrote:

On 2025-06-23, Jakob Bohm <egenagwemdimtapsar@jbohm.dk> wrote:

On 2025-05-28 03:08, Harlan Stenn via questions Mailing List wrote:

Hi Samir,

It looks like you are aware of the complexity here.

As for is it a bug or a feature, I think the answer is "it depends", and >>> it really depends on each situation.

In no particular order:

- what other sources of time does ntpd see?  Just because a time source >>> goes dark for a while shouldn't matter.  PHI marches on, and at some
point the root dispersion will grow and knock the time soure out of the
running.
- It seems like your scenario has an insufficient number of time sources. >>> - If ntpd will call tsync often enough, what is the actual difference
between letting it hit S16 faster/slower, and re-establishing tsync as a >>> source when it is available again?
- How robust is your set of orphan servers?

The list goes on.

And from my POV, as long as ntpd has sufficiently robust "mechanism" to
allow you to tune its behavior to implement your "local policy" choices, >>> that's sufficient.  As long as the default behavior is sufficient for
enough people, that seems OK.

H

On 5/27/2025 5:13 AM, MOUHOUNE Samir wrote:

Dear NTP Community,

We have observed a potentially unexpected behavior with |ntpd| version >>>> *4.2.8p18* concerning the delay in transitioning to stratum 16 when a
local reference clock (tsync) loses synchronization.


      Issue Summary

When our local reference clock (tsync) becomes unsynchronized, we
expect |ntpd| to stop selecting it and switch the system to stratum 16 >>>> relatively quickly, indicating the system is no longer a valid time
source.

However, on systems running *ntpd 4.2.8p18*, this transition appears
*delayed by up to one hour*. During this time, |ntpd| continues to
treat tsync as a valid source and *reports stratum 1*, even though
synchronization is no longer valid.

In comparison, this behavior does *not occur* in older versions like
*4.2.8p15*, where the system transitions to stratum 16 within a few
minutes.

We suspect this may be due to internal changes in source selection and >>>> trust logic introduced in later versions, possibly making |ntpd| more
conservative about declassifying known sources — even when they become >>>> unreliable.


      Temporary Workaround

We experimented with the following configuration adjustments, which
appear to mitigate the issue by making |ntpd| more responsive:
*/tos orphanwait 1
tos mindist 0.05
tinker stepout 10
tinker panic 0
minpoll 3
maxpoll 4/*

These parameters seem to accelerate response to changes in sync status. >>>>

      Questions

 1.

    Is this delay in downgrading to stratum 16 in 4.2.8p18 an *intended
    behavior*, or is it considered a *regression* compared to earlier >>>>     versions?

 2.

    Are there *recommended configuration settings* or best practices to
    ensure timely transition to stratum 16 when a local reference
    becomes unreliable?

 3.

    Would it be appropriate to submit this as a *bug report*?

We would appreciate any clarification or guidance you can provide on
this matter.

Best regards,

--
*/Cordialement,
/*
*/Samir MOUHOUNE/*

And how does ntp know that a maser has failed?. The only information it
has is the return ntp packets (or lack thereof). And a return packet can
fail to arrive if your computer's connection to the net has failed, temporarily or permanantly, or if the outside server has been
disconnected or is temporarily bad. ntp waits a while tries again.
An hour is no time at all. If you inow something has happened to the
source, you need to go in and resetup ntp to take that into account.

In the scenario as I understand the OP, NTPD would know the difference
because it connects to the hardware/outside time source via a protocol
other than NTP, specifically any of the non-NTP protocols, such as PPS,
GPS, WWWB, DCF77, Modem etc. Thread seems to be about how an NTPD
instance tied exclusively to such a time source via appropriate hardware
reacts to said hardware going offline . OP seems to complain that a
recent patchlevel NTPD update made it react much more slowly to such a situation .

Make sure you have 5 or 7 independent sources, so the majority can vote
out the misbehaving source.

Typically, the stratum 1 server in question would be one of those 4 to 7
NTP time sources feeding another NTPD instance, and the problem is
making sure NTP data sent to the stratum 2 server stops advertising
stratum 1 as soon as the hardware time source goes away .

You seem to have missed the point. This is clearly about the behavior
on a STRATUM 1 server when the hardware(-ish) time source fails, such as
a Maser failing. In these cases, ntpd needs to quickly lower its

announced stratum so the stratum 2 NTP servers will select a different
upstream until the issue is fixed . Orphan mode should rarely apply
except in small sites with no Internet sources and no backup hardware
sources . However the affected stratum 1 server might or might not
generally benefit from using NTP time sources as a fallback for
disciplining the local clock .

Enjoy

Jakob
--
Jakob Bohm, MSc.Eng., I speak only for myself, not my company
This public discussion message is non-binding and may contain errors
All trademarks and other things belong to their owners, if any.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

On 2025-06-30, Jakob Bohm <egenagwemdimtapsar@jbohm.dk> wrote:

In the scenario as I understand the OP, NTPD would know the difference because it connects to the hardware/outside time source via a protocol
other than NTP, specifically any of the non-NTP protocols, such as PPS,
GPS, WWWB, DCF77, Modem etc. Thread seems to be about how an NTPD
instance tied exclusively to such a time source via appropriate hardware reacts to said hardware going offline . OP seems to complain that a
recent patchlevel NTPD update made it react much more slowly to such a situation .

Make sure you have 5 or 7 independent sources, so the majority can vote
out the misbehaving source.

Typically, the stratum 1 server in question would be one of those 4 to 7
NTP time sources feeding another NTPD instance, and the problem is
making sure NTP data sent to the stratum 2 server stops advertising
stratum 1 as soon as the hardware time source goes away .

Well, I am not sure about that. It would take a while for the stratum 1
to forget its training by the stratum 0 source. All ntpd knows is that
this time the stratum 0 did not respond (properly). It has no idea if
next time it will respond again. And having the startum change rapidly
is probably also not good. Again it has no knowlege whethere the
harwareish time source did not respond because the maser failed. Or
someone briefly and accidentaly (or purposely) interrupted the the connection.

And if that source comes online again, how long should ntp wait for
before it announces itself as stratum 1 again. If its other sources are
poor, it might take a while befor the stratum 1 shakes of the
disciplinng by the stratum 2 or stratum 15 sources and traces the
stratum 0 again.

You seem to have missed the point. This is clearly about the behavior
on a STRATUM 1 server when the hardware(-ish) time source fails, such as >>> a Maser failing. In these cases, ntpd needs to quickly lower its

announced stratum so the stratum 2 NTP servers will select a different
upstream until the issue is fixed . Orphan mode should rarely apply
except in small sites with no Internet sources and no backup hardware
sources . However the affected stratum 1 server might or might not
generally benefit from using NTP time sources as a fallback for
disciplining the local clock .

Enjoy

Jakob

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

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

On Tue, May 27, 2025 at 12:13=E2=80=AFUTC MOUHOUNE Samir <samir.mouhoune@gm= ail.com>
wrote:

Dear NTP Community,

We have observed a potentially unexpected behavior with ntpd version *4.2.8p18* concerning the delay in transitioning to stratum 16 when a
local reference clock (tsync) loses synchronization.

Issue Summary

When our local reference clock (tsync) becomes unsynchronized, we expect
ntpd to stop selecting it and switch the system to stratum 16 relatively quickly, indicating the system is no longer a valid time source.

However, on systems running *ntpd 4.2.8p18*, this transition appears *del=

ayed

by up to one hour*. During this time, ntpd continues to treat tsync as a valid source and *reports stratum 1*, even though synchronization is no longer valid.

In comparison, this behavior does *not occur* in older versions like *4.2.8p15*, where the system transitions to stratum 16 within a few
minutes.

We suspect this may be due to internal changes in source selection and
trust logic introduced in later versions, possibly making ntpd more conservative about declassifying known sources =E2=80=94 even when they b=

ecome

unreliable.

There have been no changes to ntpd/refclock_tsyncpci.c since 4.2.8p5 in
2016, so the issue might well affect other refclocks. It sounds like
something we need to fix, or at a minimum understand and justify as an improvement.

Temporary Workaround

We experimented with the following configuration adjustments, which appea=

r

to mitigate the issue by making ntpd more responsive:

*tos orphanwait 1tos mindist 0.05tinker stepout 10tinker panic 0minpoll 3maxpoll 4*

These parameters seem to accelerate response to changes in sync status.

That's a lot of different knobs turned. Did you make all 6 changes at once
and observe improvement, or one at a time, or ?
I'm glad you found something to help out, and those might help point to
code change(s) responsible, but given so many knobs changed, not as helpful
as I might hope.

Questions

1.

Is this delay in downgrading to stratum 16 in 4.2.8p18 an *intended
behavior*, or is it considered a *regression* compared to earlier
versions?

It's hard to see why it would be intended, but we're far from understanding
the issue well enough to be definitive.

1. Are there *recommended configuration settings* or best practices to
ensure timely transition to stratum 16 when a local reference becomes
unreliable?

Interesting renumbering of your questions is happening in the GMail web
editor using Chrome on Windows.
I think it's fair to say we're pretty weak on documented best practices or recommended configuration settings, but try https://doc.ntp.org/ You could also look at the archives of this list and its onetime evil twin newsgroup comp.protocols.time.ntp.

1.

Would it be appropriate to submit this as a *bug report*?

Yes, please, by all means. That's generally true if you think you've found
a misbehavior, regression, suboptimal behavior, or just have a request to improve. The only thing we don't welcome reports to https://bugs.ntp.org/ about are reports of a security nature, such as a remote crash of ntpd
based on a port 123 query, or nontrivial information disclosure or
elevation of privileges, things that might merit a CVE. In that case,
please submit the report to security@ntp.org to ensure the information is
not made public before remediation can be done.

I apologize for taking so long to respond. I've had a lot going on in my non-NTP life and I choose to have a relative firehose of email. Thanks to Jakob for bubbling this up to my attention again. Bug reports can be
ignored too, but much less likely than email.

Cheers,
Dave Hart

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

<div dir=3D"ltr"><div dir=3D"ltr"><div><div class=3D"gmail_default" style= =3D"font-family:&quot;trebuchet ms&quot;,sans-serif"></div></div></div><br>= <div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"= gmail_attr">On Tue, May 27, 2025 at 12<font face=3D"arial, sans-serif">:13= =E2=80=AF<span class=3D"gmail_default" style=3D"">UTC</span>=C2=A0MOU</font= >HOUNE Samir &lt;<a href=3D"mailto:samir.mouhoune@gmail.com">samir.mouhoune= @gmail.com</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"><div dir=3D"ltr"><div>Dear NTP Community,</div><div><br></div><d= iv>We have observed a potentially unexpected behavior with <code>ntpd</code=

version <strong>4.2.8p18</strong> concerning the delay in transitioning t=

o stratum 16 when a local reference clock (tsync) loses synchronization.<br= ><br><h3>Issue Summary</h3>
<p>When our local reference clock (tsync) becomes unsynchronized, we expect=
<code>ntpd</code> to stop selecting it and switch the system to stratum 16=
relatively quickly, indicating the system is no longer a valid time source= .</p>
<p>However, on systems running <strong>ntpd 4.2.8p18</strong>, this transit= ion appears <strong>delayed by up to one hour</strong>. During this time, <= code>ntpd</code> continues to treat tsync as a valid source and <strong>rep= orts stratum 1</strong>, even though synchronization is no longer valid.</p=

<p>In comparison, this behavior does <strong>not occur</strong> in older ve= rsions like <strong>4.2.8p15</strong>, where the system transitions to stra= tum 16 within a few minutes.</p>
<p>We suspect this may be due to internal changes in source selection and t= rust logic introduced in later versions, possibly making <code>ntpd</code> = more conservative about declassifying known sources =E2=80=94 even when the=
y become unreliable.</p></div></div></blockquote><div>=C2=A0</div><div><div=
class=3D"gmail_default" style=3D"font-family:&quot;trebuchet ms&quot;,sans= -serif">There have been no changes to ntpd/refclock_tsyncpci.c since 4.2.8p=
5 in 2016, so the issue might well affect other refclocks.=C2=A0 It sounds = like something we need to fix, or at a minimum understand and justify as an=
improvement.<span style=3D"font-family:Arial,Helvetica,sans-serif">=C2=A0<= br><br></span></div></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"= ><div dir=3D"ltr"><div><h3>Temporary Workaround</h3><p>
</p><p>We experimented with the following configuration adjustments, which = appear to mitigate the issue by making <code>ntpd</code> more responsive:<b= r><b><i>tos orphanwait 1<br>tos mindist 0.05<br>tinker stepout 10<br>tinker=
panic 0<br>minpoll 3<br>maxpoll 4</i></b><br></p><p>These parameters seem =
to accelerate response to changes in sync status.</p></div></div></blockquo= te><div><br></div><div><div class=3D"gmail_default" style=3D"font-family:&q= uot;trebuchet ms&quot;,sans-serif">That&#39;s a lot of different knobs turn= ed.=C2=A0 Did you make all 6 changes at once and observe improvement, or on=
e at a time, or ?</div><div class=3D"gmail_default" style=3D"font-family:&q= uot;trebuchet ms&quot;,sans-serif">I&#39;m glad you found something to help=
out, and those might help point to code change(s) responsible, but given s=
o many knobs changed, not as helpful as I might hope.</div></div><div class= =3D"gmail_default" style=3D"font-family:&quot;trebuchet ms&quot;,sans-serif= "><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"><div dir=3D"l= tr"><div><h3>Questions</h3>


<p>Is this delay in downgrading to stratum 16 in 4.2.8p18 an <strong>intend=
ed behavior</strong>, or is it considered a <strong>regression</strong> com= pared to earlier versions?</p></li></ol></div></div></blockquote><div>=C2= =A0</div><div><div class=3D"gmail_default" style=3D"font-family:&quot;trebu= chet ms&quot;,sans-serif">It&#39;s hard to see why it would be intended, bu=
t we&#39;re far from understanding the issue well enough to be definitive.<= /div></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg= in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e= x"><div dir=3D"ltr"><ol><li>Are there <strong>recommended configuration set= tings</strong> or best practices to ensure timely transition to stratum 16 = when a local reference becomes unreliable?</li></ol></div></blockquote><div= >=C2=A0</div><div class=3D"gmail_default" style=3D"font-family:&quot;trebuc= het ms&quot;,sans-serif">Interesting renumbering of your questions is happe= ning in the GMail web editor using Chrome on Windows.</div><div class=3D"gm= ail_default" style=3D"font-family:&quot;trebuchet ms&quot;,sans-serif">I th= ink it&#39;s fair to say we&#39;re pretty weak on documented best practices=
or recommended configuration settings, but try <a href=3D"https://doc.ntp.= org/">https://doc.ntp.org/</a>=C2=A0 You could also look at the archives of=
this list and its onetime evil twin newsgroup comp.protocols.time.ntp.</di= v><div class=3D"gmail_default" style=3D"font-family:&quot;trebuchet ms&quot= ;,sans-serif"><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><= div dir=3D"ltr"><div><ol><li><p>Would it be appropriate to submit this as a=
<strong>bug report</strong>?</p></li></ol></div></div></blockquote><div>= =C2=A0</div><div><div class=3D"gmail_default" style=3D"font-family:&quot;tr= ebuchet ms&quot;,sans-serif">Yes, please, by all means.=C2=A0 That&#39;s ge= nerally true if you think you&#39;ve found a misbehavior, regression, subop= timal behavior, or just have a request to improve.=C2=A0 The only thing we = don&#39;t welcome reports to <a href=3D"https://bugs.ntp.org/">https://bugs= .ntp.org/</a> about are reports of a security nature, such as a remote cras=
h of ntpd based on a port 123 query, or nontrivial information disclosure o=
r elevation of privileges, things that might merit a CVE.=C2=A0 In that cas=
e, please submit the report to <a href=3D"mailto:security@ntp.org">security= @ntp.org</a> to ensure the information is not made public before remediatio=
n can be done.</div></div><div class=3D"gmail_default" style=3D"font-family= :&quot;trebuchet ms&quot;,sans-serif"><br></div><div class=3D"gmail_default=
" style=3D"font-family:&quot;trebuchet ms&quot;,sans-serif">I apologize for=
taking so long to respond.=C2=A0 I&#39;ve had a lot going on in my non-NTP=
life and I choose to have a relative firehose of email.=C2=A0 Thanks to Ja= kob for bubbling this up to my attention again.=C2=A0 Bug reports can be ig= nored too, but much less likely than email.</div><div><div dir=3D"ltr" clas= s=3D"gmail_signature"><div dir=3D"ltr"><div><font face=3D"tahoma, sans-seri=
f" color=3D"#666666"><br></font></div><font face=3D"tahoma, sans-serif" col= or=3D"#666666">Cheers,<br>Dave Hart</font></div></div></div><br class=3D"gm= ail-Apple-interchange-newline"></div></div>

--000000000000fa29ba0638cea367--

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

As I've said before, just because the behavior is different does not
mean it's broken.

The NTP algorithms do ongoing evaluations of established associations.

If an association becomes non-responsive, it auto-degrades.

At some point the association will drop.

Dave Mills was, to the best of my recollection, very hesitant to throw
out an established association "too soon".

Let's get more information and understanding around what you're seeing.

H

On 6/30/2025 12:00 PM, Dave Hart wrote:

On Tue, May 27, 2025 at 12:13 UTC MOUHOUNE Samir <samir.mouhoune@gmail.com <mailto:samir.mouhoune@gmail.com>> wrote:

Dear NTP Community,

We have observed a potentially unexpected behavior with |ntpd|
version *4.2.8p18* concerning the delay in transitioning to stratum
16 when a local reference clock (tsync) loses synchronization.

Issue Summary

When our local reference clock (tsync) becomes unsynchronized, we
expect |ntpd| to stop selecting it and switch the system to stratum
16 relatively quickly, indicating the system is no longer a valid
time source.

However, on systems running *ntpd 4.2.8p18*, this transition appears
*delayed by up to one hour*. During this time, |ntpd| continues to
treat tsync as a valid source and *reports stratum 1*, even though
synchronization is no longer valid.

In comparison, this behavior does *not occur* in older versions like
*4.2.8p15*, where the system transitions to stratum 16 within a few
minutes.

We suspect this may be due to internal changes in source selection
and trust logic introduced in later versions, possibly making |ntpd|
more conservative about declassifying known sources — even when they
become unreliable.

There have been no changes to ntpd/refclock_tsyncpci.c since 4.2.8p5 in 2016, so the issue might well affect other refclocks.  It sounds like something we need to fix, or at a minimum understand and justify as an improvement.

Temporary Workaround

We experimented with the following configuration adjustments, which
appear to mitigate the issue by making |ntpd| more responsive:
*/tos orphanwait 1
tos mindist 0.05
tinker stepout 10
tinker panic 0
minpoll 3
maxpoll 4/*

These parameters seem to accelerate response to changes in sync status.

That's a lot of different knobs turned.  Did you make all 6 changes at
once and observe improvement, or one at a time, or ?
I'm glad you found something to help out, and those might help point to
code change(s) responsible, but given so many knobs changed, not as
helpful as I might hope.

Questions

1.

Is this delay in downgrading to stratum 16 in 4.2.8p18 an
*intended behavior*, or is it considered a *regression* compared
to earlier versions?

It's hard to see why it would be intended, but we're far from
understanding the issue well enough to be definitive.

1. Are there *recommended configuration settings* or best practices
to ensure timely transition to stratum 16 when a local reference
becomes unreliable?

Interesting renumbering of your questions is happening in the GMail web editor using Chrome on Windows.
I think it's fair to say we're pretty weak on documented best practices
or recommended configuration settings, but try https://doc.ntp.org/ <https://doc.ntp.org/>  You could also look at the archives of this list and its onetime evil twin newsgroup comp.protocols.time.ntp.

1.

Would it be appropriate to submit this as a *bug report*?

Yes, please, by all means.  That's generally true if you think you've
found a misbehavior, regression, suboptimal behavior, or just have a
request to improve.  The only thing we don't welcome reports to https:// bugs.ntp.org/ <https://bugs.ntp.org/> about are reports of a security nature, such as a remote crash of ntpd based on a port 123 query, or nontrivial information disclosure or elevation of privileges, things
that might merit a CVE.  In that case, please submit the report to security@ntp.org <mailto:security@ntp.org> to ensure the information is
not made public before remediation can be done.

I apologize for taking so long to respond.  I've had a lot going on in
my non-NTP life and I choose to have a relative firehose of email.
Thanks to Jakob for bubbling this up to my attention again.  Bug reports can be ignored too, but much less likely than email.

Cheers,
Dave Hart

--
Harlan Stenn <stenn@ntp.org>
NTP Project Lead. The NTP Project is part of
https://www.nwtime.org/ - be a member!

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

On 2025-07-01, Harlan Stenn via questions Mailing List <questions@lists.ntp.org> wrote:

The NTP algorithms do ongoing evaluations of established associations.

If an association becomes non-responsive, it auto-degrades.

At some point the association will drop.

Dave Mills was, to the best of my recollection, very hesitant to throw
out an established association "too soon".

Yes, what is reported in this thread as observed behavior of 4.2.8p15
and 4.2.8p18 both sound wrong to me. NTPv4 servers are not supposed to
claim they are unsynchronized (switch to stratum 16) when they lose a
working association (it doesn't matter if it's a refclock or NTP
server/peer). Quoting from RFC 5905 section 10:

It is important to note that, unlike NTPv3, NTPv4 associations do not
show a timeout condition by setting the stratum to 16 and leap
indicator to 3. The association variables retain the values
determined upon arrival of the last packet. In NTPv4, lambda
increases with time, so eventually the synchronization distance
exceeds the distance threshold MAXDIST, in which case the association
is considered unfit for synchronization.

It seems this changed between 4.2.8p14 and 4.2.8p15 as a result of
fixing this bug:
https://bugs.ntp.org/show_bug.cgi?id=3644

The problem reported in that bug doesn't look like a bug to me.
I think it was working as intended in NTPv4. The current behavior is
a regression towards NTPv3.
--
Miroslav Lichvar
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

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

Hello Miroslav, Harlan, Jakob, and everyone,

Thank you for your responses and clarifications =E2=80=94 and apologies aga=
in for
the delay in getting back to you.

Miroslav, I=E2=80=99ve noted your explanation as well as the reference to R=
FC 5905,
section 10, and I understand now that this is not a bug.

I just wanted to make sure that the behavior is intentional and that we haven=E2=80=99t overlooked an uncontrolled or unexpected behavior.

Wishing you all a great day, and thanks again for your insights.

Best Regards,
Samir

Le mar. 1 juil. 2025 =C3=A0 13:00, Miroslav Lichvar <questions@lists.ntp.or=

a

=C3=A9crit :

On 2025-07-01, Harlan Stenn via questions Mailing List <questions@lists.ntp.org> wrote:

The NTP algorithms do ongoing evaluations of established associations.

If an association becomes non-responsive, it auto-degrades.

At some point the association will drop.

Dave Mills was, to the best of my recollection, very hesitant to throw
out an established association "too soon".

Yes, what is reported in this thread as observed behavior of 4.2.8p15
and 4.2.8p18 both sound wrong to me. NTPv4 servers are not supposed to
claim they are unsynchronized (switch to stratum 16) when they lose a
working association (it doesn't matter if it's a refclock or NTP server/peer). Quoting from RFC 5905 section 10:

It is important to note that, unlike NTPv3, NTPv4 associations do not
show a timeout condition by setting the stratum to 16 and leap
indicator to 3. The association variables retain the values
determined upon arrival of the last packet. In NTPv4, lambda
increases with time, so eventually the synchronization distance
exceeds the distance threshold MAXDIST, in which case the association
is considered unfit for synchronization.

It seems this changed between 4.2.8p14 and 4.2.8p15 as a result of
fixing this bug:
https://bugs.ntp.org/show_bug.cgi?id=3D3644

The problem reported in that bug doesn't look like a bug to me.
I think it was working as intended in NTPv4. The current behavior is
a regression towards NTPv3.

--
Miroslav Lichvar

--=20

*Cordialement,*
*Samir MOUHOUNE*

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

<div dir=3D"ltr"><p>Hello Miroslav, Harlan, Jakob, and everyone,</p>
<p>Thank you for your responses and clarifications =E2=80=94 and apologies = again for the delay in getting back to you.</p>
<p>Miroslav, I=E2=80=99ve noted your explanation as well as the reference t=
o RFC 5905, section 10, and I understand now that this is not a bug.</p>
<p>I just wanted to make sure that the behavior is intentional and that we = haven=E2=80=99t overlooked an uncontrolled or unexpected behavior.</p> <p>Wishing you all a great day, and thanks again for your insights.<br><br>= Best Regards,<br>Samir</p></div><br><div class=3D"gmail_quote gmail_quote_c= ontainer"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0mar. 1 juil. 2025 = =C3=A0=C2=A013:00, Miroslav Lichvar &lt;<a href=3D"mailto:questions@lists.n= tp.org">questions@lists.ntp.org</a>&gt; a =C3=A9crit=C2=A0:<br></div><block= quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex">On 2025-07-01, Harlan Stenn via=
questions Mailing List<br>
&lt;<a href=3D"mailto:questions@lists.ntp.org" target=3D"_blank">questions@= lists.ntp.org</a>&gt; wrote:<br>
&gt; The NTP algorithms do ongoing evaluations of established associations.=

&gt;<br>
&gt; If an association becomes non-responsive, it auto-degrades.<br>
&gt;<br>
&gt; At some point the association will drop.<br>
&gt;<br>
&gt; Dave Mills was, to the best of my recollection, very hesitant to throw=

&gt; out an established association &quot;too soon&quot;.<br>

Yes, what is reported in this thread as observed behavior of 4.2.8p15<br>
and 4.2.8p18 both sound wrong to me. NTPv4 servers are not supposed to<br> claim they are unsynchronized (switch to stratum 16) when they lose a<br> working association (it doesn&#39;t matter if it&#39;s a refclock or NTP<br=

server/peer). Quoting from RFC 5905 section 10:<br>

=C2=A0 =C2=A0It is important to note that, unlike NTPv3, NTPv4 associations=
do not<br>
=C2=A0 =C2=A0show a timeout condition by setting the stratum to 16 and leap=

=C2=A0 =C2=A0indicator to 3.=C2=A0 The association variables retain the val= ues<br>
=C2=A0 =C2=A0determined upon arrival of the last packet.=C2=A0 In NTPv4, la= mbda<br>
=C2=A0 =C2=A0increases with time, so eventually the synchronization distanc= e<br>
=C2=A0 =C2=A0exceeds the distance threshold MAXDIST, in which case the asso= ciation<br>
=C2=A0 =C2=A0is considered unfit for synchronization.<br>

It seems this changed between 4.2.8p14 and 4.2.8p15 as a result of<br>
fixing this bug:<br>
<a href=3D"https://bugs.ntp.org/show_bug.cgi?id=3D3644" rel=3D"noreferrer" = target=3D"_blank">https://bugs.ntp.org/show_bug.cgi?id=3D3644</a><br>

The problem reported in that bug doesn&#39;t look like a bug to me.<br>
I think it was working as intended in NTPv4. The current behavior is<br>
a regression towards NTPv3.<br>

-- <br>
Miroslav Lichvar<br>

</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"><div dir=3D"ltr"><div><b><font size=3D"2"><i><span style=3D"font-= family:&quot;arial black&quot;,sans-serif">Cordialement,<br></span></i></fo= nt></b></div><b><font size=3D"2"><i><span style=3D"font-family:&quot;arial = black&quot;,sans-serif">Samir MOUHOUNE</span></i></font></b><br></div></div=


--000000000000f30f2e0638de30f9--

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

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

On Tue, Jul 1, 2025 at 11:00=E2=80=AFUTC Miroslav Lichvar <questions@lists.= ntp.org>
wrote:

On 2025-07-01, Harlan Stenn via questions Mailing List <questions@lists.ntp.org> wrote:

The NTP algorithms do ongoing evaluations of established associations.

If an association becomes non-responsive, it auto-degrades.

At some point the association will drop.

Dave Mills was, to the best of my recollection, very hesitant to throw
out an established association "too soon".

Yes, what is reported in this thread as observed behavior of 4.2.8p15
and 4.2.8p18 both sound wrong to me. NTPv4 servers are not supposed to
claim they are unsynchronized (switch to stratum 16) when they lose a
working association (it doesn't matter if it's a refclock or NTP server/peer). Quoting from RFC 5905 section 10:

It is important to note that, unlike NTPv3, NTPv4 associations do not
show a timeout condition by setting the stratum to 16 and leap
indicator to 3. The association variables retain the values
determined upon arrival of the last packet. In NTPv4, lambda
increases with time, so eventually the synchronization distance
exceeds the distance threshold MAXDIST, in which case the association
is considered unfit for synchronization.

Thanks to both Harlan and Miroslav for excellent commentary and context. I
do wonder if we're confusing how NTPv4 treats its upstream associations
with how it sets its own system variables for its clients to see.

It seems this changed between 4.2.8p14 and 4.2.8p15 as a result of
fixing this bug:
https://bugs.ntp.org/show_bug.cgi?id=3D3644

The problem reported in that bug doesn't look like a bug to me.
I think it was working as intended in NTPv4. The current behavior is
a regression towards NTPv3.

Given 3644 is a report by Ulrich handled by J=C3=BCrgen, I'd love to have t= heir
thoughts as well.

Cheers,
Dave Hart

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

<div dir=3D"ltr"><div dir=3D"ltr"><div><div class=3D"gmail_default" style= =3D"font-family:&quot;trebuchet ms&quot;,sans-serif"></div></div></div><br>= <div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"= gmail_attr">On Tue, Jul 1, 2025 at 11:00=E2=80=AF<span class=3D"gmail_defau= lt" style=3D"font-family:&quot;trebuchet ms&quot;,sans-serif"></span>U<span=
class=3D"gmail_default" style=3D"font-family:&quot;trebuchet ms&quot;,sans= -serif">TC</span> Miroslav Lichvar &lt;<a href=3D"mailto:questions@lists.nt= p.org">questions@lists.ntp.org</a>&gt; wrote:<br></div><blockquote class=3D= "gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2= 04,204,204);padding-left:1ex">On 2025-07-01, Harlan Stenn via questions Mai= ling List<br>
&lt;<a href=3D"mailto:questions@lists.ntp.org" target=3D"_blank">questions@= lists.ntp.org</a>&gt; wrote:<br>
&gt; The NTP algorithms do ongoing evaluations of established associations.=

&gt;<br>
&gt; If an association becomes non-responsive, it auto-degrades.<br>
&gt;<br>
&gt; At some point the association will drop.<br>
&gt;<br>
&gt; Dave Mills was, to the best of my recollection, very hesitant to throw=

&gt; out an established association &quot;too soon&quot;.<br>

Yes, what is reported in this thread as observed behavior of 4.2.8p15<br>
and 4.2.8p18 both sound wrong to me. NTPv4 servers are not supposed to<br> claim they are unsynchronized (switch to stratum 16) when they lose a<br> working association (it doesn&#39;t matter if it&#39;s a refclock or NTP<br=

server/peer). Quoting from RFC 5905 section 10:<br>

=C2=A0 =C2=A0It is important to note that, unlike NTPv3, NTPv4 associations=
do not<br>
=C2=A0 =C2=A0show a timeout condition by setting the stratum to 16 and leap=

=C2=A0 =C2=A0indicator to 3.=C2=A0 The association variables retain the val= ues<br>
=C2=A0 =C2=A0determined upon arrival of the last packet.=C2=A0 In NTPv4, la= mbda<br>
=C2=A0 =C2=A0increases with time, so eventually the synchronization distanc= e<br>
=C2=A0 =C2=A0exceeds the distance threshold MAXDIST, in which case the asso= ciation<br>
=C2=A0 =C2=A0is considered unfit for synchronization.<br></blockquote><div>= <br></div><div><div class=3D"gmail_default" style=3D"font-family:&quot;treb= uchet ms&quot;,sans-serif">Thanks to both Harlan and Miroslav for excellent=
commentary and context.=C2=A0 I do wonder if we&#39;re confusing how NTPv4=
treats its upstream associations with how it sets its own system variables=
for its clients to see.</div></div><div>=C2=A0</div><blockquote class=3D"g= mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204= ,204,204);padding-left:1ex">It seems this changed between 4.2.8p14 and 4.2.= 8p15 as a result of<br>
fixing this bug:<br>
<a href=3D"https://bugs.ntp.org/show_bug.cgi?id=3D3644" rel=3D"noreferrer" = target=3D"_blank">https://bugs.ntp.org/show_bug.cgi?id=3D3644</a><br>

The problem reported in that bug doesn&#39;t look like a bug to me.<br>
I think it was working as intended in NTPv4. The current behavior is<br>
a regression towards NTPv3.</blockquote><div><br></div><div class=3D"gmail_= default" style=3D"font-family:&quot;trebuchet ms&quot;,sans-serif">Given 36=
44 is a report by Ulrich handled by J=C3=BCrgen, I&#39;d love to have their=
thoughts as well.<span style=3D"font-family:Arial,Helvetica,sans-serif">= =C2=A0</span></div><div><div dir=3D"ltr" class=3D"gmail_signature"><div dir= =3D"ltr"><div><font face=3D"tahoma, sans-serif" color=3D"#666666"><br></fon= t></div><font face=3D"tahoma, sans-serif" color=3D"#666666">Cheers,<br>Dave=
Hart</font></div></div></div><br class=3D"gmail-Apple-interchange-newline"= ></div></div>

--0000000000003f04ad0638e1ed8b--

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

--_000_f5ff0fc9703e414b999c5845039667faukrde_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQpGcm9tOiBEYXZlIEhhcnQgPGRhdmVoYXJ0QGdtYWlsLmNvbT4NClNlbnQ6IFR1ZXNkYXksIEp1 bHkgMSwgMjAyNSA4OjAxIFBNDQpUbzogTWlyb3NsYXYgTGljaHZhciA8bWxpY2h2YXJAcmVkaGF0 LmNvbT4NCkNjOiBxdWVzdGlvbnNAbGlzdHMubnRwLm9yZzsgSsO8cmdlbiBQZXJsaW5nZXIgPGp1 ZXJnZW4ucGVybGluZ2VyQHQtb25saW5lLmRlPjsgV2luZGwsIFVscmljaCA8dS53aW5kbEB1a3Iu ZGU+OyBKw7xyZ2VuIFBlcmxpbmdlciA8cGVybGluZ2VyQG50cC5vcmc+OyBXaW5kbCwgVWxyaWNo IDx3aW5kbEBudHAub3JnPg0KU3ViamVjdDogW0VYVF0gUmU6IERlbGF5IGluIFN3aXRjaGluZyB0 byBTdHJhdHVtIDE2IEFmdGVyIExvY2FsIFJlZmVyZW5jZSBMb3NzIG9uIG50cGQgNC4yLjhwMTgN Cg0KT24gVHVlLCBKdWwgMSwgMjAyNSBhdCAxMTowMOKAr1VUQyBNaXJvc2xhdiBMaWNodmFyIDxx dWVzdGlvbnNAbGlzdHMubnRwLm9yZzxtYWlsdG86cXVlc3Rpb25zQGxpc3RzLm50cC5vcmc+PiB3 cm90ZToNCk9uIDIwMjUtMDctMDEsIEhhcmxhbiBTdGVubiB2aWEgcXVlc3Rpb25zIE1haWxpbmcg TGlzdA0KPHF1ZXN0aW9uc0BsaXN0cy5udHAub3JnPG1haWx0bzpxdWVzdGlvbnNAbGlzdHMubnRw Lm9yZz4+IHdyb3RlOg0KPiBUaGUgTlRQIGFsZ29yaXRobXMgZG8gb25nb2luZyBldmFsdWF0aW9u cyBvZiBlc3RhYmxpc2hlZCBhc3NvY2lhdGlvbnMuDQo+DQo+IElmIGFuIGFzc29jaWF0aW9uIGJl Y29tZXMgbm9uLXJlc3BvbnNpdmUsIGl0IGF1dG8tZGVncmFkZXMuDQo+DQo+IEF0IHNvbWUgcG9p bnQgdGhlIGFzc29jaWF0aW9uIHdpbGwgZHJvcC4NCj4NCj4gRGF2ZSBNaWxscyB3YXMsIHRvIHRo ZSBiZXN0IG9mIG15IHJlY29sbGVjdGlvbiwgdmVyeSBoZXNpdGFudCB0byB0aHJvdw0KPiBvdXQg YW4gZXN0YWJsaXNoZWQgYXNzb2NpYXRpb24gInRvbyBzb29uIi4NCg0KWWVzLCB3aGF0IGlzIHJl cG9ydGVkIGluIHRoaXMgdGhyZWFkIGFzIG9ic2VydmVkIGJlaGF2aW9yIG9mIDQuMi44cDE1DQph bmQgNC4yLjhwMTggYm90aCBzb3VuZCB3cm9uZyB0byBtZS4gTlRQdjQgc2VydmVycyBhcmUgbm90 IHN1cHBvc2VkIHRvDQpjbGFpbSB0aGV5IGFyZSB1bnN5bmNocm9uaXplZCAoc3dpdGNoIHRvIHN0 cmF0dW0gMTYpIHdoZW4gdGhleSBsb3NlIGENCndvcmtpbmcgYXNzb2NpYXRpb24gKGl0IGRvZXNu J3QgbWF0dGVyIGlmIGl0J3MgYSByZWZjbG9jayBvciBOVFANCnNlcnZlci9wZWVyKS4gUXVvdGlu ZyBmcm9tIFJGQyA1OTA1IHNlY3Rpb24gMTA6DQoNCiAgIEl0IGlzIGltcG9ydGFudCB0byBub3Rl IHRoYXQsIHVubGlrZSBOVFB2MywgTlRQdjQgYXNzb2NpYXRpb25zIGRvIG5vdA0KICAgc2hvdyBh IHRpbWVvdXQgY29uZGl0aW9uIGJ5IHNldHRpbmcgdGhlIHN0cmF0dW0gdG8gMTYgYW5kIGxlYXAN CiAgIGluZGljYXRvciB0byAzLiAgVGhlIGFzc29jaWF0aW9uIHZhcmlhYmxlcyByZXRhaW4gdGhl IHZhbHVlcw0KICAgZGV0ZXJtaW5lZCB1cG9uIGFycml2YWwgb2YgdGhlIGxhc3QgcGFja2V0LiAg SW4gTlRQdjQsIGxhbWJkYQ0KICAgaW5jcmVhc2VzIHdpdGggdGltZSwgc28gZXZlbnR1YWxseSB0 aGUgc3luY2hyb25pemF0aW9uIGRpc3RhbmNlDQogICBleGNlZWRzIHRoZSBkaXN0YW5jZSB0aHJl c2hvbGQgTUFYRElTVCwgaW4gd2hpY2ggY2FzZSB0aGUgYXNzb2NpYXRpb24NCiAgIGlzIGNvbnNp ZGVyZWQgdW5maXQgZm9yIHN5bmNocm9uaXphdGlvbi4NCg0KVGhhbmtzIHRvIGJvdGggSGFybGFu IGFuZCBNaXJvc2xhdiBmb3IgZXhjZWxsZW50IGNvbW1lbnRhcnkgYW5kIGNvbnRleHQuICBJIGRv IHdvbmRlciBpZiB3ZSdyZSBjb25mdXNpbmcgaG93IE5UUHY0IHRyZWF0cyBpdHMgdXBzdHJlYW0g YXNzb2NpYXRpb25zIHdpdGggaG93IGl0IHNldHMgaXRzIG93biBzeXN0ZW0gdmFyaWFibGVzIGZv ciBpdHMgY2xpZW50cyB0byBzZWUuDQoNCkl0IHNlZW1zIHRoaXMgY2hhbmdlZCBiZXR3ZWVuIDQu Mi44cDE0IGFuZCA0LjIuOHAxNSBhcyBhIHJlc3VsdCBvZg0KZml4aW5nIHRoaXMgYnVnOg0KaHR0 cHM6Ly9idWdzLm50cC5vcmcvc2hvd19idWcuY2dpP2lkPTM2NDQNCg0KVGhlIHByb2JsZW0gcmVw b3J0ZWQgaW4gdGhhdCBidWcgZG9lc24ndCBsb29rIGxpa2UgYSBidWcgdG8gbWUuDQpJIHRoaW5r IGl0IHdhcyB3b3JraW5nIGFzIGludGVuZGVkIGluIE5UUHY0LiBUaGUgY3VycmVudCBiZWhhdmlv ciBpcw0KYSByZWdyZXNzaW9uIHRvd2FyZHMgTlRQdjMuDQoNCkdpdmVuIDM2NDQgaXMgYSByZXBv cnQgYnkgVWxyaWNoIGhhbmRsZWQgYnkgSsO8cmdlbiwgSSdkIGxvdmUgdG8gaGF2ZSB0aGVpciB0 aG91Z2h0cyBhcyB3ZWxsLg0KDQpDaGVlcnMsDQpEYXZlIEhhcnQNCg0KW1dpbmRsLCBVbHJpY2hd DQoNCkFjdHVhbGx5LCBJIGhhZCBjb21wbGV0ZWx5IGZvcmdvdHRlbiBhYm91dCB0aGF0IGlzc3Vl LiBSZWFkaW5nIGl0IGFnYWluLCBpdCBzZWVtcyBzdHJhdHVtIHNob3VsZCBiZSAxNiBpZiBhbGwg c291cmNlcyBhcmUgdW5yZWFjaGFibGUgKGxvc3QpLg0KVGhhdCBzZWVtcyBpbmRlcGVuZGVudCBm cm9tIG1heGRpc3QuIEhvd2V2ZXIgdXNpbmcgYSBoaWdoLXF1YWxpdHkgb3NjaWxsYXRvciwgc29t ZW9uZSAobGlpZSBNZWluYmVyZykgY291bGQgbGlrZSB0byBjb250aW51ZSB0byBzZXJ2ZSB0aW1l IGV2ZW4gaWYgYWxsIHJlZmVyZW5jZXMgYXJlIGRvd24uDQpJdCBzZWVtcyB0aGF0IGNhc2Ugd2Fz buKAmXQgYWN0dWFsbHkgaGFuZGxlZCBpbiB0aGUgUkZDLCBidXQgd2FzIHBvc3NpYmxlIGluIHRo ZSBpbXBsZW1lbnRhdGlvbiAoQUZBSUspLg0KDQpLaW5kIHJlZ2FyZHMsDQpVbHJpY2ggV2luZGwN Cg0K

--_000_f5ff0fc9703e414b999c5845039667faukrde_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiVHJlYnVjaGV0IE1T IjsNCglwYW5vc2UtMToyIDExIDYgMyAyIDIgMiAyIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9u cyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46 MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7 bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h cmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl ZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0Kc3Bhbi5nbWFpbGRlZmF1bHQNCgl7bXNvLXN0eWxlLW5hbWU6Z21haWxfZGVmYXVs dDt9DQpzcGFuLkUtTWFpbEZvcm1hdHZvcmxhZ2UyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0 OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn aW46NzAuODVwdCA3MC44NXB0IDIuMGNtIDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJERSIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0 LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj RTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+RnJvbTo8L2I+IERhdmUgSGFydCAmbHQ7ZGF2ZWhhcnRAZ21haWwuY29tJmd0OyA8 YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVseSAxLCAyMDI1IDg6MDEgUE08YnI+DQo8Yj5U bzo8L2I+IE1pcm9zbGF2IExpY2h2YXIgJmx0O21saWNodmFyQHJlZGhhdC5jb20mZ3Q7PGJyPg0K PGI+Q2M6PC9iPiBxdWVzdGlvbnNAbGlzdHMubnRwLm9yZzsgSsO8cmdlbiBQZXJsaW5nZXIgJmx0 O2p1ZXJnZW4ucGVybGluZ2VyQHQtb25saW5lLmRlJmd0OzsgV2luZGwsIFVscmljaCAmbHQ7dS53 aW5kbEB1a3IuZGUmZ3Q7OyBKw7xyZ2VuIFBlcmxpbmdlciAmbHQ7cGVybGluZ2VyQG50cC5vcmcm Z3Q7OyBXaW5kbCwgVWxyaWNoICZsdDt3aW5kbEBudHAub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6 PC9iPiBbRVhUXSBSZTogRGVsYXkgaW4gU3dpdGNoaW5nIHRvIFN0cmF0dW0gMTYgQWZ0ZXIgTG9j YWwgUmVmZXJlbmNlIExvc3Mgb24gbnRwZCA0LjIuOHAxODxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi Pk9uIFR1ZSwgSnVsIDEsIDIwMjUgYXQgMTE6MDDigK9VPC9zcGFuPjxzcGFuIGNsYXNzPSJnbWFp bGRlZmF1bHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJl YnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWYiPlRDPC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+IE1pcm9zbGF2IExpY2h2YXIgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86cXVlc3Rp b25zQGxpc3RzLm50cC5vcmciPjxzcGFuIGxhbmc9IkVOLVVTIj5xdWVzdGlvbnNAbGlzdHMubnRw Lm9yZzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsNCiB3cm90ZTo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biAyMDI1LTA3LTAxLCBIYXJsYW4gU3Rlbm4gdmlhIHF1ZXN0aW9ucyBNYWlsaW5nIExpc3Q8YnI+ DQombHQ7PGEgaHJlZj0ibWFpbHRvOnF1ZXN0aW9uc0BsaXN0cy5udHAub3JnIiB0YXJnZXQ9Il9i bGFuayI+cXVlc3Rpb25zQGxpc3RzLm50cC5vcmc8L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IFRo ZSBOVFAgYWxnb3JpdGhtcyBkbyBvbmdvaW5nIGV2YWx1YXRpb25zIG9mIGVzdGFibGlzaGVkIGFz c29jaWF0aW9ucy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJZiBhbiBhc3NvY2lhdGlvbiBiZWNvbWVz IG5vbi1yZXNwb25zaXZlLCBpdCBhdXRvLWRlZ3JhZGVzLjxicj4NCiZndDs8YnI+DQomZ3Q7IEF0 IHNvbWUgcG9pbnQgdGhlIGFzc29jaWF0aW9uIHdpbGwgZHJvcC48YnI+DQomZ3Q7PGJyPg0KJmd0 OyBEYXZlIE1pbGxzIHdhcywgdG8gdGhlIGJlc3Qgb2YgbXkgcmVjb2xsZWN0aW9uLCB2ZXJ5IGhl c2l0YW50IHRvIHRocm93IDxicj4NCiZndDsgb3V0IGFuIGVzdGFibGlzaGVkIGFzc29jaWF0aW9u ICZxdW90O3RvbyBzb29uJnF1b3Q7Ljxicj4NCjxicj4NClllcywgd2hhdCBpcyByZXBvcnRlZCBp biB0aGlzIHRocmVhZCBhcyBvYnNlcnZlZCBiZWhhdmlvciBvZiA0LjIuOHAxNTxicj4NCmFuZCA0 LjIuOHAxOCBib3RoIHNvdW5kIHdyb25nIHRvIG1lLiBOVFB2NCBzZXJ2ZXJzIGFyZSBub3Qgc3Vw cG9zZWQgdG88YnI+DQpjbGFpbSB0aGV5IGFyZSB1bnN5bmNocm9uaXplZCAoc3dpdGNoIHRvIHN0 cmF0dW0gMTYpIHdoZW4gdGhleSBsb3NlIGE8YnI+DQp3b3JraW5nIGFzc29jaWF0aW9uIChpdCBk b2Vzbid0IG1hdHRlciBpZiBpdCdzIGEgcmVmY2xvY2sgb3IgTlRQPGJyPg0Kc2VydmVyL3BlZXIp LiBRdW90aW5nIGZyb20gUkZDIDU5MDUgc2VjdGlvbiAxMDo8YnI+DQo8YnI+DQombmJzcDsgJm5i c3A7SXQgaXMgaW1wb3J0YW50IHRvIG5vdGUgdGhhdCwgdW5saWtlIE5UUHYzLCBOVFB2NCBhc3Nv Y2lhdGlvbnMgZG8gbm90PGJyPg0KJm5ic3A7ICZuYnNwO3Nob3cgYSB0aW1lb3V0IGNvbmRpdGlv biBieSBzZXR0aW5nIHRoZSBzdHJhdHVtIHRvIDE2IGFuZCBsZWFwPGJyPg0KJm5ic3A7ICZuYnNw O2luZGljYXRvciB0byAzLiZuYnNwOyBUaGUgYXNzb2NpYXRpb24gdmFyaWFibGVzIHJldGFpbiB0 aGUgdmFsdWVzPGJyPg0KJm5ic3A7ICZuYnNwO2RldGVybWluZWQgdXBvbiBhcnJpdmFsIG9mIHRo ZSBsYXN0IHBhY2tldC4mbmJzcDsgSW4gTlRQdjQsIGxhbWJkYTxicj4NCiZuYnNwOyAmbmJzcDtp bmNyZWFzZXMgd2l0aCB0aW1lLCBzbyBldmVudHVhbGx5IHRoZSBzeW5jaHJvbml6YXRpb24gZGlz dGFuY2U8YnI+DQombmJzcDsgJm5ic3A7ZXhjZWVkcyB0aGUgZGlzdGFuY2UgdGhyZXNob2xkIE1B WERJU1QsIGluIHdoaWNoIGNhc2UgdGhlIGFzc29jaWF0aW9uPGJyPg0KJm5ic3A7ICZuYnNwO2lz IGNvbnNpZGVyZWQgdW5maXQgZm9yIHN5bmNocm9uaXphdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWYiPlRo YW5rcyB0byBib3RoIEhhcmxhbiBhbmQgTWlyb3NsYXYgZm9yIGV4Y2VsbGVudCBjb21tZW50YXJ5 IGFuZCBjb250ZXh0LiZuYnNwOyBJIGRvIHdvbmRlciBpZiB3ZSdyZSBjb25mdXNpbmcgaG93IE5U UHY0IHRyZWF0cyBpdHMgdXBzdHJlYW0gYXNzb2NpYXRpb25zIHdpdGggaG93IGl0IHNldHMgaXRz IG93biBzeXN0ZW0gdmFyaWFibGVzDQogZm9yIGl0cyBjbGllbnRzIHRvIHNlZS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SXQgc2VlbXMgdGhpcyBjaGFuZ2VkIGJldHdlZW4gNC4yLjhwMTQgYW5kIDQuMi44 cDE1IGFzIGEgcmVzdWx0IG9mPGJyPg0KZml4aW5nIHRoaXMgYnVnOjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vYnVncy5udHAub3JnL3Nob3dfYnVnLmNnaT9pZD0zNjQ0IiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly9idWdzLm50cC5vcmcvc2hvd19idWcuY2dpP2lkPTM2NDQ8L2E+PGJyPg0KPGJyPg0K VGhlIHByb2JsZW0gcmVwb3J0ZWQgaW4gdGhhdCBidWcgZG9lc24ndCBsb29rIGxpa2UgYSBidWcg dG8gbWUuPGJyPg0KSSB0aGluayBpdCB3YXMgd29ya2luZyBhcyBpbnRlbmRlZCBpbiBOVFB2NC4g VGhlIGN1cnJlbnQgYmVoYXZpb3IgaXM8YnI+DQphIHJlZ3Jlc3Npb24gdG93YXJkcyBOVFB2My48 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fu cy1zZXJpZiI+R2l2ZW4gMzY0NCBpcyBhIHJlcG9ydCBieSBVbHJpY2ggaGFuZGxlZCBieSBKw7xy Z2VuLCBJJ2QgbG92ZSB0byBoYXZlIHRoZWlyIHRob3VnaHRzIGFzIHdlbGwuPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPkNoZWVycyw8YnI+DQpE YXZlIEhhcnQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPltXaW5kbCwgVWxyaWNoXSA8bzpwPjwvbzpwPjwvc3Bhbj48L2k+ PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkFjdHVhbGx5LCBJIGhhZCBjb21wbGV0 ZWx5IGZvcmdvdHRlbiBhYm91dCB0aGF0IGlzc3VlLiBSZWFkaW5nIGl0IGFnYWluLCBpdCBzZWVt cyBzdHJhdHVtIHNob3VsZCBiZSAxNiBpZiBhbGwgc291cmNlcyBhcmUgdW5yZWFjaGFibGUgKGxv c3QpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+VGhhdCBzZWVtcyBpbmRlcGVuZGVudCBmcm9tIG1heGRpc3QuIEhvd2V2ZXIgdXNpbmcgYSBo aWdoLXF1YWxpdHkgb3NjaWxsYXRvciwgc29tZW9uZSAobGlpZSBNZWluYmVyZykgY291bGQgbGlr ZSB0byBjb250aW51ZSB0byBzZXJ2ZSB0aW1lIGV2ZW4gaWYgYWxsIHJlZmVyZW5jZXMgYXJlIGRv d24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5JdCBzZWVtcyB0aGF0IGNhc2Ugd2FzbuKAmXQgYWN0dWFsbHkgaGFuZGxlZCBpbiB0aGUgUkZD LCBidXQgd2FzIHBvc3NpYmxlIGluIHRoZSBpbXBsZW1lbnRhdGlvbiAoQUZBSUspLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iY29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5LaW5k IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj5VbHJpY2ggV2luZGw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K

--_000_f5ff0fc9703e414b999c5845039667faukrde_--

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

Miroslav,

from the RFC citations found in the bug report it seems to be specified differently, or I misunderstood.

Kind regards,
Ulrich Windl

-----Original Message-----
From: Miroslav Lichvar <mlichvar@redhat.com>
Sent: Wednesday, July 2, 2025 11:42 AM
To: Windl, Ulrich <u.windl@ukr.de>
Cc: Dave Hart <davehart@gmail.com>; questions@lists.ntp.org; Jürgen Perlinger <juergen.perlinger@t-online.de>; Jürgen Perlinger <perlinger@ntp.org>; Windl, Ulrich <windl@ntp.org>
Subject: [EXT] Re: Re: Delay in Switching to Stratum 16 After Local Reference Loss on ntpd 4.2.8p18

Sicherheits-Hinweis: Diese E-Mail wurde von einer Person außerhalb des
UKR gesendet. Seien Sie vorsichtig vor gefälschten Absendern, wenn Sie auf Links klicken, Anhänge öffnen oder weitere Aktionen ausführen, bevor Sie die Echtheit überprüft haben.

On Wed, Jul 02, 2025 at 09:23:12AM +0000, Windl, Ulrich wrote:

Actually, I had completely forgotten about that issue. Reading it again, it

seems stratum should be 16 if all sources are unreachable (lost).

Why should it do that?

The idea in NTPv4 is that the decision if a source is acceptable
should be made on the client side. If a server loses all time sources,
its root dispersion will grow (15 ppm by default). If a client of that
server has other sources, it can reselect when the distance becomes
larger than that of the other sources.

If the server quickly switches to the unsynchronized state (as recent
ntpd versions seem to be doing), the client can no longer synchronize
to it, even if it has no other sources available. If there are
multiple clients of that server, their clocks will not stay in sync,
each will be drifting on its own.

--
Miroslav Lichvar

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

On Wed, Jul 02, 2025 at 09:23:12AM +0000, Windl, Ulrich wrote:

Actually, I had completely forgotten about that issue. Reading it again, it seems stratum should be 16 if all sources are unreachable (lost).

Why should it do that?

The idea in NTPv4 is that the decision if a source is acceptable
should be made on the client side. If a server loses all time sources,
its root dispersion will grow (15 ppm by default). If a client of that
server has other sources, it can reselect when the distance becomes
larger than that of the other sources.

If the server quickly switches to the unsynchronized state (as recent
ntpd versions seem to be doing), the client can no longer synchronize
to it, even if it has no other sources available. If there are
multiple clients of that server, their clocks will not stay in sync,
each will be drifting on its own.
--
Miroslav Lichvar

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

On Wed, Jul 02, 2025 at 09:50:37AM +0000, Windl, Ulrich wrote:

Miroslav,

from the RFC citations found in the bug report it seems to be specified differently, or I misunderstood.

If you are referring to the Figure 24 of RFC 5905, which has "return
(UNSYNC)" for this path, there doesn't seem to be anything suggesting
that should be handled by resetting the clock to an unsynchronized
state.

The clock_select() function in A.5.5.1 doesn't have a return value and
in this case when no usable sources are present it doesn't do
anything, it just returns.

/*
* There must be at least NSANE survivors to satisfy the
* correctness assertions. Ordinarily, the Byzantine criteria
* require four survivors, but for the demonstration here, one
* is acceptable.
*/
if (s.n < NSANE)
return;
--
Miroslav Lichvar

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

Well,

We could start a discussion what "UNSYNC" really means:
Does it mean the clock is free-running (not updated by the clock discipline), or does it mean the clock's estimated offset is "just terrible" (like 16 seconds)?
With the former definitions it's likely that an issue is discovered earlier by monitoring IMHO.
I think an UNSYNC clock could still provide an estimated an maximum error.

Kind regards,
Ulrich Windl

-----Original Message-----
From: Miroslav Lichvar <mlichvar@redhat.com>
Sent: Wednesday, July 2, 2025 4:55 PM
To: Windl, Ulrich <u.windl@ukr.de>
Cc: Dave Hart <davehart@gmail.com>; questions@lists.ntp.org; Jürgen Perlinger <juergen.perlinger@t-online.de>; Jürgen Perlinger <perlinger@ntp.org>; Windl, Ulrich <windl@ntp.org>
Subject: [EXT] Re: Re: Re: Delay in Switching to Stratum 16 After Local Reference Loss on ntpd 4.2.8p18

On Wed, Jul 02, 2025 at 09:50:37AM +0000, Windl, Ulrich wrote:

Miroslav,

from the RFC citations found in the bug report it seems to be specified

differently, or I misunderstood.

If you are referring to the Figure 24 of RFC 5905, which has "return (UNSYNC)" for this path, there doesn't seem to be anything suggesting
that should be handled by resetting the clock to an unsynchronized
state.

The clock_select() function in A.5.5.1 doesn't have a return value and
in this case when no usable sources are present it doesn't do
anything, it just returns.

/*
* There must be at least NSANE survivors to satisfy the
* correctness assertions. Ordinarily, the Byzantine criteria
* require four survivors, but for the demonstration here, one
* is acceptable.
*/
if (s.n < NSANE)
return;

--
Miroslav Lichvar

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

On Fri, Jul 04, 2025 at 06:54:13AM +0000, Windl, Ulrich wrote:

Well,

We could start a discussion what "UNSYNC" really means:
Does it mean the clock is free-running (not updated by the clock discipline), or does it mean the clock's estimated offset is "just terrible" (like 16 seconds)?

I think in the context of the clock_select() function it means there
is no source selected and the clock cannot be updated. The selection
itself doesn't change the status of the clock. If it was previously
considered to be synchronized, it will still be synchronized.

With the former definitions it's likely that an issue is discovered earlier by monitoring IMHO.

The monitoring can check the reachability directly and discover the
issue even sooner, no need to wait for the orphan timeout to activate
after the source becomes unreachable.
--
Miroslav Lichvar

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

Hi!

Well things seems a bit more complex:
The kernel clock has a clock state, too: Initially after boot it is unsynchronized, but when NTP updates the clock, it will be set to synchronizes, together with a few more parameters.
When the maximum error (the kernel clock advances automatically) reaches a threshold, the clock is set to unsynchronized again. So even if NTP crashes, the kernel clock may indicate a synchronized status for some time.
In contrast when NTP is considering itself UNSNC, will it set the kernel clock to unsynchronized immediately, or will it just stop sending updates to the kernel clock?
As I understood the discussion so far, the latter is the case.
What's not quite clear at the moment is whether NTP ever reads back the values provided from the kernel clock.

Traditionally NTP was assumed to know everything about the kernel clock, but maybe today the kernel clock knows its properties better than a generic NTP will, right?
So I think the interface between the NTP clock model and the kernel clock should be explained a bit better in the upcoming specification.
As I understand it , the NTP kernel clock model is optional, still.

Kind regards,
Ulrich Windl

-----Original Message-----
From: Miroslav Lichvar <mlichvar@redhat.com>
Sent: Monday, July 7, 2025 11:34 AM
To: Windl, Ulrich <u.windl@ukr.de>
Cc: Dave Hart <davehart@gmail.com>; questions@lists.ntp.org; Jürgen Perlinger <juergen.perlinger@t-online.de>; Jürgen Perlinger <perlinger@ntp.org>; Windl, Ulrich <windl@ntp.org>
Subject: [EXT] Re: Re: Re: Re: Delay in Switching to Stratum 16 After Local Reference Loss on ntpd 4.2.8p18

Sicherheits-Hinweis: Diese E-Mail wurde von einer Person außerhalb des
UKR gesendet. Seien Sie vorsichtig vor gefälschten Absendern, wenn Sie auf Links klicken, Anhänge öffnen oder weitere Aktionen ausführen, bevor Sie die Echtheit überprüft haben.

On Fri, Jul 04, 2025 at 06:54:13AM +0000, Windl, Ulrich wrote:

Well,

We could start a discussion what "UNSYNC" really means:
Does it mean the clock is free-running (not updated by the clock discipline),

or does it mean the clock's estimated offset is "just terrible" (like 16 seconds)?

I think in the context of the clock_select() function it means there
is no source selected and the clock cannot be updated. The selection
itself doesn't change the status of the clock. If it was previously considered to be synchronized, it will still be synchronized.

With the former definitions it's likely that an issue is discovered earlier by

monitoring IMHO.

The monitoring can check the reachability directly and discover the
issue even sooner, no need to wait for the orphan timeout to activate
after the source becomes unreachable.

--
Miroslav Lichvar

--- Synchronet 3.21a-Linux NewsLink 1.2