[ntp:questions] peers don't synch with each other when runnig on local clock

[Juergen]

Dear NTP community.

I've noticed a strange behavior of ntpd-4.2.3.

Two hosts
- configured to act as peers to each other
- with an unreachable external time source
- the local clock configured as fallback
both select their local clock and stay in this mode, even when the
offset
between them grows and grows.

With ntp 4.2.0, one of them took over control so that they stayed at
least in-
sync with each other.

Example:

The host involved are ipcop, chip & chap.

Configuration on chip:

server 127.127.1.0 iburst minpoll 4 maxpoll 4
fudge  127.127.1.0 stratum 10
server ipcop burst iburst minpoll 4 maxpoll 6
peer chap burst iburst minpoll 4 maxpoll 4

Configuration on chap:

server 127.127.1.0 iburst minpoll 4 maxpoll 4
fudge  127.127.1.0 stratum 10
server ipcop burst iburst minpoll 4 maxpoll 6
peer chip burst iburst minpoll 4 maxpoll 4

With ipcop being unreachable, the ntpq -p on chip & chap looks like
this.

# ntpq -p chip chap
server remote    refid       st t when poll reach   delay   offset
jitter
==========================================================================
chip  *LOCAL(0)  .LOCL.      10 l   10   16  377    0.000    0.000
0.001
chip   ipcop     .INIT.      16 u    -   64    0    0.000    0.000
0.000
chip   chap      LOCAL(0)    11 u   14   16  376    0.133   12.538
0.038
server remote    refid       st t when poll reach   delay   offset
jitter
==========================================================================
chap  *LOCAL(0)  .LOCL.      10 l    2   16  377    0.000    0.000
0.001
chap   ipcop     .INIT.      16 u    -   64    0    0.000    0.000
0.000
chap   chip      LOCAL(0)    11 u    1   16  377    0.166  -12.522
0.055

These two hosts are not really a realiable redundancy pair for their
ntp
clients. Isn't it?
Running away from each other, they both are marked as falstetickers
soon. :-(

Using the same configuration with ntpd-4.2.0, the result looks much
better.

# ntpq -p chip chap
server remote    refid       st t when poll reach   delay   offset
jitter
==========================================================================
chip  *LOCAL(0)  LOCAL(0)    10 l    1   16  377    0.000    0.000
0.001
chip   ipcop     .INIT.      16 u    -   64    0    0.000    0.000
4000.00
chip   chap      192.168.1.1 12 u    2   16  376    0.237    0.043
0.012
server remote    refid       st t when poll reach   delay   offset
jitter
==========================================================================
chap   LOCAL(0)  LOCAL(0)    10 l    3   16  377    0.000    0.000
0.001
chap   ipcop     .INIT.      16 u    -   64    0    0.000    0.000
4000.00
chap  *chip      LOCAL(0)    11 u    1   16  377    0.232   -0.043
0.017

I originally raised this as a bug (Bug ID 748).
However, Steve Kosteke proposed to move the topic to the newsgroup.

Brian Utterback already made some proposals:

1. Use different stratum settings for the local clocks.
   -> This doesn't change the behaviour. (Even wit stratum differences
> 2)
2. Don't configure the local clocks.
   -> This doesn't work for the startup case.

It seems that something has been changed in the internal selection
algorithms between
version 4.2.0 and version 4.2.3.
Bug/Feature introduction/removal? That's the question. ;-)

Juergen