Hello,
although this is probably a beginner's question, I would like to
understand this before I run into trouble caused by misunderstanding
basic information. I think i misunderstood how to read the output of
ntpq -p... 
The third column ("st") shows the stratum.
But beginning to monitor time synchronization in our network, I noticed
a slight difference in the understanding of stratum levels between me
and the monitoring tool (Nagios).
When I use ntpq -p on one of our hosts I get the following output:

remote      refid   st t when poll reach delay offset   jitter
========================================================================
======
*10.x.y.z   .PPS.    1 u  338 1024  377  0.454 -1.559   0.078
name1.name  10.x.y.z 2 u  471 1024  376  0.209  1.763   0.093
name2.name  10.x.y.z 2 u 1461 1024  374  0.001  2.652   0.206
name3.name  10.x.y.z 2 u  596 1024  376  0.385  0.052   0.322
LOCAL(0)    .LOCL.   5 l   59   64  377  0.000  0.000   0.001

Until now I read this line :*10.x.y.z   .PPS.    1 u  338 1024  377
0.454 -1.559   0.078
the following way:
The host I ran ntpq -p on is synchronized to (*) server 10.x.y.z., whose
time source is a PulsePerSecond clock. 10.x.y.z is a server at stratum 1
and 338 seconds have passed since the last poll. The poll interval is
1024 seconds.
Because the time reference is located at stratum 1, this host is located
at stratum 2.
Similarily, if I look at server name1.name: name1.name is a server
located at stratum 2 and is itself synchronized to server 10.x.y.z.
If this is correct so far, the following output confuses me. I ran a
check for time synchronization for Nagios. Nagios provides a couple of
checks, one of them called check_ntp_peer. I use it to detect
differences between expected and current stratum levels.

/<installation_path>/libexec/check_ntp_peer -H name1.name -W 4 -C 6 -v

1 candiate peers available
synchronization source found
Getting offset, jitter and stratum for peer 4551
parsing offset from peer 4551: -0.001193
parsing stratum from peer 4551: 1
NTP OK: Offset -0.001193 secs,
stratum=1|offset=-0.001193s;60.000000;120.000000; stratum=1;4;6;0;16

This output tells me, that name1.name is located in stratum 1 (instead
of the expected stratum 2). 

In short: does the column st refer to the stratum of the remote host OR
does it mean "If I synchronize to that remote host I will get to stratum
x" ?
Thanks and regards,
Stefan Nottorf

Stefan.Nottorf@plath.de (Nottorf, Stefan) writes:

>Hello,
>although this is probably a beginner's question, I would like to
>understand this before I run into trouble caused by misunderstanding
>basic information. I think i misunderstood how to read the output of
>ntpq -p... 
>The third column ("st") shows the stratum.
>But beginning to monitor time synchronization in our network, I noticed
>a slight difference in the understanding of stratum levels between me
>and the monitoring tool (Nagios).
>When I use ntpq -p on one of our hosts I get the following output:

>remote      refid   st t when poll reach delay offset   jitter
>========================================================================
>======
>*10.x.y.z   .PPS.    1 u  338 1024  377  0.454 -1.559   0.078
>name1.name  10.x.y.z 2 u  471 1024  376  0.209  1.763   0.093
>name2.name  10.x.y.z 2 u 1461 1024  374  0.001  2.652   0.206
>name3.name  10.x.y.z 2 u  596 1024  376  0.385  0.052   0.322
>LOCAL(0)    .LOCL.   5 l   59   64  377  0.000  0.000   0.001

>Until now I read this line :*10.x.y.z   .PPS.    1 u  338 1024  377
>0.454 -1.559   0.078
>the following way:
>The host I ran ntpq -p on is synchronized to (*) server 10.x.y.z., whose
>time source is a PulsePerSecond clock. 10.x.y.z is a server at stratum 1
>and 338 seconds have passed since the last poll. The poll interval is
>1024 seconds.

The PPS clock is stratum 0. The host synced to that is stratum 1. The host
synced to a stratum 1 is stratum 2, etc.

>Because the time reference is located at stratum 1, this host is located
>at stratum 2.
>Similarily, if I look at server name1.name: name1.name is a server
>located at stratum 2 and is itself synchronized to server 10.x.y.z.
>If this is correct so far, the following output confuses me. I ran a
>check for time synchronization for Nagios. Nagios provides a couple of
>checks, one of them called check_ntp_peer. I use it to detect
>differences between expected and current stratum levels.

>/<installation_path>/libexec/check_ntp_peer -H name1.name -W 4 -C 6 -v

>1 candiate peers available
>synchronization source found
>Getting offset, jitter and stratum for peer 4551
>parsing offset from peer 4551: -0.001193
>parsing stratum from peer 4551: 1
>NTP OK: Offset -0.001193 secs,
>stratum=1|offset=-0.001193s;60.000000;120.000000; stratum=1;4;6;0;16

>This output tells me, that name1.name is located in stratum 1 (instead
>of the expected stratum 2). 

This is an issue with nagios. 



>In short: does the column st refer to the stratum of the remote host OR
>does it mean "If I synchronize to that remote host I will get to stratum
>x" ?

As you can see, the machine that is synced to the pps is stratum 1 .

>Thanks and regards,
>Stefan Nottorf

Nottorf, Stefan wrote:

> remote      refid   st t when poll reach delay offset   jitter
> ========================================================================
> ======
> *10.x.y.z   .PPS.    1 u  338 1024  377  0.454 -1.559   0.078
> name1.name  10.x.y.z 2 u  471 1024  376  0.209  1.763   0.093
> name2.name  10.x.y.z 2 u 1461 1024  374  0.001  2.652   0.206
> name3.name  10.x.y.z 2 u  596 1024  376  0.385  0.052   0.322
> LOCAL(0)    .LOCL.   5 l   59   64  377  0.000  0.000   0.001
> 
> In short: does the column st refer to the stratum of the remote host OR
> does it mean "If I synchronize to that remote host I will get to stratum

That of the remote host.

Incidentally, why are you running the local clock driver at stratum 5? 
That should only be done if your machine is a server and is being 
synchronised to a reliable time source by means other than NTP.  Local 
clock has no place at all on clients and should only be used on servers 
as a deliberate choice.  When synchrnonised to an unreliable source, 
like the undisciplined local clock (including that clock as a fall back 
to external servers), it should be set to the highest stratum that is 
still acceptable to its clients, if used at all.