Miroslav,
I set up the same configuration as yours, but got different results.
55358 827.068 128.4.2.24 8011 81 mobilize assoc 39075
55358 827.086 0.0.0.0 c016 06 restart
55358 827.086 0.0.0.0 c012 02 freq_set ntpd 10.669 PPM
55358 827.885 128.4.2.24 8024 84 reachable
55358 833.883 128.4.2.24 963a 8a sys_peer
55358 833.883 0.0.0.0 c61c 0c clock_step +5.395800 s
55358 839.280 0.0.0.0 c614 04 freq_mode
55358 840.280 128.4.2.24 8044 84 reachable
55358 840.280 0.0.0.0 c618 08 no_sys_peer
55358 846.280 128.4.2.24 965a 8a sys_peer
55358 1749.281 0.0.0.0 c612 02 freq_set ntpd 9.808 PPM
55358 1749.281 0.0.0.0 c615 05 clock_sync
55358 4773.280 0.0.0.0 0618 08 no_sys_peer
55358 4773.280 128.4.2.24 8063 83 unreachable
55358 5013.283 128.4.2.24 8074 84 reachable
55358 5121.281 128.4.2.24 968a 8a sys_peer
An hour later I disconnected the server. By second 4773 the server
became unreachable and was undeclared the system peer. ten minutes later
I reconnected the server which again became reachable and the system peer.
About five years ago I began a program to carefully review the program
logic according to sound engineering principles. The behavior over the
preceding 25 years had drifted due to various weed patches and bugfixes.
It is my understanding that the results of this program are now in the
release version; however, some sllipup might have occurred. If you are
using an old release version, that might explain your results.
Dave
Miroslav Lichvar wrote:
On Wed, Jun 09, 2010 at 11:48:00PM +0000, David L. Mills wrote:
Seriously untrue. If the server is unreachable from the client, the
tally code shown at the client is blank and can never be the system
peer. To prove your case, show evidence the reach register is zero
and the tally code is *,
David,
have you tried blocking the connection after receiving four replies
from the peer as I wrote in the bug report? That seems to be the
easiest way how to reproduce the problem.
It happens in other situations too. Here is an ntpd log where the
outgoing packets were blocked in pattern: 100 unblocked, 6 blocked, 4
unblocked, 2890 blocked. As you can see there are 52 hours when the
peer was unreachable and marked as system peer.
31 May 08:55:47 ntpd[31411]: 192.168.1.1 8011 81 mobilize assoc 20984
31 May 08:55:47 ntpd[31411]: 0.0.0.0 c016 06 restart
31 May 08:55:47 ntpd[31411]: 0.0.0.0 c012 02 freq_set kernel -16.405 PPM
31 May 08:55:48 ntpd[31411]: 192.168.1.1 8024 84 reachable
31 May 08:59:05 ntpd[31411]: 192.168.1.1 963a 8a sys_peer
31 May 08:59:05 ntpd[31411]: 0.0.0.0 c615 05 clock_sync
31 May 11:03:39 ntpd[31411]: 192.168.1.1 8643 83 unreachable
2 Jun 15:31:22 ntpd[31411]: 192.168.1.1 8654 84 reachable
2 Jun 15:31:22 ntpd[31411]: 0.0.0.0 0618 08 no_sys_peer
2 Jun 15:41:17 ntpd[31411]: 192.168.1.1 966a 8a sys_peer
2 Jun 15:54:25 ntpd[31411]: 0.0.0.0 0613 03 spike_detect -0.239374 s
2 Jun 16:08:34 ntpd[31411]: 0.0.0.0 061c 0c clock_step -0.536514 s
2 Jun 16:08:34 ntpd[31411]: 0.0.0.0 0615 05 clock_sync
2 Jun 16:08:35 ntpd[31411]: 192.168.1.1 8074 84 reachable
This seems to happen when the reachable register was not full when the
server stopped responding and clock_filter() didn't call
clock_select() which would unselect the system peer.
When the source stops responding, the first few MAXDISPERSE samples
pushed from the transmit() timeout won't pass the epoch check in
clock_filter(), then the function will abort on the condition which
checks if there are any acceptable samples.
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
