peers don't synch with each other when runnig on local clock - NTP

This is a discussion on peers don't synch with each other when runnig on local clock - NTP ; 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 ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: peers don't synch with each other when runnig on local clock

  1. peers don't synch with each other when runnig on local clock

    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


  2. Re: peers don't synch with each other when runnig on local clock

    >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.


    [chip]
    >fudge 127.127.1.0 stratum 10


    [chap]
    >fudge 127.127.1.0 stratum 10


    > chip *LOCAL(0) .LOCL. 10 l 10 16 377 0.000 0.000 0.001
    > chip chap LOCAL(0) 11 u 14 16 376 0.133 12.538 0.038


    I don't know how the old version worked. Did you have the exact
    same config files?

    This looks like it's doing something sensible. It's picking the local
    stratum 10 clock over the remote stratum 10 system. Both sides are
    doing the same thing.

    Which system do you want to be boss in this case? Try making the
    local clock on the other one run at stratum 12.

    --
    These are my opinions, not necessarily my employer's. I hate spam.


  3. Re: peers don't synch with each other when runnig on local clock

    Hal is right - the implementation is doing the right thing.

    See http://ntp.isc.org/Support/ConfiguringLocalRefclock .

    H

  4. Re: peers don't synch with each other when runnig on local clock

    Hi Hal & Harlan.

    As I already wrote, changing the stratum settings doesn't change
    anything.

    A quote from the bug report:

    Hi Brian.

    Well, changing the stratum of the local clocks doesn't change anything.

    # ntpq -p chip chap
    server remote refid st t when poll reach delay offset
    jitter
    ================================================== ========================
    chip *LOCAL(0) .LOCL. 11 l 12 16 377 0.000 0.000
    0.001
    chip ipcop .INIT. 16 u - 16 0 0.000 0.000
    0.000
    chip chap LOCAL(0) 14 u 9 16 376 0.130 10.937
    0.039
    # ntpq -p chip chap
    server remote refid st t when poll reach delay offset
    jitter
    ================================================== ========================
    chap *LOCAL(0) .LOCL. 13 l 11 16 377 0.000 0.000
    0.001
    chap ipcop .INIT. 16 u - 16 0 0.000 0.000
    0.000
    chap chip LOCAL(0) 12 u 6 16 377 0.119 -10.932
    0.031

    Chap continues to run on local clock even when the peer-stratum is
    better.

    Bye
    Juergen


  5. Re: peers don't synch with each other when runnig on local clock

    Comparing the documentation of 4.2.0 and 4.2.3, I found the 'tos orphan
    ' configuration option.
    This option didn't exists yet in 4.2.0.
    Is it possible that this option was introduced to cover exactly the
    scenarion mentionend above?
    This might be the reason why behaviour with peer & local-clock has
    changed...

    Can someone confirm this?

    Juergen


  6. Re: peers don't synch with each other when runnig on local clock

    Juergen,

    I run the setup you describe in a number of places without problems and I do
    not use (or seem to need) 'orphan' mode. I have never used orphan mode, so
    I'd just be reading the docs just like most anybody else.

    Just to be sure, do you have any 'restrict' statements in either ntp.conf
    file? If so, please comment them out and restart ntpd.

    H

  7. Re: peers don't synch with each other when runnig on local clock

    Hi Harlan.

    I have no restrict statements in any of the configuration files.

    You wrote that you use a similar setup in a number of places.
    Did you ever startup the peer group without connection to any ntp
    server?
    The effect only occurs when the peer group is started up 'in
    isolation'.

    Bye
    Juergen


  8. Re: peers don't synch with each other when runnig on local clock

    I'm sure I have - I have been running this way for many years.

    I did not see this note of yours about the problem only happening when the
    peer group is started up in isolation - that is probably important
    information; would you please add it to the report?

    H
    --
    >>> In article <1165945034.542042.188390@n67g2000cwd.googlegroups. com>, "Juergen Salm" writes:


    Juergen> You wrote that you use a similar setup in a number of places. Did
    Juergen> you ever startup the peer group without connection to any ntp
    Juergen> server? The effect only occurs when the peer group is started up
    Juergen> 'in isolation'.

    Juergen> Bye Juergen


+ Reply to Thread