for reasons I have not divined, am unable to setup ntp where ntpd actually works in RH_7.3. It is working fine in SuSE 8.1 and 8.2 according to ntptrace.

In step to simplify, set the drift and keys files to RFC 1305 rather than RH standards (/etc/ntp.drift and /etc/ntp.keys. /etc/ntp.conf on the RH7.3 machine is identical to the one on the working suSE machine. files saved.

Hardware clock set to within 2 seconds of the SuSE machine entrained to a Stratum 1. PING successful to the time server. xntp service stopped and restarted manually.

ntptrace shows no sync to external, using internal time clock.

I need the time sync in order to run LDAP Directory server and a cluster.

something appears to be different in RH vs SuSE. Will send config files to anyone who wants to respond.

melissad@speakeasy.net

Try using 'dateconfig'. RedHat 7.x uses the dateconfig applet to set up the ntp system - it works for me.

Of course that probably doesn't help you much.

Here are the 6 uncommented lines of my NTP file...

server 192.168.1.3
fudge 192.168.1.3 stratum 3
driftfile /etc/ntp/drift
multicastclient
broadcastdelay 0.008
authenticate no

thanks for the reply. been to << dateconfig >> . services stop and start. <<ntpq -p shows they have touched the server with a zero offset and acceptable jitter variance.

<<ntptrace is still showing the following:
desiree: stratum 16, offset 0.00026, sync distance 0.00468
0.0.0.0: Not Synchronized*

am I reading this wrong? Is this merely telling me that the local clock isn't sync'd yet?

Also, if I want this machine to be a time server for the local net (i.e., be the source for the cluster and the Directory Services), do I need a <<multicastserver yes>> line in /etc/ntp.conf? (multicast is configured on eth0)

melissa

NTP will "drift" the clock in partial second increments - so it could perceivably take some time to sync. Your output example is not exactly a format I recognize though.

ntpdate can be used to hard sync (especially usefull on boot).

From what I can tell - the ability to make an ntpd act as a server is dependant upon that server having "peer" entries, and not just "server" entries - but I am not sure of this.

the <<peer>> keyword is indicated in some places in the documentation as providing that functionality to a local subnet (broadcast) or multicast net. In other places, the documentation recommends using the <<server>> keyword for remote (up the chain off-net) servers and <<peer>> to designate local ones.

Of course, these are not mutually exclusive. I will try these settings after sync is attained and post the results here for everyone's info.

I notice that <<ntptrace>> is now giving me some variance in offsets, so it is doing its work.