Interpreting NTPQ output

[Yogeeraj_1]

Dear experts!

I recently has a thread which permitted me to troubleshoot my timeserver problem (http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=947300).
Unfortunately, i am still not at ease with the ntp command and outputs.

As such, can any one please help me interprete the output produced when i run the ntpq command on my server?

Note that, i was previously using time zone GMT04:00 which i have just change to GMT+4 (using set_parms timezone) after which i also had to correct the current time using set_parms datetime.

Below the current output of the "ntpq" command:
# ntpq -p
remote refid st t when poll reach delay offset disp
==============================================================================
*LOCAL(1) LOCAL(1) 10 l 28 64 377 0.00 0.000 10.01
ntptsvr.yd.mu LOCAL(1) 13 u 75 256 377 4.87 -286550 1.46
# date
Thu Sep 1 10:21:49 GMT 2005
# echo $TZ
GMT+4
#

thanking you in advance for all your replies.

kind regards
yogeeraj

[Steve Steel · Accepted solution]

Hi

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


table 4.7


Steve Steel

[Alessandro Pilati]

Yogeeraj,
these are some explanation of the output:

REMOTE=the localhost plus peers hosts specified in the configuration files, from which your host will take time sinchronization

Charachter that may be before hostname:
* 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.


REFID=the current source of synchronization for the remote host

STRATUM=the stratum level of the remote host

T=types available
l local (such as a GPS clock)

u unicast (this is the common type)

m multicast

b broadcast

- netaddr (usually 0)

WHEN=number of seconds passed since the remote host response

POLL=polling interval to the remote host, defined with the "minpoll" value in ntp.conf file

REACH=indicates how successful attempts to reach the server are. This is an 8-bit shift register with the most recent probe in the 2^0 position. The value 001 indicates the most recent probe was answered, while 357 indicates one probe was not answered. The value 377 indicates that all the recent probes have been answered.

DELAY= (round trip time) indicates the time (in milliseconds) taken by the reply packet to return in response, to a query sent by the server.

OFFSET=indicates the time difference (in milliseconds) between the server's clock and the client's clock. When this number exceeds 128, and the message synchronization lost appears in the log file

DISP=indicates the difference in the offset measurement between two samples. This is an error-bound estimate. The dispersion is a primary measure of the network service quality.


Hope this helps.
Rgds,
Alex

[Alessandro Pilati]

Take also these other links:

http://docs.hp.com/en/B2355-90774/ch04s03.html

http://www.meinberg.de/english/info/ntp.htm#ntp_status

http://www.lnf.infn.it/computing/Unix/ntp/debug.html

Regards,
Alex

[Yogeeraj_1]

hi,

thank you all for your quick responses, can anyone help me clarify the following line:
LOCAL(1)
13
u
605
1024
377
4.79
-286549
19.39

(nb. translated to vertical for clarity)

thanking you in advance

kind regards
yogeeraj

[Alessandro Pilati]

LOCAL(1) Indicates your localhost
13 is the stratum of one of the servers to contact for synchronization, the lower the better, 1=primary...16=not synchronized ( the server must be at lower or equal stratum than client, to avoid loops in configuration )
u is the type of server, in your case is UNICAST
605 time passed since the last interrogation of this server ( in seconds )
1024 is the poll value, the interval between the interrogations
377 reachability of the last 8 interrogation ( 377 means that all the last 8 responses from the server have been correctly received )
4.79 Delay of propagation ( MUST BE < 16, otherwise your xntpd consider the server unaffordable, so 4,79 is OK )
-286549 Difference from the local time
19.39 Time of dispersion of the last 8 interrogation


Anyway,
here it is a SUPER document about NTP.
Take care of it

http://www.sun.com/blueprints/0901/NTPpt3.pdf

Hope all it helped you

Regards,
Alex

[Yogeeraj_1]

hi again,

seems like my server is not synchronising with my time server. am i right?

below some observations:

# ntpq -p
remote refid st t when poll reach delay offset disp
==============================================================================
*LOCAL(1) LOCAL(1) 10 l 21 64 377 0.00 0.000 10.01
ntptsvr.yd.mu LOCAL(1) 13 u 901 1024 367 5.52 -286544 13.66

# ntpq -p ntptsvr.yd.mu
remote refid st t when poll reach delay offset disp
==============================================================================
*LOCAL(1) LOCAL(1) 12 l 8h 64 377 0.00 0.000 0.94
#


attaching txt file for a better formatted output.

your comments would be most appreciated.

Kind regards
yogeeraj

[Alessandro Pilati]

OK,
verify if the server ntp is failing in authentication:

Run:
xntpdc
at the "xntpdc>" prompt run:
pstats

And post the output ( Bad authentication should be 0 )

[Yogeeraj_1]

hi,
below the output you requested:
# xntpdc
xntpdc> pstats ntptsvr.yd.mu
remote host: ntptsvr.yd.mu
local interface: x.x.x.x
time last received: 311s
time until next send: 713s
reachability change: 98152s
packets sent: 109
packets received: 108
bad authentication: 0
bogus origin: 0
duplicate: 0
bad dispersion: 8
bad reference time: 0
candidate order: 0
xntpdc>

regards
yogeeraj

[Alessandro Pilati]

Authentication is ok.
But you host is using itself as the ntp source.

Check if you did this procedure to enable ntp client:

/sbin/init.d/xntp stop
cd /etc/rc.config.d
vi netdaemons

export NTPDATE_SERVER=node name
export XNTPD=1

then run:
ntpdate
/sbin/init.d/xntp start

Wait 10 mins, run ntpq -p again to check the status.

[Alessandro Pilati]

Check also if your server is reachable:
ntpq -p ntpsrv.yd.mu
and
ntptrace

[Yogeeraj_1]

hi,
thank you for your reply.

below the output after running the commands you requested above!

============================================
# ntpdate ntptsvr.yd.mu
2 Sep 07:43:55 ntpdate[8066]: step time server 192.168.150.20 offset -28654.202762 sec
#

# ./xntpd start
2 Sep 07:45:09 ntpdate[8155]: step time server 192.168.150.20 offset -0.008408 sec
xntpd # date
Fri Sep 2 07:45:42 GMT 2005
# ntpq -p
remote refid st t when poll reach delay offset disp
==============================================================================
LOCAL(1) LOCAL(1) 10 l 8 64 3 0.00 0.000 7885.01
ntptsvr.yd.mu LOCAL(1) 13 u 39 64 1 5.97 -1.288 15875.0
# date
Fri Sep 2 07:50:28 GMT 2005
# date
Fri Sep 2 08:03:49 GMT 2005
# ntpq -p
remote refid st t when poll reach delay offset disp
==============================================================================
*LOCAL(1) LOCAL(1) 10 l 15 64 377 0.00 0.000 10.01
ntptsvr.yd.mu LOCAL(1) 13 u 1 1024 377 4.90 7.982 3.95

# ntpq -p ntptsvr.yd.mu
remote refid st t when poll reach delay offset disp
==============================================================================
*LOCAL(1) LOCAL(1) 12 l 58 64 377 0.00 0.000 0.92
# ntptrace
localhost: stratum 11, offset 0.000063, synch distance 0.01038
127.127.1.1: *Timeout*
# ntptrace ntptsvr.yd.mu
ntptsvr.yd.mu: stratum 13, offset 0.004179, synch distance 0.01114
127.127.1.1: *Timeout*
# date
Fri Sep 2 08:12:38 GMT 2005
#

===========================================
attached a less garbled output

My date has gone totally ashtray now instead of 16:12 it is showing me 08:12

what's wrong?

thanking you in advance for your reply.

kind regards
yogeeraj

[Alessandro Pilati]

Yogeeraj, check what I did on my server:

# ntptrace -v -d idats1
DoTransmit(10.115.0.3)
DoTransmit to 10.115.0.3
ReceiveBuf(10.115.0.3, 10.115.0.3)
server 10.115.0.3, port 123
stratum 4, precision -11, leap 00
refid 127.127.1.0 delay 0.00027, dispersion 0.00000 offset 21426.566123
rootdelay 0.00000, rootdispersion 0.01120, synch dist 0.01120
reference time: c6c2c67c.b99a3000 Fri, Sep 2 2005 14:39:24.725
originate timestamp: c6c2c690.bf5a3000 Fri, Sep 2 2005 14:39:44.747
transmit timestamp: c6c272de.2e637000 Fri, Sep 2 2005 8:42:38.181

DoTransmit(127.127.1.0)
DoTransmit to 127.127.1.0
# ntpdate idats1
2 Sep 14:40:00 ntpdate[9117]: step time server 10.115.0.3 offset 21426.566051 sec

# ntptrace -v -d idats1
DoTransmit(10.115.0.3)
DoTransmit to 10.115.0.3
ReceiveBuf(10.115.0.3, 10.115.0.3)
server 10.115.0.3, port 123
stratum 4, precision -11, leap 00
refid 127.127.1.0 delay 0.00038, dispersion 0.00000 offset -0.010414
rootdelay 0.00000, rootdispersion 0.01141, synch dist 0.01141
reference time: c6c2c67c.b99a3000 Fri, Sep 2 2005 14:39:24.725
originate timestamp: c6c2c6a3.c15a3000 Fri, Sep 2 2005 14:40:03.755
transmit timestamp: c6c2c6a3.c3f7d000 Fri, Sep 2 2005 14:40:03.765

DoTransmit(127.127.1.0)
DoTransmit to 127.127.1.0



With ntptrace I saw that I had a time setted to 8:42:38, but after ntpdate, the time has sinchronized to "idats1" time ( my timeserver ) to 14.40.03


Try "ntptrace -d -v ntptsvr.yd.mu"
so we can see if the time server has the correct hour.

Then try to launch again ntpdate ntptsvr.yd.mu

[Yogeeraj_1]

Hi Alessandro,

Thank you for your reply.

here is what i am getting now!
# date
Fri Sep 2 09:16:14 GMT 2005

# ntptrace -d -v ntptsvr.yd.mu
DoTransmit(ntptsvr.yd.mu)
DoTransmit to ntptsvr.yd.mu
ReceiveBuf(ntptsvr.yd.mu, ntptsvr.yd.mu)
server ntptsvr.yd.mu, port 123
stratum 13, precision -20, leap 00
refid 127.127.1.1 delay 0.00493, dispersion 0.00000 offset 0.046830
rootdelay 0.00000, rootdispersion 0.01128, synch dist 0.01128
reference time: c6c2cf3b.e003ff69 Fri, Sep 2 2005 9:16:43.875
originate timestamp: c6c2cf54.94e453d2 Fri, Sep 2 2005 9:17:08.581
transmit timestamp: c6c2cf54.88425000 Fri, Sep 2 2005 9:17:08.532

DoTransmit(127.127.1.1)
DoTransmit to 127.127.1.1
ReceiveBuf(127.127.1.1, 127.0.0.1)
receive: wrong server
DoTransmit(127.127.1.1)
DoTransmit to 127.127.1.1
ReceiveBuf(127.127.1.1, 127.0.0.1)
receive: wrong server
DoTransmit(127.127.1.1)
DoTransmit to 127.127.1.1
ReceiveBuf(127.127.1.1, 127.0.0.1)
receive: wrong server
DoTransmit(127.127.1.1)
DoTransmit to 127.127.1.1
ReceiveBuf(127.127.1.1, 127.0.0.1)
receive: wrong server
DoTransmit(127.127.1.1)
DoTransmit to 127.127.1.1
ReceiveBuf(127.127.1.1, 127.0.0.1)
receive: wrong server
127.127.1.1: *Timeout*
#
# date
Fri Sep 2 09:17:46 GMT 2005
#

What is wrong now?

a time zone problem?
on my hp-ux server, it it
# echo $TZ
GMT+4

and on my windows time server, it is also set to GMT+4

any more insights?

kind regards
yogeeraj

PS. if i don't reply, it means that it is already 6pm and i have left office, will followup tomorrow morning. Have nice weekend.

[Florian Heigl (new acc)]

let me first answer the second question, as it's the easier one :)

the timezone is not an issue, ntp does all transfers fixed to UTC.

first one:
DoTransmit(127.127.1.1)
DoTransmit to 127.127.1.1
ReceiveBuf(127.127.1.1, 127.0.0.1)
receive: wrong server
127.127.1.1: *Timeout*

now, You're server is talking to itself, but is (I think) not correctly specified in ntp.conf. guessing by the stratum of 13 this is the failback to the local system clock, but it appears to have a problem.

Your definition should be no more than:
# server 127.127.1.1
# fudge 127.127.1.1 stratum 13

can You please compare it?

[Alessandro Pilati]

Yogeeraj,
127.127.1.1 is not an IP address, but a Magic Number that indicates ntp client to refer to himself.

You should post your ntp.conf file to let our ideas more clear about the situation.

Thank you,
Alex

[Yogeeraj_1]

Dear all,

thank you for your replies.

The last few lines of my /etc/ntp.conf (full file attached) are as follows:
=============================
broadcastclient no
server 127.127.1.1
fudge 127.127.1.1 stratum 10
driftfile /etc/ntp.drift
authenticate no
server ntptsvr.yd.mu version 3
=============================

which i have modified to:
=============================
broadcastclient no
#server 127.127.1.1
#fudge 127.127.1.1 stratum 10
driftfile /etc/ntp.drift
authenticate no
server ntptsvr.yd.mu version 3
=============================
and ran the following commands:

# ./xntpd stop
xntpd stopped
# ./xntpd start
3 Sep 00:33:09 ntpdate[26213]: step time server 192.168.150.20 offset 0.457739
sec
xntpd # ntpq -p
remote refid st t when poll reach delay offset disp
==============================================================================
corp.cmt.mu 0.0.0.0 16 - - 64 0 0.00 0.000 16000.0
#
# ntpdate ntptsvr.yd.mu
3 Sep 00:34:37 ntpdate[26221]: the NTP socket is in use, exiting

# date 09030836
Sat Sep 3 08:36:00 GMT 2005
#

===================
restarted server
===================
# date
Sat Sep 3 08:47:12 GMT 2005
# ntpq -p
ntpq: read: Can't assign requested address
# ntpq -p ntptsvr.yd.mu
remote refid st t when poll reach delay offset disp
==============================================================================
*LOCAL(1) LOCAL(1) 12 l 8h 64 377 0.00 0.000 0.95
# ntpdate ntptsvr.yd.mu
3 Sep 00:50:32 ntpdate[1517]: step time server ntptsvr.yd.mu offset -28661.098
925 sec
# ntpq -p ntptsvr.yd.mu
remote refid st t when poll reach delay offset disp
==============================================================================
*LOCAL(1) LOCAL(1) 12 l 45 64 377 0.00 0.000 0.95
# ntpq -p
ntpq: read: Can't assign requested address
# date
Sat Sep 3 00:51:16 GMT 2005
#

my time is again late by 8 hours again!

kind regards
yogeeraj

[Bob_Vance]

>seems like my server is not synchronising with my time server. am i right?

You will notice from the first output:

*LOCAL(1) LOCAL(1) 10 l 28 64 377 0.00 0.000 10.01
ntptsvr.yd.mu LOCAL(1) 13 u 7

That "ntptsvr.yd.mu" is also using its LOCAL time, but at stratum 13.
Since you specified stratum 10 for this server and 10 is better than 13, that's why it is using its own LOCAL time.

It appears that "ntptsvr.yd.mu" is not a real NTP server -- at least it has no access to a real server or is having problems accessing one.

If "ntptsvr.yd.mu" is simply another internal box that has been designated as the master time, but is not really accessing an external, "real" NTP server, then I would set its LOCAL stratum to something better than 13, say 7. This is just as an indicator that it's kinda special.

Then, for other boxes using "ntptsvr.yd.mu", simply take out the LOCAL spec (which you finally did here) or be sure that that the fallback stratum is worse (greater) than 7.

What do you know about "ntptsvr.yd.mu" ?
Are you sure that its LOCAL time is correct?

hth
bv

[Yogeeraj_1]

Dear bv,

Your Question: What do you know about "ntptsvr.yd.mu" ?
My Answer:
I downloaded "NTP for Windows NT/2000/XP"
from:
http://www.meinberg.de/download/ntp/windows/ntp-4.2.0a@1.1354-o-win32-set
up.exe

(see my previous thread that i create during my initial installation/configuration: http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=947300 )


Your Question: Are you sure that its LOCAL time is correct?
My Answer:
Yes. I had manually changed the time after installation.

Dear experts, please advise on what i should do next.

thank you in advance

kind regards
yogeeraj

[Bob_Vance]

Well, first I would make sure that the latest patch for NTP, PHNE_24512, is installed on HPUX.

Then, I would suspect the windows NTP server -- because I have always used Unix NTP servers ;>) However, I *have* had problems in the past with some v3 HPUX versions, but not lately.

Is there any reason that the NT box has to be the main time server?

I would try changing the HPUX box to be the main NTP server:
. change it to stratum 7
. take out its server statement to "ntptsvr.yd.mu"
. then, on "ntptsvr.yd.mu", add a 'server hp-box'

to see whether the NT box syncs up with the HP server.

Or, do you have another Unix/Linux server that you could play with to try to sync up with the HP box?

hth
bv

[Yogeeraj_1]

Dear Bob,

thank you for your reply.

In fact, we have most of our systems on Windows -based. Thus, the reason for going for a windows-based time server to which not only my hp-ux server will sync but also all the other servers..

I will try to download the latest patch and test again...

will update in due course.

hope this fixes the problem. Hope the windows-based server is not the main issue!

Views from the experts are most welcomed.

kind regards
yogeeraj

[john korterman]

Hi Yogeeraj,

not exactly an expert contribution: does any Windows, or other machine, synchronize correctly to your time server?

regards,
John K.

[Yogeeraj_1]

Question: does any Windows, or other machine, synchronize correctly to your time server?

Answer: Yes. It was successfully tested in a windows environment.

[Bob_Vance]

Thinking more about it, NTP would normally not do large jumps in time.

If I read the previous correctly, when you restart the xntpd service the time is correct on the HP box?
I.e., ntpdate gets the correct time set and then xntpd keeps it synced for a while.

If the time stays correct on the Windows box, then you should never see a big difference between the times, much less several hours.

Are you sure that there is not something else running periodically on the HP box that could be changing the time manually in some way?

bv

[Bob_Vance]

OK, looking at your stuff again, we see:


---bv----------------------------------
# ./xntpd start
3 Sep 00:33:09 ntpdate[26213]: step time server 192.168.150.20 offset 0.457739
sec

xntpd # ntpq -p
remote refid st t when poll reach delay offset disp
==============================================================
================
corp.cmt.mu 0.0.0.0 16 - - 64 0 0.00 0.000 16000.0
---bv----------------------------------

We see that the xntpd script executed 'ntpdate' and got the current time as 00:33:09, with a very small offset, from 192.168.150.20.

So, what is 192.168.150.20?
Is that ntptsvr.yd.mu?
What is corp.cmt.mu?




---bv----------------------------------
#
# ntpdate ntptsvr.yd.mu
3 Sep 00:34:37 ntpdate[26221]: the NTP socket is in use, exiting
---bv----------------------------------

You cannot execute 'ntpdate' once 'xntpd' is running -- this gives the "in use" error.




---bv----------------------------------
# date 09030836
Sat Sep 3 08:36:00 GMT 2005
---bv----------------------------------

Here you forced a time change, apparently with 'xntpd' still running. You should never do this -- always stop xntpd first.




---bv----------------------------------
===================
restarte
d server
===================
# date
Sat Sep 3 08:47:12 GMT 2005
# ntpq -p
ntpq: read: Can't assign requested address
-bv-------------------------------------

It looks you really didn't "restart" the server, but merely stopped it -- otherwise you wouldn't have gotten the "Can't assign" error. IOW, 'xntpd' is not running.





---bv----------------------------------
# ntpq -p ntptsvr.yd.mu
remote refid st t when poll reach delay offset disp
==============================================================
================
*LOCAL(1) LOCAL(1) 12 l 8h 64 377 0.00 0.000 0.95
---bv----------------------------------

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



---bv----------------------------------
# ntpdate ntptsvr.yd.mu
3 Sep 00:50:32 ntpdate[1517]: step time server ntptsvr.yd.mu offset -28661.098
925 sec
---bv----------------------------------

Once again, the server tells us that it is 00:50:32 with a huge offset.


...

---bv----------------------------------
# ntpq -p
ntpq: read: Can't assign requested a
ddress
---bv----------------------------------

Again, this shows that 'xntpd' is not running.



---bv----------------------------------
# date
Sat Sep 3 00:51:16 GMT 2005
---bv----------------------------------

This is the time as received (or set) by the previous 'ntpdate'.



So, it looks like the problem might be with 'ntpdate' (assuming that the NTP server on Windows is working correctly).

I would test while avoiding 'ntpdate'
You can do that by modifying "/etc/rc.config.d/netdaemons" to have:

export NTPDATE_SERVER=""

This will make the '/sbin/init.d/xntpd start' *not* do the 'ntpdate'.

. /sbin/init.d/xntpd stop
. manually get the time close on the HP box via 'date mmddhhmm'
. /sbin/init.d/xntpd start
. check time via 'date'
. wait 5 mins
. ntpq -p
. date


hth
bv