[ntp:questions] Rejected peers. But why?
Hi, On a system that has been running for quite some time now i find that the ntpq output looks like this: | remote refid st t when poll reach delay offset jitter | == | nscache1.dmz.bi 213.136.0.2522 u 585 1024 3770.6140.058 0.310 | nscache2.dmz.bi 213.136.0.2522 u 774 1024 3770.4140.116 4.459 | ntp3.dmz.bit.nl 213.136.0.2522 u 21 1024 3771.0390.172 0.521 | *ntp4.bit.nl .PPS.1 u 620 1024 3770.7010.126 0.131 | | associd=0 status=0618 leap_none, sync_ntp, 1 event, no_sys_peer, | version="ntpd 4.2.6p3@1.2290-o Tue Jun 5 20:12:08 UTC 2012 (1)", | processor="x86_64", system="Linux/3.2.0-65-generic", leap=00, stratum=2, | precision=-22, rootdelay=0.701, rootdisp=40.953, refid=213.136.0.252, | reftime=d87dc094.9b3384d5 Thu, Feb 5 2015 11:12:36.606, | clock=d87dc730.0e1b8a90 Thu, Feb 5 2015 11:40:48.055, peer=19970, | tc=10, mintc=3, offset=0.126, frequency=6.923, sys_jitter=0.131, | clk_jitter=0.086, clk_wander=0.008 | | ind assid status conf reach auth condition last_event cnt | === | 1 19967 9014 yes yes nonereject reachable 1 | 2 19968 9014 yes yes nonereject reachable 1 | 3 19969 902a yes yes nonerejectsys_peer 2 | 4 19970 963a yes yes none sys.peersys_peer 3 Can someone please explain why the first three peers are in 'condition: reject' and wether or not this will recover automaticaly? The poll, reach, delay, offset and jitter values do not seem way out of hand to me. Why is ntpd not syncing to the three peers? I'm fairly certain it will sync to them when i restart the process, but for now i'll leave it like this... Thanks, -Sndr. -- | 42.7 percent of all statistics are made up on the spot. | 4096R/20CC6CD2 - 6D40 1A20 B9AA 87D4 84C7 FBD6 F3A9 9442 20CC 6CD2 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Rejected peers. But why?
On Thu, Feb 05, 2015 at 11:46:34AM +0100, Sander Smeenk wrote: > Can someone please explain why the first three peers are in 'condition: > reject' and wether or not this will recover automaticaly? The poll, > reach, delay, offset and jitter values do not seem way out of hand to > me. Why is ntpd not syncing to the three peers? It may be the loop detection algorithm. All of those servers indicate they are synced to the selected peer. If its clock wanders, they could follow it. --msa ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Rejected peers. But why?
Quoting Majdi S. Abbas (m...@latt.net): > > Can someone please explain why the first three peers are in 'condition: > > reject' and wether or not this will recover automaticaly? The poll, > > reach, delay, offset and jitter values do not seem way out of hand to > > me. Why is ntpd not syncing to the three peers? > > It may be the loop detection algorithm. All of those servers indicate > they are synced to the selected peer. If its clock wanders, they > could follow it. Hmm. That sounds right. I'll reconfigure the entire setup again. Thanks, -Sander. -- | If you're ever cold, stand in a corner for a bit. | They are usually about 90 degrees. | 4096R/20CC6CD2 - 6D40 1A20 B9AA 87D4 84C7 FBD6 F3A9 9442 20CC 6CD2 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Rejected peers. But why?
Sander Smeenk wrote: Hi, On a system that has been running for quite some time now i find that the ntpq output looks like this: | remote refid st t when poll reach delay offset jitter | == | nscache1.dmz.bi 213.136.0.2522 u 585 1024 3770.6140.058 0.310 | nscache2.dmz.bi 213.136.0.2522 u 774 1024 3770.4140.116 4.459 | ntp3.dmz.bit.nl 213.136.0.2522 u 21 1024 3771.0390.172 0.521 | *ntp4.bit.nl .PPS.1 u 620 1024 3770.7010.126 0.131 | . Can someone please explain why the first three peers are in 'condition: reject' and wether or not this will recover automaticaly? The poll, reach, delay, offset and jitter values do not seem way out of hand to me. Why is ntpd not syncing to the three peers? I'm fairly certain it will sync to them when i restart the process, but for now i'll leave it like this... Hi $ ntpq -4 -p me6000e remoterefidst t poll reach delay offset jitter (s) (ms)(ms) (ms) = *GPS_NMEA(2) .GPSb. 7 l 64 377 0.000 -1.786 7.863 oPPS(2) .PPSb. 0 l 16 377 0.000 0.000 0.004 +mail0.lordy 81.187.61.78 3 u 64 377 0.801 -0.006 0.416 +mail.lordyn 81.187.61.78 3 u 64 377 0.869 0.010 0.509 +ns3.lordyne 81.187.61.78 3 u 64 377 1.309 -0.209 0.481 e350n1b.hom 192.168.59.61 2 u 64 377 0.459 0.014 0.586 me6000g.hom 192.168.59.61 2 u 16 377 0.480 0.001 0.597 p3x1300.hom 192.168.59.61 2 u 64 377 0.317 0.356 0.544 +xxx 195.66.241.2 2 u 256 377 18.087 -1.466 0.365 E350n1b, me6000g and p3x1300 can't be selected because they are all synced to me6000e. You possibly need to add at least one extra independent ntp source. David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Rejected peers. But why?
Quoting David Lord (sn...@lordynet.org): > *GPS_NMEA(2) .GPSb. 7 l 64 377 0.000 -1.786 7.863 > oPPS(2) .PPSb. 0 l 16 377 0.000 0.000 0.004 > +mail0.lordy 81.187.61.78 3 u 64 377 0.801 -0.006 0.416 > +mail.lordyn 81.187.61.78 3 u 64 377 0.869 0.010 0.509 > +ns3.lordyne 81.187.61.78 3 u 64 377 1.309 -0.209 0.481 > e350n1b.hom 192.168.59.61 2 u 64 377 0.459 0.014 0.586 > me6000g.hom 192.168.59.61 2 u 16 377 0.480 0.001 0.597 > p3x1300.hom 192.168.59.61 2 u 64 377 0.317 0.356 0.544 > +xxx 195.66.241.2 2 u 256 377 18.087 -1.466 0.365 > > E350n1b, me6000g and p3x1300 can't be selected because they > are all synced to me6000e. > > You possibly need to add at least one extra independent ntp > source. Yes. This was indeed the problem. My mind not only wanders, it sometimes leaves completely. -- | Why won't an answering machine ever answer any questions? | 4096R/20CC6CD2 - 6D40 1A20 B9AA 87D4 84C7 FBD6 F3A9 9442 20CC 6CD2 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Rejected peers. But why?
On 2015-02-05 11:06, Sander Smeenk wrote: Quoting David Lord (sn...@lordynet.org): *GPS_NMEA(2) .GPSb. 7 l 64 377 0.000 -1.786 7.863 oPPS(2) .PPSb. 0 l 16 377 0.000 0.000 0.004 +mail0.lordy 81.187.61.78 3 u 64 377 0.801 -0.006 0.416 +mail.lordyn 81.187.61.78 3 u 64 377 0.869 0.010 0.509 +ns3.lordyne 81.187.61.78 3 u 64 377 1.309 -0.209 0.481 e350n1b.hom 192.168.59.61 2 u 64 377 0.459 0.014 0.586 me6000g.hom 192.168.59.61 2 u 16 377 0.480 0.001 0.597 p3x1300.hom 192.168.59.61 2 u 64 377 0.317 0.356 0.544 +xxx 195.66.241.2 2 u 256 377 18.087 -1.466 0.365 E350n1b, me6000g and p3x1300 can't be selected because they are all synced to me6000e. You possibly need to add at least one extra independent ntp source. Yes. This was indeed the problem. My mind not only wanders, it sometimes leaves completely. You need a majority of truechimers over falsetickers, so you need three independent sources to tolerate one being off occasionally, five to allow two off, etc. if the sources David has 3 falsetickers but 6 truechimers so selection succeeds. Wander > 1 is always an issue ;^> -- Take care. Thanks, Brian Inglis ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
