ntpdate / ntpd

In the data centre, I have about 8 SPARCs running Solaris8.
Each of them are running ntpdate via cron every 10 minutes.
The NTP server used is internal to the data centre, which then
synchronises its time with external NTP servers in the internet.

I have 1 linux box, running RH 7.2, using ntp from RH 7.3. The time on
this box is advanced by 1 minute and a few seconds compared to the
SPARCs. The file /etc/ntp.conf has the server line point to the internal
NTP server, like this:

server 10.0.10.37


Restarted ntpd ( /etc/rc.d/init.d/ntp stop; /etc/rc.d/init.d/ntp start
). Now after one day, the time on the linux box is still not in sync
with the rest of my boxes, the SPARCs, and ntpd is still running.

Of course, if I run ntpdate 10.0.10.37, then the time on the linux box
is "corrected" and in sync with the rest.

So question is, why ntpd did not ( or take a long time ) to "correct"
the time ?

"noone" <(E-Mail Removed)> wrote in message
news0Tub.18224$(E-Mail Removed)

> In the data centre, I have about 8 SPARCs running Solaris8.
> Each of them are running ntpdate via cron every 10 minutes.
> The NTP server used is internal to the data centre, which then
> synchronises its time with external NTP servers in the internet.
>
> I have 1 linux box, running RH 7.2, using ntp from RH 7.3. The time on
> this box is advanced by 1 minute and a few seconds compared to the
> SPARCs. The file /etc/ntp.conf has the server line point to the
> internal NTP server, like this:
>
> server 10.0.10.37
>
>
> Restarted ntpd ( /etc/rc.d/init.d/ntp stop; /etc/rc.d/init.d/ntp start
> ). Now after one day, the time on the linux box is still not in sync
> with the rest of my boxes, the SPARCs, and ntpd is still running.
>
> Of course, if I run ntpdate 10.0.10.37, then the time on the linux box
> is "corrected" and in sync with the rest.
>
> So question is, why ntpd did not ( or take a long time ) to "correct"
> the time ?

If the system clock is "off" by some substantial amount of time from the
ntpd server, then it is necessary to run ntpdate initially to close the gap
to an amount that can then be handled by ntpd. It's not clear why you're
using an ntpdate cron job on the Solaris machines, but ntpd on the Linux.

I just use an hourly cron job, and then sync the hardware BIOS clock too:

23 * * * * ( /usr/sbin/ntpdate 10.0.10.37; /usr/sbin/hwclock --systohc ) \
> /dev/null 2>&1


tony

--
use hotmail for any email replies



-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

"noone" <(E-Mail Removed)> wrote in message
news0Tub.18224$(E-Mail Removed)...
>
> In the data centre, I have about 8 SPARCs running Solaris8.
> Each of them are running ntpdate via cron every 10 minutes.
> The NTP server used is internal to the data centre, which then
> synchronises its time with external NTP servers in the internet.
>
> I have 1 linux box, running RH 7.2, using ntp from RH 7.3. The time on
> this box is advanced by 1 minute and a few seconds compared to the
> SPARCs. The file /etc/ntp.conf has the server line point to the internal
> NTP server, like this:
>
> server 10.0.10.37
>
>
> Restarted ntpd ( /etc/rc.d/init.d/ntp stop; /etc/rc.d/init.d/ntp start
> ). Now after one day, the time on the linux box is still not in sync
> with the rest of my boxes, the SPARCs, and ntpd is still running.
>
> Of course, if I run ntpdate 10.0.10.37, then the time on the linux box
> is "corrected" and in sync with the rest.
>
> So question is, why ntpd did not ( or take a long time ) to "correct"
> the time ?

IMHO, the proper method is to initially sync at boot with ntpdate and let
ntpd then handle the rest. ntpd is better than a cron job, as it prevent
sudden time jumps and uses slow slewing instead so that no process will ever
see time reversing or jumping. Also, ntpd adjusts the poll rate to a
suitably sparse rate as soon as it is sure for a good sync.

The Solaris thingies should also use NTP. Now, at each cron time they risk a
time jump.

For a local network with limited delay, a solution could also be broadcast
NTP from the local server, e.g. at 20 min intervals. However, with less than
hundreds of clients, even a server behind 10 Mbit/s cable can well handle
standard NTP.

For more information of NTP, go to <http://www.ntp.org/>.

HTH

Tauno Voipio
tauno voipio @ iki fi