"ohaya" <ohaya@yahoo.com> wrote in message
news:1116608567.353501.319280@g47g2000cwa.googlegr oups.com...
> John,
>
> Followup to my earlier post about "no server to synchronize..." error.
>
>
> After going back to the lab, I did another ntpdate, and was surprised
> that this time it worked, even tho no changes.
>
> Does xntpd take awhile (maybe a couple of minutes) to get to the point
> that it will respond to requests from other systems??? Seems like it
> (xntpd) doesn't "talk" for awhile after it starts?

Well, I may not have expressed it too clearly, but I did note that
>>
on the clients the
ntp daemon itself will not be started start until ntpdate completes, which
requires the server has locally synchronized so that ntpdate on the client
can
get the time from it, which takes about 5 or 6 minutes.
<<

Basically, the standard Solaris NTP software goes through a two-stage
sequence if you use the standard /etc/rc* scripts to start it:

1 use ntpdate to quickly get the clock within the 128ms ntp expects
2 use the ntp daemon to really get things going properly

It must complete step 1 before moving on to step 2, so if the system
providing the source of time for ntpdate is not yet itself synchronized
ntpdate will wait, and the daemon will only start when it completes.

Once ntpdate has completed it takes about five or six minutes for the daemon
to synchronize, whether that be to its own hardware in the case of your
"server" (Solaris1) or to that system for your other three "client" systems.

The default minimum polling interval always starts at 64 seconds (it can go
up to a default maximum of 1024 seconds in powers of 2 as it thinks things
are stable enough to allow it), and it takes five or six samples at 64
second intervals before the daemon is confident it knows what is going on.
During this time it works out the difference in frequency and stability
between its local clock and that of the source of time data.

If you stop and start the ntp software on Solaris1 and use "ntpq -p" to
monitor it you will have to wait about six minutes before the '*' appears to
show it is in sync. Only then will the other servers see the time as valid
and start their synchronization, which will itself take at least a further
six minutes, and possibly up to five minutes longer depending on exactly
where in the ntp startup sequence the client has reached when the server
finally offers it time data.

With NTP you have to be patient. It's about long term stability and
accuracy, not instant gratification!

Each hour the ntp software will update the "ntp.drift" file (in the example
files) with the clock error, so that next time the daemon runs it has a clue
as to where things should start.

John Howells