On Wed, Jul 30, 2014 at 12:46 AM, Brian Inglis <brian.ing...@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. _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
