1. Forum
  2. Newsgroups
  3. comp.protocols.time.ntp

  • ntpd keeps calling adjtime when synchronized to local clock

    From rcheaito via questions Mailing List@questions@lists.ntp.org to questions on Mon Nov 3 22:43:00 2025
    From Newsgroup: comp.protocols.time.ntp

    When ntpd is running with the following simple config:

    restrict 127.0.0.1
    server 127.127.1.0

    is it expected that ntpd keeps calling adjtime()?

    My understanding is that in this config type, ntpd runs as server only, and will sync itself to the local clock driver. So, if I am not missing something, the daemon should not try to adjust the local clock that it is synchronizing to.

    Is this a specific behavior with VxWorks (where I am testing ntpd with), or common to all systems?


    0x01d67ad0 ntpdmain +0x6c0: timer ()
    0x01d85968 timer +0x58 : 0x01d7156c ()
    0x01d71698 adj_host_clock+0x164: adj_systime ()
    0x0092eca0 adj_systime +0x254: adjtime ()

    Thanks

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From David Woolley@david@ex.djwhome.demon.invalid to comp.protocols.time.ntp on Mon Nov 3 23:36:53 2025
    From Newsgroup: comp.protocols.time.ntp

    On 03/11/2025 22:43, rcheaito via questions Mailing List wrote:
    My understanding is that in this config type, ntpd runs as server only, and will sync itself to the local clock driver. So, if I am not missing something,
    the daemon should not try to adjust the local clock that it is synchronizing to.

    It will report a finite stratum, and the frequency and phase adjusted
    system time. Unless the kernel API allows direct setting of the time
    (and if it is using adjtime, rather than adjtimex, that suggest the
    kernel doesn't allow control of the frequency), it will need to
    continuously nudge the kernel time, to keep the effective average
    frequency at the value it was set to before it lost all upstream
    sources, in the same way as it was being controlled when the upstream
    sources were valid.

    What you appear to be suggesting would result in the frequency reverting
    to the one determined by the crystal, but ntpd knows the error in that frequency, immediately before the outage, so can and does correct for
    that error.

    The ntpd time for a machine is always the corrected local time for that machine, so there is no resynchronisation process. What actually
    happens is a change in the metadata.

    Using the local clock pseudo-driver has been superceded by orphan mode,
    as the preferred way of handling this situation.
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From David Woolley@david@ex.djwhome.demon.invalid to comp.protocols.time.ntp on Mon Nov 3 23:37:57 2025
    From Newsgroup: comp.protocols.time.ntp

    On 03/11/2025 23:36, David Woolley wrote:
    allows direct setting of the time

    That should have said "of the frequency".
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Harlan Stenn via questions Mailing List@questions@lists.ntp.org to rcheaito on Tue Nov 4 02:13:00 2025
    From Newsgroup: comp.protocols.time.ntp

    On 11/3/2025 1:22 PM, rcheaito (via questions Mailing List) wrote:
    When ntpd is running with the following simple config:

    restrict 127.0.0.1
    server 127.127.1.0

    is it expected that ntpd keeps calling adjtime()?

    Yes.

    Ntpd monitors time from its sources, and adjusts the clock.

    If you're using the LOCAL refclock, ntpd gets the time from the local
    clock. It will discover that this source of time matches the system
    time, so it calls adjtime() with no adjustment needing to be made.

    My understanding is that in this config type, ntpd runs as server only, and will sync itself to the local clock driver. So, if I am not missing something,
    the daemon should not try to adjust the local clock that it is synchronizing to.

    That would be extra code that complicates how things work.

    Is there a compelling reason to add this complication?

    Is this a specific behavior with VxWorks (where I am testing ntpd with), or common to all systems?
    I believe it will be common to all systems.

    And I could be wrong - I've been on the edge of a migraine for more than
    2 weeks' time.

    0x01d67ad0 ntpdmain +0x6c0: timer ()
    0x01d85968 timer +0x58 : 0x01d7156c ()
    0x01d71698 adj_host_clock+0x164: adj_systime ()
    0x0092eca0 adj_systime +0x254: adjtime ()

    Thanks
    Side note - in general, we recommend against using the LOCAL refclock.

    See https://support.ntp.org/Support/ConfiguringLocalRefclocks for more information.
    --
    Harlan Stenn <stenn@ntp.org>
    NTP Project Lead. The NTP Project is part of
    https://www.nwtime.org/ - be a member!

    --- Synchronet 3.21a-Linux NewsLink 1.2