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.252 2 u 585 1024 377 0.614 0.058 0.310
| nscache2.dmz.bi 213.136.0.252 2 u 774 1024 377 0.414 0.116 4.459
| ntp3.dmz.bit.nl 213.136.0.252 2 u 21 1024 377 1.039 0.172 0.521
| *ntp4.bit.nl .PPS. 1 u 620 1024 377 0.701 0.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
remote refid st 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
+xxxxxxxxxxx 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
[email protected]
http://lists.ntp.org/listinfo/questions