I am setting up a solaris 8 server as an v3 ntp client (using public ntp servers). I can change the date and time and then start xntpd daemon with the start script and the time sets to the correct time.
When I issue the "date" command, setting the clock back 10 minutes, the time doesn't seem to get set.
I do not use the ntpdate command, although the start script issues it one time first.
Why doesn't the time reset after the date command is issued.
Thank you
These are the messages when I execute the startup scripts
[ID 558275 daemon.notice] adjust time server 208.184.49.9 offset 0.016220 sec
[ID 702911 daemon.notice] xntpd 3-5.93e Mon Sep 20 15:47:11 PDT 1999 (1)
[ID 301315 daemon.notice] tickadj = 5, tick = 10000, tvu_maxslew = 495, est. hz = 100
[ID 798731 daemon.notice] using kernel phase-lock loop 0041
#
These are the messages from the log file
3 Apr 15:33:51 xntpd[931]: read drift of 6.785 from /etc/inet/ntp.drift
3 Apr 15:33:51 xntpd[931]: using kernel phase-lock loop 0041
3 Apr 15:38:08 xntpd[931]: synchronized to 208.184.49.9, stratum=1
3 Apr 15:38:14 xntpd[931]: synchronized to 129.6.15.29, stratum=1
3 Apr 15:38:17 xntpd[931]: synchronized to 64.236.96.53, stratum=1
3 Apr 15:39:12 xntpd[931]: synchronized to 129.6.15.28, stratum=1
3 Apr 15:39:18 xntpd[931]: synchronized to 129.6.15.29, stratum=1
3 Apr 15:41:21 xntpd[931]: synchronized to 129.6.15.28, stratum=1
3 Apr 15:41:24 xntpd[931]: synchronized to 132.163.4.101, stratum=1
3 Apr 15:41:27 xntpd[931]: synchronized to 207.200.81.113, stratum=1
3 Apr 15:44:21 xntpd[931]: synchronized to 129.6.15.29, stratum=1
3 Apr 15:44:55 xntpd[931]: synchronized to 64.236.96.53, stratum=1
3 Apr 15:45:25 xntpd[931]: synchronized to 129.6.15.28, stratum=1
3 Apr 15:45:59 xntpd[931]: synchronized to 129.6.15.29, stratum=1
3 Apr 15:51:42 xntpd[931]: synchronized to 208.184.49.9, stratum=1
3 Apr 15:51:49 xntpd[931]: synchronized to 69.25.96.13, stratum=1
3 Apr 15:51:50 xntpd[931]: synchronized to 68.216.79.113, stratum=1
3 Apr 15:52:01 xntpd[931]: synchronized to 129.6.15.28, stratum=1
3 Apr 15:53:28 xntpd[931]: synchronisation lost
3 Apr 15:55:34 xntpd[931]: synchronized to 129.6.15.28, stratum=1
3 Apr 15:56:06 xntpd[931]: synchronisation lost
3 Apr 15:56:46 xntpd[931]: synchronized to 69.25.96.13, stratum=1
#
---------------------------------
8:00? 8:25? 8:40? Find a flick in no time
with theYahoo! Search movie showtime shortcut.
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions
|
|
0
|
|
|
|
Reply
|
csgonan
|
4/3/2007 8:06:55 PM |
|
Christine Ross wrote:
> I am setting up a solaris 8 server as an v3 ntp client (using public ntp servers). I can change the date and time and then start xntpd daemon with the start script and the time sets to the correct time.
>
> When I issue the "date" command, setting the clock back 10 minutes, the time doesn't seem to get set.
>
> I do not use the ntpdate command, although the start script issues it one time first.
>
> Why doesn't the time reset after the date command is issued.
>
> Thank you
<snip>
It's a little less than clear what you hoped to accomplish by this and
not even clear what you actually accomplished. I'll assume that you
succeeded in setting your clock by by ten minutes and that you are
wondering why ntpd (not xntpd for many years now BTW, the version that
ships with Solaris seems to be about ten or twelve years behind the
times) did not immediately correct your clock.
Ntpd will not "jump" your clock! After you miss-set your clock by 600
seconds, ntpd will attempt to correct your clock at its maximum slew
rate of 500 Parts Per Million or 1/2 millisecond per second.
Calculating how long the correction will take is left as an exercise for
the student. If you had made a change of a little over seventeen
minutes ntpd would have taken a "panic exit" and not corrected your
clock at all.
BTW, it is customary to use your return key when you type your message
rather than enter a whole paragraph as a single line which is how your
message came through. Seventy-two characters is a good line length that
can be read easily on most displays.
|
|
0
|
|
|
|
Reply
|
Richard
|
4/4/2007 11:23:40 PM
|
|
Christine Ross <csgonan@yahoo.com> wrote:
> I am setting up a solaris 8 server as an v3 ntp client (using public ntp servers). I can change the date and time and then start xntpd daemon with the start script and the time sets to the correct time.
>
> When I issue the "date" command, setting the clock back 10 minutes, the time doesn't seem to get set.
You're saying the 'date' command doesn't work or that xntpd isn't
resetting it back correctly?
If the first, that's odd.
If the second, then you need to wait longer. The clock isn't supposed
to jump suddenly, so the ntp daemon isn't designed to correct such
issues.
> I do not use the ntpdate command, although the start script issues it one time first.
>
> Why doesn't the time reset after the date command is issued.
How about when you run ntpdate by hand? Does that work? Any output?
How about when you run it in debug mode?
> Thank you
>
> These are the messages when I execute the startup scripts
>
> [ID 558275 daemon.notice] adjust time server 208.184.49.9 offset
> 0.016220 sec
This says that the clock was basically correct when ntpdate was run.
Are you sure the clock is off?
What does 'ntpq -p' report?
--
Darren Dunham ddunham@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >
|
|
0
|
|
|
|
Reply
|
Darren
|
4/4/2007 11:28:09 PM
|
|
>>> In article <492977.28238.qm@web58512.mail.re3.yahoo.com>, csgonan@yahoo.com (Christine Ross) writes:
Christine> I am setting up a solaris 8 server as an v3 ntp client (using
Christine> public ntp servers). I can change the date and time and then
Christine> start xntpd daemon with the start script and the time sets to the
Christine> correct time. When I issue the "date" command, setting the clock
Christine> back 10 minutes, the time doesn't seem to get set.
If ntpd is running at the time you change the time with 'date', that's
probably your problem.
ntpd expects that it is the only thing messing with your clock.
I suspect that if you run the date command and then wait a while, you will
see ntpd fix things. And it may take a while, depending on what
configuration and/or command line options you used.
H
|
|
0
|
|
|
|
Reply
|
Harlan
|
4/5/2007 12:02:42 AM
|
|
In article <4614337C.3070500@comcast.net>,
Richard B. gilbert <rgilbert88@comcast.net> wrote:
> It's a little less than clear what you hoped to accomplish by this and
Making gross changes to the clock on a running machine is how people
think they can test that ntpd is synchronising the clock, when what they
should really be testing is the ability to track to 10ms, rather than
the ability to cope with bad operator training or hardware that is only
suitable for the scrapheap.
> wondering why ntpd (not xntpd for many years now BTW, the version that
I believe he really is using xntpd, not the version of ntpd that is misnamed
as such. Obviously he should upgrade.
> Ntpd will not "jump" your clock! After you miss-set your clock by 600
Normal configurations of ntpd will jump the clock if the error exceeds 128 ms,
but some vendors choose to set it into a slew only mode. (The jump follows
a sanity check that takes around quarter of an hour.)
> seconds, ntpd will attempt to correct your clock at its maximum slew
> rate of 500 Parts Per Million or 1/2 millisecond per second.
plus/minus the actual hardware clock frequency error!
|
|
0
|
|
|
|
Reply
|
david
|
4/5/2007 6:52:00 AM
|
|
|
4 Replies
209 Views
(page loaded in 3.109 seconds)
|