Conference turris::digital_unix

    From what I've observed, "Previous time adjustment didn't complete" is
    an informational message xntpd generates when the next attempted time
    adjustment comes around before a gradual adjustment initiated by the
    previous one has finished. If you have a large initial clock skew or if
    you have a crummy hardware clock, for example a Sun, you'll see it a
    lot more often. Sounds like that's what you've got (large drift
    factors). I believe you'll also see it more often if the hardware clock
    runs fast, because that requires a gradual adjustment, whereas a slow
    clock can be "jumped" ahead. I suppose if the hardware clock accuracy
    was bad enough you'd see it almost all the time.
    
    -Tom

Hi,

8948.1 was a good reply, but I'll throw in my $.02 worth too.

I think 8225.1 said it pretty well.  Good timekeeping has
a lot to do with server reachability.  According to 8225.3/4,
all of you your "clients" can reach their local server ok,
but it's *really* getting time from the Internet (ugh).
The delays on that look pretty high, not to mention they
are *9* hops away.  Look how big the drift is on ecn04, 19.103.

From what I know about NTP, this delay will just propagate
to the clients.  Ecno4 is getting bad time, and he's just
passing it on, the drifts on all the clients show this.

Another thing that stuck out at me was the local precision of
one of your clients - "precision = 976 usec".  My machine is
running with a precision = 12 usec.  Maybe your local clock is
causing a lot of the warnings because it's always doing adjust-
ments w.r.t. the NTP server.  I know there was a bug with
machines losing time, you might want to search the conference
and determine if that's affecting you too.

I guess the solution that comes to mind is to have your customer
buy a clock, that way they're not relying on routers, Internet
connections, etc. that are obviously injecting time delays.

As Dirce said in her original post - "It is not a bug, but
the way xntpd behaves."  Again, these messages are just warnings,
they are not fatal, and should not be perceived that way.

-Brian
[Posted by WWW Notes gateway]

    re: .2
    
    Good points. That message _can_ be a symptom of time servers that don't
    quite agree on what the right time is, especially if you have spotty
    connectivity to the servers. One says "set the time ahead", the other
    says "set it back". The result is that xntpd jumps the time ahead,
    slowly it adjusts it back, jumps it ahead, etc.
    
    Another scenario that can cause oscillation is if you have another time
    service, such as DECnet/DTSS or DCE DTS, running on the same host with
    xntpd, also trying to adjust the clock. The multiple services can pull
    on the clock in opposite directions, working against each other and
    producing a pseudo-stable time. A symptom of that in xntpd is, in fact,
    a very large drift factor. In such a case, disabling DTSS or DTS puts
    things back to normal, but only after the clock takes off like a rocket
    in one direction or the other, stabilizing after a few days.
    
    -Tom

    Has anyone written a good document on ntp and its management? Id like
    to see something with a good description of how it operates and various
    configuration examples. An O'reilley book would be perfect, but I dont
    think they have one.

    re: .-1
    
    The xntp distribution includes a set of HTML pages that describe NTP
    and xntpd pretty well. They also include a bibliography, most of which
    is available electronically.
    
    The NTP home page, which includes even more information and the
    distributions, is at http://www.eecis.udel.edu/~ntp/ .
    
    -Tom