Help with NTP

[salomon cruz_1]

I´m trying to sync my Tru64 system with a Windows system as local reference clock but after some days my Tru64 is several seconds behind the Windows. I checked the drift file in my Tru64 and always has a 0.000 value.
I have Tru64 5.1B with PK4 running in an Alphaserver GS80 and Windows 2003 server SP1 on the other side in a BL20 G2. Both sistems in the same LAN (same tcpip network)

My ntp.conf:

driftfile /usr/ntp.drift
server int204 version 3

where int204 is my Windows server and its ip address is on the /etc/hosts file

My rc.config file has the following:

XNTPD_OPTS="-g"
export XNTPD_OPTS
TIMED_CONF="NO"
export TIMED_CONF
TIMED_FLAGS=""
export TIMED_FLAGS
XNTPD_CONF="YES"
export XNTPD_CONF
XNTP_SERV1="int204"
export XNTP_SERV1

Any idea to solve this?

Thanks

[Ivan Ferreira]

Did you used sysman ntp to configure the ntp client?

What is the output of:

ntpq -p

[salomon cruz_1]

I didn't use sysman. I did it manually

output of ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
int204.fira.gob .LOCL. 1 u 18 64 377 0.488 9204.37 0.488

[Ivan Ferreira]

It's strange. I think that you should use sysman to configure the client to avoid configurations problems, even when it seems to be good.


If you do ls -la /usr/ntp.drift, when was the file last modified?

[Mark Poeschl_2]

Can you post the contents of your /etc/ntp.conf file?

When your 'offset' value gets high like you show what happens if you stop your NTP daemon and try to adjust the date manually? i.e.

# /sbin/init.d/xntpd stop
# ntpdate -p 1 int204

Windows (at least before 2003) was notoriously bad at running a full-function NTP server. I've never tried doing it on 2003, so perhaps the trolls at Microsoft finally figured it out ;-) On the other hand...

[Al Licause]

Interesting.....I recently spoke with another customer with a similar situation. They used a GS160 and had upgraded to pk4 of v5.1b at the same time they upgraded their console firmware.

Did you upgrade patch levels or your console firmware recently ?

I don't see anything out of place in your configuration. In terms of sysman, if you can get all the peices correctly by hand edits, by all means do so. Sysman is more of a shortcut for those not so comfortable with file editing.

From your ntpq -p output we can see that the client has success fully reached the server each time it's tried but the time has drifted significantly.

I would suggest stopping xntpd, running ntpdate -b {server}, then observe the time ford about a day or so and see how far it drifts from the server.

If it drifts too far and too fast, xntpd will not be able to correct sufficiently to keep it in sync with the server. It would also mean there is more than likely nothing wrong with xntpd.

I suggested the other customer have his system clock replaced.

[Ivan Ferreira]

Also, you should verify your TIMEZONE configuration.

[salomon cruz_1]

# ls -al /usr/ntp.drift
-rw-r--r-- 1 root system 6 Sep 28 12:22 /usr/ntp.drift

As you can see it´s today's date, but:

# more /usr/ntp.drift
0.000

always in 0.000


My /etc/ntp.conf:

# more ntp.conf
#
# XNTPD Configuration File (template for NTP V3)
#
#
# Specify a filename for the driftfile created by xntpd.
# /etc/ntp.drift is the default.
#
driftfile /usr/ntp.drift
#
#
#
#
# Specify several NTP servers and/or peers (See the xntpd documentation
# for recommendations on selecting servers and peers).
# NOTE: Be sure to specify the version number of the server/peer:
#
# peer host1 version 2 # xntpd V2
# server host2 version 1 # ntpd V1
# server host3 version 3 # xntpd V3
#
# For further information on configuration options, see the xntpd
# documentation. If you have a local accurate clock (radio clock, etc),
# you will need to specify further configuration options.
#


#Server and peer configuration

server int204 version 3
# server 127.127.1.0 version 3
# fudge 127.127.1.0 stratum 12
#



Now I tried this (as suggested by Mark):

#
# /sbin/init.d/xntpd stop
#
# date
Wed Sep 28 12:45:06 CDT 2005
#
# ntpdate -p 1 int204
28 Sep 12:45:29 ntpdate[921580]: step time server 10.1.1.204 offset 11.055250 sec
#
# date
Wed Sep 28 12:45:37 CDT 2005
#
# /sbin/init.d/xntpd start
Network Time Service started
#
# ps -fea |grep xntpd
root 921595 524289 0.0 12:46:02 ?? 0:00.02 /usr/sbin/xntpd -g -c /etc/ntp.conf
root 921612 917358 0.0 12:46:21 pts/0 0:00.00 grep xntpd

# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
int204.fira.gob .LOCL. 1 u 15 64 7 0.488 1.000 0.488

Here the reach is 7 and some seconds later same command reports reach=77 and kept growing until 377.

The state now:

# ntpdate -q int204
server 10.1.1.204, stratum 1, offset 0.013125, delay 0.04124
28 Sep 12:55:14 ntpdate[921804]: adjust time server 10.1.1.204 offset 0.013125 sec
#

Lets see tomorrow


By other hand, we recently updated this equipment to PK4 but we have also systems with PK3 with same problem but those are behind a firewall and I would prefer work with this one, the firewall would be another variable.


Last, I checked my zonetime and is correct:

ls -al /etc/zoneinfo/localtime
lrwxrwxrwx 1 root system 21 Apr 28 13:01 /etc/zoneinfo/localtime -> ./America/Mexico_City
#

[Ivan Ferreira]

There is something that I don't really understand, from here:

http://docs.hp.com/en/B2355-90774/ch04s02.html#chbbcgeb

You can see that in the remote column, you can get:

The remote (server name) column depicts the hosts specified in the local host's configuration file plus other hosts that are configured as peers with the local host. The host address can be preceded by the following special characters:

* indicates the current synchronization source.

# indicates that the host is selected for
synchronization, but distance from the host
to the server exceeds the maximum value.

o indicates that the host is selected for synchronization, and the PPS signal is in use.

+ indicates the host included in the final synchronization selection set.

x indicates that the host is the designated false ticker by the intersection algorithm.

. indicates that the host is selected from the end of the candidate list.

- indicates a host discarded by the clustering algorithm.

blank indicates a host is discarded due to high stratum and/or failed sanity checks.



And you have "blank". Does that means that your NTP server is discarded?

[salomon cruz_1]

Ivan, the document you mentioned is HP-UX doc, does it also apply to Tru64?

[Ivan Ferreira]

Yes, it's standard and applies to most/all Unix/Linux NTP versions.

[salomon cruz_1]

We changed to an internet GPS reference and it's working now.

Thanks all for your time.

[salomon cruz_1]

We changed our reference clock to an internet GPS system.