[ntp:questions] LOCL clock reachability not 377?

Paul tik-tok at bodosom.net
Wed Jul 30 13:23:04 UTC 2014


On Wed, Jul 30, 2014 at 12:46 AM, Brian Inglis
<Brian.Inglis at systematicsw.ab.ca> wrote:

> Not seen this topic mentioned in the last year or more.

See my posts about "PPS is a falseticker?" of  Sun Jun 15 14:37:32 UTC
2014 and Wed Jun 18 20:59:03 UTC 2014 .

> These statuses show the same issue with local clock reach, implying if reach stays
> at zero, sync will be lost and PPS become a falseticker without anything to number
> seconds for too long.

But it doesn't -- as previously mentioned.

>>The reach bit cycles up until it is 0, then the LOCAL clock is no longer
>>reference clock, the PPS status changes to x
>>
>>    remote           refid      st t when poll reach   delay   offset  jitter
>>==============================================================================
>>xPPS(0)          .PPS.            0 l    9   16  377    0.000    0.001   0.000
>> LOCAL(0)        .LOCL.           5 l  536   64    0    0.000    0.000   0.000
>>
>>The next cycle the LOCAL clock starts at reach 1 again, becomes the
>>reference (*), and PPS status changes to o again.

or here:

>>  Looks like a bug anterior to your version. I see the same issue with version="ntpd 4.2.6p5 at 1.2349-o"
>>  whether or not there is a preferred local clock or not, and whether or not there are other active server associations.

> Read the thread about the OP's config and problems.

I did.  And like others I see this:
oPPS(0)          .GPPS.           0 l    3    8  377    0.000    0.001   0.008
*LOCAL(0)        .LOCL.          12 l   66    8    0    0.000    0.000   0.008
oPPS(0)          .GPPS.           0 l    1    8  377    0.000    0.003   0.008
*LOCAL(0)        .LOCL.          12 l    -    8    1    0.000    0.000   0.008
oPPS(0)          .GPPS.           0 l    6    8  377    0.000    0.003   0.008
*LOCAL(0)        .LOCL.          12 l   21    8    4    0.000    0.000   0.008
oPPS(0)          .GPPS.           0 l    1    8  377    0.000    0.001   0.008
*LOCAL(0)        .LOCL.          12 l   56    8  200    0.000    0.000   0.008
oPPS(0)          .GPPS.           0 l    8    8  377    0.000    0.005   0.008
 LOCAL(0)        .LOCL.          12 l   71    8    0    0.000    0.000   0.008
oPPS(0)          .GPPS.           0 l    1    8  377    0.000    0.005   0.008
*LOCAL(0)        .LOCL.          12 l    8    8    2    0.000    0.000   0.008

etc. etc.  I don't see LOCL marked as a falseticker.  This clock has
been running and keeping acceptable time for weeks (as an experiment).
Since this last came up.  I mentioned the version because I *don't*
have the OP's various problems -- either in configuration or execution
which I think, as I said last month, are the OP's real problem

BTW, the other snippet seems to refute the idea that you can't run
like this with varying minpoll (although the peer was marked
noselect).  Or perhaps I misunderstand the assertion.


More information about the questions mailing list