Interpreting NTPQ output

[Bob_Vance]

I should mention that I downloaded and installed the Windows NTP server and it is working fine with an HPUX 11.00 box (with the latest NTP patch), with a setup similar to yours.

bv
hth

[Yogeeraj_1]

hi bob.

thank you for your lengthy reply.

Below a set of actions taken.

1. Latest patch already installed.
==================================
Patch Name: PHNE_24512
Patch Description: s700_800 11.11 NTP timeservices upgrade plus utilities

When installing getting message:
NOTE: The fileset "PHNE_24512.INETSVCS-BOOT,r=1.0" is already
installed. If you wish to reinstall this fileset, change the
"reinstall" option to "true".
* Reading source for file information.
* Executing preDSA command.


2. NTPDATE_SERVER parameter changed
===================================
Before:
######################################
# xntp configuration. See xntpd(1m) #
######################################
#
# Time synchronization daemon
#
# NTPDATE_SERVER: name of trusted timeserver to synchronize with at boot
# (default is rootserver for diskess clients)
# XNTPD: Set to 1 to start xntpd (0 to not run xntpd)
# XNTPD_ARGS: command line arguments for xntpd
#
# Also, see the /etc/ntp.conf and /etc/ntp.keys file for additional
# configuration.
#
export NTPDATE_SERVER=ntptsvr.yd.mu
export XNTPD=1
export XNTPD_ARGS=
###########################################



after:
...
export NTPDATE_SERVER=
export XNTPD=1
export XNTPD_ARGS=
...

3. Carrying tests mentioned above
=================================
# date
Wed Sep 7 08:32:32 GMT 2005
# /sbin/init.d/xntpd stop
ERROR: Unable to stop xntpd (cannot find pid)
# ps -ef|grep ntp
#
# date
Wed Sep 7 08:35:34 GMT 2005
# date 09070836
Wed Sep 7 08:36:00 GMT 2005
# /sbin/init.d/xntpd start
xntpd #
# ps -ef|grep ntp
root 19522 1 0 08:36:32 ? 0:00 /usr/sbin/xntpd
# date
Wed Sep 7 08:43:56 GMT 2005
# ntpq -p
ntpq: read: Can't assign requested address
# date
Wed Sep 7 08:44:19 GMT 2005
#

please advise

regards
yogeeraj

[Bob_Vance]

> # ntpq -p
> ntpq: read: Can't assign requested address

Hmmm. That's not good.I would suspect that xntpd exited.

I ran a test on my HP server:
. killed xntpd
. set the time 6 hours off via 'date'
. restarted xntpd
Got this in the syslog

Sep 7 00:16:50 roger xntpd[18189]: synchronized to 10.1.0.130, stratum=2
Sep 7 00:16:50 roger xntpd[18189]: time error 28265.318427 is way too large (set clock manually)


I would guess that you have the same thing.

So, now I think that we've proved that your problem is *not* particular to 'ntpdate' and that for some reason the two systems really think that they are way out of whack.

Maybe it *is* a time zone thingy.

Did you really set your ZONE to GMT+4 via set_parms?
I don't see a way to do that. I can set it to AST4ADT by selecting options.


(((
BTW, I may have been a little misleading when I said:
"""
# ntpq -p ntptsvr.yd.mu
...
*LOCAL(1) LOCAL(1) 12 l 8h 64 377 0.00 0.000 0.95

This doesn't really tell us anything -- it's just local to ntptsvr.yd.mu.
""""

It *does* verify the state of the server, which is good to know ;>) And the "*" tells us that "ntptsvr.yd.mu" is stable and has settled on his own clock. Of course, this shouldn't change until you restart his NTP. Thus, he will reply to requests from clients. If you see a server with no "*" on any line, then he will not respond to any time requests -- he says "I'm not good enough, yet, to help you".
)))


Also, you didn't answer these questions:
What is 192.168.150.20?
Is that ntptsvr.yd.mu?
What is corp.cmt.mu?


bv

[Bob_Vance]

(BTW, I am running the Meinberg 1370 build.
)

If you set TIMEZONE to GMT+4, then you are not honoring daylight saving time.
Is the windows box set also not to honor daylight saving time?

BTW, where are you actually located?


On my Windows server, I have Microsoft Service for Unix (SFU) installed and also the bash shell. Therefore, I can do a
... date -u
to get UTC time.
Thus, I can verify that the HP box and Windows box both think that it is about the same UTC time (before starting up xntpd).



On HP, I manually have TZ=GMT+4 (and I rebooted just to be positively sure).

On Windows I have normal EDT5EST

on Windows
... bash-2.05b$ date -u ; date
... Wed Sep 7 13:30:05 GMT 2005
... Wed Sep 7 09:30:05 EDT 2005

on HP
... roger ## date -u ; date
... Wed Sep 7 13:30:02 UTC 2005
... Wed Sep 7 09:30:02 GMT 2005

(I purposely have them off a few seconds
so we can see NTP get them in sync.
)

I started up xntpd and watched it get in sync with a while loop on 'ntpq -p':

====================================
atlanta.cnetics tock.usnogps.na 2 - 58 32 0 0.69 4751.10 16000.0
remote refid st t when poll reach delay offset disp
====================================
atlanta.cnetics tock.usnogps.na 2 u 5 32 1 0.72 -3.892 15875.0
remote refid st t when poll reach delay offset disp

atlanta.cnetics tock.usnogps.na 2 u 31 32 17 0.76 -3.909 1875.05
remote refid st t when poll reach delay offset disp
====================================
*atlanta.cnetics tick.usnogps.na 2 u 10 32 37 0.72 -3.880 875.03
remote refid st t when poll reach delay offset disp
====================================
*atlanta.cnetics tick.usnogps.na 2 u - 32 77 0.70 -2.436 376.42
remote refid st t when poll reach delay offset disp
====================================
*atlanta.cnetics tick.usnogps.na 2 u 1 32 177 0.70 -1.456 126.68
remote refid st t when poll reach delay offset disp
====================================
*atlanta.cnetics tick.usnogps.na 2 u 15 32 377 0.70 -0.061 0.14
remote refid st t when poll reach delay offset disp



Now, I set to GMT+3.
HP:
roger ## date -u ; date
Wed Sep 7 13:51:44 UTC 2005
Wed Sep 7 10:51:44 GMT 2005

Win:
bash-2.05b$ date -u ; date
Wed Sep 7 13:51:44 GMT 2005
Wed Sep 7 09:51:44 EDT 2005

Notice how they are in sync because of NTP.
Notice that the local time is diff by one hour, as expected.


stopped xntpd.


Now, I will set the time off by a couple of seconds.

bash-2.05b$ date -u ; date
Wed Sep 7 13:55:44 GMT 2005
Wed Sep 7 09:55:44 EDT 2005

roger ## date -u ; date
Wed Sep 7 13:55:46 UTC 2005
Wed Sep 7 10:55:46 GMT 2005


Now, restart xntpd and monitor:

atlanta.cnetics tick.usnogps.na 2 - 306 32 0 0.69 -1261.4 16000.0
remote refid st t when poll reach delay offset disp
====================================
atlanta.cnetics tick.usnogps.na 2 u 25 32 1 2.20 -2.074 15875.0
remote refid st t when poll reach delay offset disp
====================================
atlanta.cnetics tick.usnogps.na 2 u 26 32 7 0.72 -1.345 3877.12
remote refid st t when poll reach delay offset disp
====================================
*atlanta.cnetics tick.usnogps.na 2 u 8 32 77 0.85 -0.952 375.66
remote refid st t when poll reach delay offset disp
====================================
*atlanta.cnetics tick.usnogps.na 2 u 18 32 377 0.76 -0.217 0.32
remote refid st t when poll reach delay offset disp




Again, HP gets in sync.
So, there appears to be no bug on the HP side.

I think that you need to somehow verify that the Win box and the HP box both show (approx) the same *UTC* time before you start xntpd.


hth
bv

[Yogeeraj_1]

Dear bv,

thank you for all the tests that you performed at your site for helping me. Still no success here!:

============================================================================
Your question: Did you really set your ZONE to GMT+4 via set_parms?
I don't see a way to do that. I can set it to AST4ADT by selecting options.
============================================================================

# set_parms timezone
_______________________________________________________________________________

The following procedure enables you to set the time zone.

Select your location from the following list:

1) North America or Hawaii

2) Central America

3) South America

4) Europe

5) Africa

6) Asia

7) Australia, New Zealand
_______________________________________________________________________________


Enter the number for your location (1-7) then press [Enter] 5
_______________________________________________________________________________

Select your time zone from the following list:

1) Northwest Africa, Morocco, Mauritania, Mali

2) Algeria, West Central Africa, Chad, Angola, Congo

3) Egypt, Sudan, Zaire, Central Africa

4) Eastern Africa, Kenya, Ethiopia

5) Republic of South Africa

6) Unlisted time zone

7) Previous menu

_______________________________________________________________________________

Enter the number for your time zone (1 - 7), then press [Enter] 6


_______________________________________________________________________________


An unlisted time zone must consist of zero or more characters followed
by a number (for example: abc-3, xyz+10). The number represents the
number of hours your time is offset from Coordinated Universal Time (CTU),
also known as Greenwich Mean Time (GMT) at zero degrees longitude.

A positive number is the number of hours west of CTU; a negative number
is the number of hours east of CTU. You may specify hours and minutes
offset from CTU by separating the hours and minutes with a colon (:).
For example: abc10:30 would be 10 hours 30 minutes west of CTU.

_______________________________________________________________________________


Enter the time zone for your location, then press [Enter] GMT+4



============================================================================
Your Question: Is the windows box set also not to honor daylight saving time?
============================================================================
We don't have this in our region.
I am in the Indian Ocean. A place call Mauritius.



also. this is what show my timezone file:
# more TIMEZONE
TZ=GMT+4
export TZ
#


what should do next?

thank you in advance for your reply

kind regards
yogeeraj

[David P. Goodsell]

You're in the Indian Ocean !!!

Your time zone should be GMT-4 !!!!

Not GMT+4


That would explain the 8 hour difference!!!


hth
bv

[Bob_Vance]

OOOOPS
no points for the previous post!!!
I had the wrong login ID.

bv

[Bob_Vance]

((
I knew Geography class would pay off some day ;>)
))

bv

[Yogeeraj_1]

hi bv,

unfortunately, we cannot rollback the points!

anyway, Why should it be GMT-4?

We have always been using GMT+4 and the time server also has time zone set as GMT+4

8 hours ahead - this was something i had already observed.

please clarify!

thank you in advance for your reply

kind regards
yogeeraj

[Bob_Vance]

The GMT offset is what must be *added* to your local time to give GMT time.

In your case, you're top the "right", "east", "ahead", whatever, of Greenwich, so to get GMT time you must *subtract* 4 hours from your time.

I.e., if it is 17:00 in Mauritius, then it is only 13:00 in London.

hth
bv

[Bob_Vance]

BTW,
You can the the "negative effect" if you use 'set_parms timezone' and pick, say, Africa/Ethiopia -- you'll see that it has a negative offset (just say "no" to the question "is it correct?" and then ctl-c to kill it).

hth
bv

[Yogeeraj_1]

Dear bv,

thank you for your observations. It is really strange because on the windows-based server we use gmt+4 while here we have to specify gmt-4

i initially thought that due to this difference, my time servers might not be functioning properly. Hence, the idea of setting the time zone and adjusting the time accordingly!

i will try to set the time zone to gmt-4 and continue my tests.

will update this thread asap.

kind regards
yogeeraj

ps. Bob vance: many congratulations for your new hat. see: http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=955645

[Bob_Vance]

yogeeraj,

did you ever check this out?

I had very much trouble with the Meinberg NTP running on a couple of active directory controllers. Never would sync up right with anything! Always ended up with LOCAL as the source. Unix boxes couldn't sync with them, even after a long time.

Running on just standalone Win2k and Win2k3 servers seemed to work right (except that 'ntpdate' on them would not work).


bv