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