6 messages in org.freebsd.freebsd-stableRe: xntp messages in new build | From | Sent On | Attachments |
|---|---|---|
| Scot Elliott | Feb 20, 1998 7:37 am | |
| Dennis Tenn | Feb 20, 1998 8:34 am | |
| Studded | Feb 20, 1998 10:54 am | |
| Warner Losh | Feb 20, 1998 2:30 pm | |
| Dennis Tenn | Feb 20, 1998 3:28 pm | |
| Louis A. Mamakos | Mar 3, 1998 5:52 pm |
| Subject: | Re: xntp messages in new build | |
|---|---|---|
| From: | Louis A. Mamakos (lou...@TransSys.COM) | |
| Date: | Mar 3, 1998 5:52:02 pm | |
| List: | org.freebsd.freebsd-stable | |
In message <Pine...@fanfic.org> Dennis Tenn
writes:
: | Feb 20 15:34:16 uranus xntpd[16462]: Previous time adjustment didn't
: | complete
:
: All it means AFAIK is it couldn't connect to the time server to update the
: clock. This happens on my system too and you shouldn't worry about it.
No. That's not quite right. It means that the last adjustment (via tickadj) didn't finish slowly skewing the clock before the next one was requested. I've seen this mostly when there is a largish offset at the start. You can ignore these messages if you have a couple, but thery may indicate something wrong with your hardware (or that of the time server) if you get lots of them.
Under normal circumstances, you shouldn't see this out of a clock adjustment that NTP makes. If you are, there are two likely possibilities:
- Some other process (like timed?) did a tickadj() system call, and when the xntpd daemon did it's adjustment, it's seeing the residual delta.
- The value of "tick" in the kernel is inconsistant with what xntpd is prepared to deal with. Possibly the "tickadj" program can correct this.
Generally, xntpd will perform a series of adjustments to gently slew the clock; it's won't crank in more clock slew per interval than it believe the kernel can actually adjust.
louie
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message