Danny Mayer wrote:
Richard B. Gilbert wrote:
Danny Mayer wrote:
David J Taylor wrote:
Danny Mayer wrote:
David J Taylor wrote:
Just a small point, but it would be nice if ntpd used the event
number ID on Windows as well. At the moment, all events have an
<snip>
In my opinion, info. It's just telling you what it did. There's nothing
wrong with that since it's the intended behavior.
Danny
Doesn't the very fact that it found it necessary to reset the time
indicate some sort of a problem? If everything were working as
designed ntpd should be tweaking the fine tuning knob instead of
wrenching the clock hands around.
Not in my opinion. You told ntpd to do whatever is necessary to keep the
clock in synch and that's just what it's doing. You're suggesting
different categories for different methods of changing the clock. I'm
not sure why it would be any different.
Danny
My point was that, in a properly working system, ntpd should not need to
"reset" the clock once it has been synchronized. Let's look at reasons
why this might happen:
a. ntpd selected a new server for synchronization. The selected
server's time differed from the client's by more than the step threshold.
b. the client's clock is drifting at a rate greater the 500 PPM limit
on slew rate.
c. the client has been unable to get time from a server for a long time,
a lapse in service sufficient to let the client's clock drift past the
step threshold.
I think that any of the above three reasons would merit a warning or an
error message. Did I miss any possible causes that would rate only an
informational message?
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
