On Wed, 24 May 2023 19:23:00 -0000 (UTC), "Dave Hart"
<hart@ntp.org> wrote:

>Feedback from a helpful tester that they didn't see the removal of peers in
>their log prompts me to add that you might want to turn on logging of peer
>events in ntp.conf:
>
>logconfig +peerall

I noticed that the release version 4.2.8p15 logged when it
dropped a server the dev doesn't. I decided to what protostats
has to offer. Now I see when a server is dropped, thus:

<dropped ip address> 1315 85 restart timeout
<dropped ip address> 0012 82 demobilize assoc 63135

followed by

<new ip address> 0011 81 mobilize assoc 63139
<new ip address> 0014 84 reachable

Thus maintaining 6 servers.

Make failed on the very elderly system I'm trying the dev on
with the message that I needed to add -fPIC to CFLAGS.

HTH
--
Roger

On Wednesday, May 24, 2023 at 5:42:20 PM UTC-4, Roger wrote:
> On Wed, 24 May 2023 19:23:00 -0000 (UTC), "Dave Hart"
> <ha...@ntp.org> wrote:
>
> >Feedback from a helpful tester that they didn't see the removal of peers in
> >their log prompts me to add that you might want to turn on logging of peer
> >events in ntp.conf:
> >
> >logconfig +peerall
> I noticed that the release version 4.2.8p15 logged when it
> dropped a server the dev doesn't. I decided to what protostats
> has to offer. Now I see when a server is dropped, thus:
>
> <dropped ip address> 1315 85 restart timeout
> <dropped ip address> 0012 82 demobilize assoc 63135
>
> followed by
>
> <new ip address> 0011 81 mobilize assoc 63139
> <new ip address> 0014 84 reachable

I'm glad you found a way, but if you add +peerall (or even +allall) to you ntp.conf logconfig you should see the restart and demobilize messages in your normal syslog or ntp.log.

> Thus maintaining 6 servers.
>
> Make failed on the very elderly system I'm trying the dev on
> with the message that I needed to add -fPIC to CFLAGS.

Martin Burnicki ran into the same problem on a presumably recent Linux. Harlan Stenn has a fix for this problem. Apparently after updating sntp/libopts he forgot to do something to add those flags to the libopts tearoff build to match the rest of the package's compiler switches.

I'll try to find that workaround and get a new tarball out.

Thanks for pitching in with testing.

Cheers,
Dave Hart

On Sun, 28 May 2023 13:43:00 -0000 (UTC), "Dave Hart"
<davehart@gmail.com> wrote:

>I've posted a new tarball, but it may not appear for a few minutes. It
>should resolve the build failure you saw.
>
>https://people.nwtime.org/hart/ntp-dev-3792-msm-v2.tar.gz

Thank you. This compiles okay on my elderly system. I'm running
it with logconfig +allall for the present.
--
Roger

On 5/28/2023 6:39 AM, Dave Hart wrote:
> On Sun, 28 May 2023 at 12:25, Dave Hart <davehart@gmail.com
> <mailto:davehart@gmail.com>> wrote:
>
> On Wednesday, May 24, 2023 at 5:42:20 PM UTC-4, Roger wrote:
> > Make failed on the very elderly system I'm trying the dev on
> > with the message that I needed to add -fPIC to CFLAGS.
>
> Martin Burnicki ran into the same problem on a presumably recent
> Linux.  Harlan Stenn has a fix for this problem.  Apparently after
> updating sntp/libopts he forgot to do something to add those flags
> to the libopts tearoff build to match the rest of the package's
> compiler switches.
>
> I'll try to find that workaround and get a new tarball out.
>
>
> I've posted a new tarball, but it may not appear for a few minutes.  It
> should resolve the build failure you saw.
>
> https://people.nwtime.org/hart/ntp-dev-3792-msm-v2.tar.gz
> <https://people.nwtime.org/hart/ntp-dev-3792-msm-v2.tar.gz>
>
> Alternatively, replace the
>
> AM_CFLAGS = blah blah
>
> line in sntp/libopts/Makefile.am with:
>
> AM_CFLAGS = $(NTP_HARD_CFLAGS)

That should probably be:

AM_CFLAGS= $(NTP_HARD_CFLAGS) blah blah

The Makefile.am in this directory now uses AM_CFLAGS, as I recall.

H
--
> AM_CPPFLAGS = $(NTP_HARD_CPPFLAGS)
> AM_LDFLAGS = $(NTP_HARD_LDFLAGS)
>
> --
> Cheers,
> Dave Hart
>

--
Harlan Stenn <stenn@nwtime.org>
http://networktimefoundation.org - be a member!
--
This is questions@lists.ntp.org
Subscribe: questions+subscribe@lists.ntp.org
Unsubscribe: questions+unsubscribe@lists.ntp.org

On Sun, 28 May 2023 13:43:00 -0000 (UTC), "Dave Hart"
<davehart@gmail.com> wrote:

>I've posted a new tarball, but it may not appear for a few minutes. It
>should resolve the build failure you saw.
>
>https://people.nwtime.org/hart/ntp-dev-3792-msm-v2.tar.gz

I'm running this on my elderly system and spotted this. It was
unexpected by me but perhaps not by you. All servers at poll 10.
(Times made human readable.)

In protostats:

>10:00:50 185.83.169.27 0313 83 unreachable
>10:18:17 185.83.169.27 0014 84 reachable

From peerstats before and after the above times
(offset, delay, dispersion, jitter are all *1e3
to be human readable):

>06:27:16 185.83.169.27 135a -0.105 12.831 15.082 0.102
>07:02:51 185.83.169.27 135a +0.201 12.720 15.429 0.332
>07:38:36 185.83.169.27 145a +0.178 13.003 15.495 1.392
>10:18:17 185.83.169.27 1014 +0.196 13.226 263.647 1.646
>10:36:15 185.83.169.27 1414 +0.002 13.057 231.781 1.556
>11:11:00 185.83.169.27 1414 +0.115 13.215 223.162 1.601

Question: why wasn't this server dropped? I presume
that the reach had gone down to 0.
--
Roger

On Monday, June 19, 2023 at 11:57:31 AM UTC, Roger wrote:
> On Sun, 28 May 2023 13:43:00 -0000 (UTC), "Dave Hart"
> <dave...@gmail.com> wrote:
>
> >I've posted a new tarball, but it may not appear for a few minutes. It
> >should resolve the build failure you saw.
> >
> >https://people.nwtime.org/hart/ntp-dev-3792-msm-v2.tar.gz
> I'm running this on my elderly system and spotted this. It was
> unexpected by me but perhaps not by you. All servers at poll 10.
> (Times made human readable.)
>
> In protostats:
>
> >10:00:50 185.83.169.27 0313 83 unreachable
> >10:18:17 185.83.169.27 0014 84 reachable
>
> From peerstats before and after the above times
> (offset, delay, dispersion, jitter are all *1e3
> to be human readable):
>
> >06:27:16 185.83.169.27 135a -0.105 12.831 15.082 0.102
> >07:02:51 185.83.169.27 135a +0.201 12.720 15.429 0.332
> >07:38:36 185.83.169.27 145a +0.178 13.003 15.495 1.392
> >10:18:17 185.83.169.27 1014 +0.196 13.226 263.647 1.646
> >10:36:15 185.83.169.27 1414 +0.002 13.057 231.781 1.556
> >11:11:00 185.83.169.27 1414 +0.115 13.215 223.162 1.601
>
> Question: why wasn't this server dropped? I presume
> that the reach had gone down to 0.

I think it probably was dropped, and then picked up again Notice the big jump in root dispersion in the last three lines.

Also it's worth noting that manycastclient and pool associations are not demobilized when the reach register hits zero, but rather when the unreach counter hits 10 and they score the least among all associations and there are maxclock associations and there have not been any such demobilizations in the last 10 minutes (default "tos turnover 600").

Cheers,
Dave Hart

On Mon, 19 Jun 2023 05:47:32 -0700 (PDT), Dave Hart
<davehart@gmail.com> wrote:

>On Monday, June 19, 2023 at 11:57:31?AM UTC, Roger wrote:
>> On Sun, 28 May 2023 13:43:00 -0000 (UTC), "Dave Hart"
>> <dave...@gmail.com> wrote:
>>
>> >I've posted a new tarball, but it may not appear for a few minutes. It
>> >should resolve the build failure you saw.
>> >
>> >https://people.nwtime.org/hart/ntp-dev-3792-msm-v2.tar.gz
>> I'm running this on my elderly system and spotted this. It was
>> unexpected by me but perhaps not by you. All servers at poll 10.
>> (Times made human readable.)
>>
>> In protostats:
>>
>> >10:00:50 185.83.169.27 0313 83 unreachable
>> >10:18:17 185.83.169.27 0014 84 reachable
>>
>> From peerstats before and after the above times
>> (offset, delay, dispersion, jitter are all *1e3
>> to be human readable):
>>
>> >06:27:16 185.83.169.27 135a -0.105 12.831 15.082 0.102
>> >07:02:51 185.83.169.27 135a +0.201 12.720 15.429 0.332
>> >07:38:36 185.83.169.27 145a +0.178 13.003 15.495 1.392
>> >10:18:17 185.83.169.27 1014 +0.196 13.226 263.647 1.646
>> >10:36:15 185.83.169.27 1414 +0.002 13.057 231.781 1.556
>> >11:11:00 185.83.169.27 1414 +0.115 13.215 223.162 1.601
>>
>> Question: why wasn't this server dropped? I presume
>> that the reach had gone down to 0.
>
>I think it probably was dropped, and then picked up again
>Notice the big jump in root dispersion in the last three lines.

An update of the peerstats shows that the root dispersion
has come down and will, I presume, continue to be in the
region of 15-20 as it had been for many hours before this.

>06:27:16 185.83.169.27 135a -0.105 12.831 15.082 0.102
>07:02:51 185.83.169.27 135a +0.201 12.720 15.429 0.332
>07:38:36 185.83.169.27 145a +0.178 13.003 15.495 1.392
>10:18:17 185.83.169.27 1014 +0.196 13.226 263.647 1.646
>10:36:15 185.83.169.27 1414 +0.002 13.057 231.781 1.556
>11:11:00 185.83.169.27 1414 +0.115 13.215 223.162 1.601
>11:29:04 185.83.169.27 1414 +0.040 12.996 211.462 1.569
>12:04:48 185.83.169.27 1314 +0.529 13.135 206.530 0.439
>12:22:49 185.83.169.27 1314 +0.374 12.748 77.997 0.269
>12:57:24 185.83.169.27 1314 +0.398 12.767 15.208 0.256
>13:32:36 185.83.169.27 1414 +0.209 12.757 15.330 0.190
>14:07:27 185.83.169.27 161a +0.204 12.949 19.185 0.135

>Also it's worth noting that manycastclient and pool associations
>are not demobilized when the reach register hits zero, but
>rather when the unreach counter hits 10 and they score the
>least among all associations and there are maxclock
>associations and there have not been any such demobilizations
>in the last 10 minutes (default "tos turnover 600").

Thank you for your detailed answer. I'll continue using this
version and if anything else happens which I don't understand
you can be sure of a further question.
--
Roger