Re: NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)

"David L. Mills" <mills@xxxxxxxx> writes:

Guys,

I haven't read every word on this thread, but all I can contribute is
that nothing reported here is anything like my experience here. Our
servers pogo.udel.edu and rackety.udel.edu are synchronized via GPS and
PPS. I invite the skeptics to peek at them from time to time. I describe
their behavior as like cats; most of the time they are quiet and gentle
at a few microseconds, but once in a whild they show a surge of ten
microseconds or more, especially after a power failure, which we do get
from time to time.

You can also peek at mine (string.physics.ubc.ca) on
www.theory.physics.ubc.ca/chrony/chrony.html




There is a persistent report that appears as a low-frequency ringing
with more or less constant period. This would seem to suggest something
wrong with the discipline loop transient response. In the past the most
likely cause has been an ill-advised tinker with the Unix adjtime()
system call with the dubious purpose of reducing the time to slew the
clock over some range. This wrecks the transient response and easily
leads to loop instability. If you are using the kernel time discipline
and not adjtime() this is not an issue.

I use ntp with NO tinkering at all. So if the problem exists it exists in
NTP 4.2.4


There are lots of ways to measure the loop transient response. The
easiest way is to set the clock some 50-100 ms off from some stable
source (not necessarily accurate) and watch the loop converge. The
response should cross zero in about 3000 s and overshoot about 6 percent

3000 s is a HUGE time. For people who switch on their computers daily, that
means most of their time is spent with the computer unsynchronised to best
accuracy. The timescale of chrony is far faster. (I am not a writer of
chrony.I am a user who is trying to get the very best out of the
timekeeping.)


and smoothly amortize over several hours. Be sure to clamp the poll
interval to 64 s over that period. If it does something else, like show
an exponentially decreasing ringing. Go looking for trouble.

As for "offset should be much larger than the error", be careful here.
By error I assume you mean what ntpq rv shows as jitter. The best case
is when offset is indeed less than jitter; if the error is much larger
than error, this suggests the frequency has surged and the time
constant/poll interval needs to be reduced. Watch the poll interval
behavior in the loopstats data.

Dave

David Woolley wrote:

In article <eI8lj.17461$yQ1.5617@edtnps89>,
Unruh <unruh-spam@xxxxxxxxxxxxxx> wrote:


No, the offset is the value reported in loopstats.


Same thing. If chrony is reporting the same measurements, neither set of
measurements is particularly valid. You need to measure the actual
offsets, using something that has a repeatability a couple of orders
of magnitude better. Certainly for ntpd, offset should be much larger
than the error, when locked. Is the server running ntpd?

Anyway, as I said, arguing by proxy is difficult and I'm rather hoping that
Dave Mills will take over. Certainly it is Dave Mills you have to
convince if ntpd is going to change.

.

Relevant Pages

  • Re: Hacking Attempts ?
    ... Im seeing this in clients servers also. ... give better reporting function, got no idea which 'door' this webmaster is ... a "webmaster" username attempt yesterday as well. ... Logon Failure: ...
    (microsoft.public.windows.server.sbs)
  • Re: Wrong network usage reported by /proc
    ... servers that are reporting all sorts of impossible ... The values collected using tcpdump always seem realistic and match the ... I download a DVD ISO from a remote workstation: ...
    (Linux-Kernel)
  • Re: BSDstats: New High Water Mark: 25 000+ Hosts Reporting In
    ... I have 10 FreeBSD servers and desktops in use here in Hawaii. ... the reporting is not based on your IP ... ... individual host to connect to the rver ... ...
    (freebsd-questions)
  • Wrong network usage reported by /proc
    ... servers that are reporting all sorts of impossible ... network usage values through /proc, ... I download a DVD ISO from a remote workstation: ...
    (Linux-Kernel)