ntpd operates, as I said, in a certain way. It sends out a request for
time at the poll intervals. It then looks at the last 8 times and if the
current round trip time is greater than any in the last 8 times, the
current one is not used and the next poll is waited for. Thus, the used
measurements vary between poll interval and 8 times poll interval time
between them.
Then that measurement is compared with the local clock. If it shows that
the local clock is slow, the local clocks tick rate is increased by a
small amount-- proportional to that offset and inversely proportional to
the poll interval, but much less than would be required to fix the
offset within even 8 poll intervals. And the process continues.
Eventually, the local clock's rate is increased enough that the offset
starts to decrease and finally the time offset is also decreased.
Ie, the local clock is NOT reset, is not synced except over a long time.
Its rate is gradually changed. After the local rate equals the distant
rate, and the local offset is small, the local clock tracks slow drifts
either in its own rate or the remote rate.
ntp does terribly if the local, or remote rate change suddenly. It takes
a long time (about 8 poll intervals) to even notice, and then much
longer to bring the rates into line again. Mills designed the system
with stability, not speed of response, in mind.
Whether this kind of feedback system is the best use of the measurements
made has been a long topic of discussion (extending back into the first
design of ntpd). chrony, another program which uses the ntp packet
exchange protocol for time discipline, and interoperates on the packet
level with ntpd, uses a different philosophy, and is much faster at
responding to changes, and has been found to discipline the clock much
more accurately (3-20 better in offset jitter in a variety of tests).
Whether it has drawbacks to compensate is a topic ripe for testing.
However for you its biggest drawback is that it does not run under
Windows or MacOS (although the latter should not be a difficult port
since macOS is based on BSD/Unix. )
>
> NTPd whe started with -g steps your system within 128ms of UTC
> then disciplines the rate at which the system sees time passing
> to get the offset closer to UTC.
> It decides how often it needs to request information and make
> corrections depending on how it sees your platform behaving.
>
> How close you get to UTC depends on the stability of your OS,
> hardware, and time sources, so may be ms with network sources
> or Windows, us with hardware reference clocks (e.g. GPS with PPS),
> or ns with BSD on embedded systems (e.g. Soekris) with time nut
> level hardware (e.g. Trimble Thunderbolt) and external antennas
> (e.g. survey quality) with a good view of the sky (no trees or
> buildings nearby and above the level of the antenna). YMMV
Well, no, with just a bog standard level gps (eg the $35 Sure out a
window with trees in the way) and standard serial port interupt,
I get a few usec level jitter, and using it as a network source for
other machines, I get 10s of usec errors (measured with separate gps pps
attached as the standard) over the local network. Even over an ADSL line
from home, I was getting better than 100 usec on the home machine.
So, yes, YMMV.
>