• ntpd on busybox ARM system not keeping time with server

    From Andreas Schick@21:1/5 to David Woolley on Tue May 18 06:11:47 2021
    David Woolley schrieb am Dienstag, 18. Mai 2021 um 13:58:46 UTC+2:
    On 18/05/2021 12:39, Andreas Schick wrote:
    I could safely remove the LCL entries and the server line where it lists own IPv4 address of the ARM box
    I think it is more accurate to say that you CANNOT safely keep these!
    The self reference is plain wrong.

    @David:Wooley: Thank you for confirming that. I was 'forced/asked' to set it up this way by one of my former colleagues, who is frankly speaking not really familiar with ntpd functionality. People here sadly (my employer) tend to assume stuff without
    exactly knowing the technical backgrounds. I think this idea initially came up because we are also using several of these ARM machines on one network and all of them are running ntpd and people used to always put all of them into server lines assuming
    they will get some strange sort of pooling redundancy or something. I still doubt it is the right way in that scenario and I'd rather prefer one server that is reasonably safe provided it is synced to some sort of outside world and has at least a battery
    buffered LCL.

    Regarding w32time I know it is not the solution anyone using ntp mechanisms would prefer (me included), but at least it gives me some means of time syncronisation as the network is missing a real ntp timeserver (eiteher a dedicated device or a reliable
    linux server machine running 24/7). The windows workstation is actually a server machine running 24/7 and it is connected to the internet via a router and a secondary NIC. Sadly I had the mentioned router already failing or dropping the internet
    connection and that lead to the windows machine dropping to stratum 16 and then clients have to say goodbye to synchronisation. But this risk I currently have to take.

    If I could I'd replace that windows host by some dedicated time server (e.g. the meinberg lantime series). But at the moment unfortunately I can not do that.

    Another question I have is: does adding iburst to the server entry improve startup behavior of ntpd, as far as I saw it does not make much difference in my scenario, as I only have one accessible server on my network.
    And as per the documents I read so far it just makes the server send out several requests in a shorter time period. I do not think it will improve the situation I am having in regards to startup, as it already seems to work fine now without it.

    One further idea I had was just modifying some startup scripts (which run before ntpd process is started and after the network is up) to include some from of a ntpd-run-sync-and-quit or ntpdate call that steps the clock at system startup on the ARM
    device. I have to avoid stepping the system time during normal system runtime as timers in some software can misbehave if a leap in time is detected. But at the moment startup behavior seems fine after boot and the time just is not in sync after a couple
    of hours days of the system running.

    Thank you for helping anyway.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jakob Bohm@21:1/5 to David Woolley on Wed May 19 02:57:20 2021
    On 2021-05-18 13:56, David Woolley wrote:
    On 18/05/2021 12:26, Andreas Schick wrote:
    server 127.127.1.0              # local clock (LCL)
    fudge  127.127.1.0 stratum 10   # LCL is unsynchronized

    Delete these lines.  As described, this system is not suitable as a time server, and including these lines on a pure client can actually
    frustrate synchronisation. This fake server is likely to vote against
    the genuine server.


    Perhaps the "tos orphan" option is a better way to make ntpd continue
    after loss of all time sources.

    Maybe some option to force treating the Windows server as stratum 12,
    even if it looses outside synch and reports itself as stratum 16.

    server  192.168.101.2

    This appears to be the machine itself, so it will be voting that's its
    own time is correct.  Delete it.

    Windows machines can vary from fair to atrocious as time servers.  A workstation running a default configuration of w32time will be at the atrocious end.

    Fortunately, this is reportedly a server, which means it will keep time
    with a somewhat coarse granularity and include a battery backed TOY
    (Time Of Year) clock to keep time even across power outages.

    W32Time in server mode has a tendency to fluctuate about +/- 10ms from
    the time sources. It is designed to provide an SNTP time source for
    Kerberos clients that need to stay within +/- 5 minutes of the Kerberos
    KDC.


    You should make sure that the ARM starts in the right ball park, by
    either using a file timestamp to record the time at, or close to,
    shutdown, or, as a last resort, setting a fixed time that isn't too far
    from reality.

    Perhaps using the sntp program to do initial synchronization to the
    server machine (as a better alternative to ntpd -g).

    Enjoy

    Jakob
    --
    Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
    Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
    This public discussion message is non-binding and may contain errors.
    WiseMo - Remote Service Management for PCs, Phones and Embedded

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Terje Mathisen@21:1/5 to Jakob Bohm on Wed May 19 09:55:37 2021
    Jakob Bohm wrote:
    On 2021-05-18 13:56, David Woolley wrote:
    On 18/05/2021 12:26, Andreas Schick wrote:
    server 127.127.1.0              # local clock (LCL)
    fudge  127.127.1.0 stratum 10   # LCL is unsynchronized

    Delete these lines.  As described, this system is not suitable as a
    time server, and including these lines on a pure client can actually
    frustrate synchronisation. This fake server is likely to vote against
    the genuine server.


    Perhaps the "tos orphan" option is a better way to make ntpd continue
    after loss of all time sources.

    Maybe some option to force treating the Windows server as stratum 12,
    even if it looses outside synch and reports itself as stratum 16.

    server  192.168.101.2

    This appears to be the machine itself, so it will be voting that's its
    own time is correct.  Delete it.

    Windows machines can vary from fair to atrocious as time servers.  A
    workstation running a default configuration of w32time will be at the
    atrocious end.

    Fortunately, this is reportedly a server, which means it will keep time
    with a somewhat coarse granularity and include a battery backed TOY
    (Time Of Year) clock to keep time even across power outages.

    W32Time in server mode has a tendency to fluctuate about +/- 10ms from
    the time sources.  It is designed to provide an SNTP time source for Kerberos clients that need to stay within +/- 5 minutes of the Kerberos
    KDC.


    You should make sure that the ARM starts in the right ball park, by
    either using a file timestamp to record the time at, or close to,
    shutdown, or, as a last resort, setting a fixed time that isn't too
    far from reality.

    Perhaps using the sntp program to do initial synchronization to the
    server machine (as a better alternative to ntpd -g).

    ntpd with iburst is pretty much always better, even more so when you
    have multiple servers configured.

    Terje


    --
    - <Terje.Mathisen at tmsw.no>
    "almost all programming can be viewed as an exercise in caching"

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Miroslav Lichvar@21:1/5 to Andreas Schick on Wed May 19 08:04:52 2021
    On 2021-05-18, Andreas Schick <a.schick81@web.de> wrote:
    One further idea I had was just modifying some startup scripts (which
    run before ntpd process is started and after the network is up) to
    include some from of a ntpd-run-sync-and-quit or ntpdate call that
    steps the clock at system startup on the ARM device.

    Another possibility is to start ntpd normally and wait for it to set the
    clock. There is the ntp-wait script for that. On systemd-based
    distributions there is a time-sync target which delay start of services
    that need accurate clock.

    --
    Miroslav Lichvar

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Woolley@21:1/5 to Jakob Bohm on Wed May 19 11:12:07 2021
    On 19/05/2021 01:57, Jakob Bohm wrote:
    Perhaps the "tos orphan" option is a better way to make ntpd continue
    after loss of all time sources.

    This is a pure client configuration. There is no need for ntpd to
    continue to serve time after the loss of all sources. The kernel
    software clock will continue to run, using the last available frequency correction supplied by ntpd, without the need for any time island
    mitigation measures.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jakob Bohm@21:1/5 to Terje Mathisen on Wed May 19 12:09:41 2021
    On 2021-05-19 09:55, Terje Mathisen wrote:
    Jakob Bohm wrote:
    On 2021-05-18 13:56, David Woolley wrote:
    On 18/05/2021 12:26, Andreas Schick wrote:
    server 127.127.1.0              # local clock (LCL)
    fudge  127.127.1.0 stratum 10   # LCL is unsynchronized

    Delete these lines.  As described, this system is not suitable as a
    time server, and including these lines on a pure client can actually
    frustrate synchronisation. This fake server is likely to vote against
    the genuine server.


    Perhaps the "tos orphan" option is a better way to make ntpd continue
    after loss of all time sources.

    Maybe some option to force treating the Windows server as stratum 12,
    even if it looses outside synch and reports itself as stratum 16.

    server  192.168.101.2

    This appears to be the machine itself, so it will be voting that's
    its own time is correct.  Delete it.

    Windows machines can vary from fair to atrocious as time servers.  A
    workstation running a default configuration of w32time will be at the
    atrocious end.

    Fortunately, this is reportedly a server, which means it will keep time
    with a somewhat coarse granularity and include a battery backed TOY
    (Time Of Year) clock to keep time even across power outages.

    W32Time in server mode has a tendency to fluctuate about +/- 10ms from
    the time sources.  It is designed to provide an SNTP time source for
    Kerberos clients that need to stay within +/- 5 minutes of the Kerberos
    KDC.


    You should make sure that the ARM starts in the right ball park, by
    either using a file timestamp to record the time at, or close to,
    shutdown, or, as a last resort, setting a fixed time that isn't too
    far from reality.

    Perhaps using the sntp program to do initial synchronization to the
    server machine (as a better alternative to ntpd -g).

    ntpd with iburst is pretty much always better, even more so when you
    have multiple servers configured.


    In my experience, ntpd algorithms converge very slowly in the trivial
    cases where the initial local clock is not set, and all (or only in the
    OPs case) sources agree on the correct time (TrueChimers).



    Enjoy

    Jakob
    --
    Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
    Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
    This public discussion message is non-binding and may contain errors.
    WiseMo - Remote Service Management for PCs, Phones and Embedded

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Terje Mathisen@21:1/5 to Jakob Bohm on Wed May 19 12:51:39 2021
    Jakob Bohm wrote:
    On 2021-05-19 09:55, Terje Mathisen wrote:
    Jakob Bohm wrote:
    On 2021-05-18 13:56, David Woolley wrote:
    On 18/05/2021 12:26, Andreas Schick wrote:
    server 127.127.1.0              # local clock (LCL)
    fudge  127.127.1.0 stratum 10   # LCL is unsynchronized

    Delete these lines.  As described, this system is not suitable as a
    time server, and including these lines on a pure client can actually
    frustrate synchronisation. This fake server is likely to vote
    against the genuine server.


    Perhaps the "tos orphan" option is a better way to make ntpd continue
    after loss of all time sources.

    Maybe some option to force treating the Windows server as stratum 12,
    even if it looses outside synch and reports itself as stratum 16.

    server  192.168.101.2

    This appears to be the machine itself, so it will be voting that's
    its own time is correct.  Delete it.

    Windows machines can vary from fair to atrocious as time servers.  A
    workstation running a default configuration of w32time will be at
    the atrocious end.

    Fortunately, this is reportedly a server, which means it will keep time
    with a somewhat coarse granularity and include a battery backed TOY
    (Time Of Year) clock to keep time even across power outages.

    W32Time in server mode has a tendency to fluctuate about +/- 10ms from
    the time sources.  It is designed to provide an SNTP time source for
    Kerberos clients that need to stay within +/- 5 minutes of the Kerberos
    KDC.


    You should make sure that the ARM starts in the right ball park, by
    either using a file timestamp to record the time at, or close to,
    shutdown, or, as a last resort, setting a fixed time that isn't too
    far from reality.

    Perhaps using the sntp program to do initial synchronization to the
    server machine (as a better alternative to ntpd -g).

    ntpd with iburst is pretty much always better, even more so when you
    have multiple servers configured.


    In my experience, ntpd algorithms converge very slowly in the trivial
    cases where the initial local clock is not set, and all (or only in the
    OPs case) sources agree on the correct time (TrueChimers).

    Huh?

    With an initial iburst I'm seeing 1-5s convergence.

    Terje


    --
    - <Terje.Mathisen at tmsw.no>
    "almost all programming can be viewed as an exercise in caching"

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)