On Sat, Jul 7, 2012 at 23:24 UTC, Justin Piszcz wrote: > # ntpq -pn > remote refid st t when poll reach delay offset > jitter > ============================================================================ > == > *127.127.28.0 .SHM. 0 l 7 16 377 0.000 25.168 > 51.466 > +64.6.144.6 128.252.19.1 2 u 34 64 1 74.498 77.264 > 69.854 > +204.235.61.9 209.51.161.238 2 u 31 64 3 46.668 65.476 > 67.756 > +108.61.73.244 129.7.1.66 2 u 30 64 3 24.246 71.441 > 68.162 > +67.18.187.111 129.7.1.66 2 u 1 64 7 50.851 94.044 > 89.377 > > Some ~5 minutes later, the same system (X9SCM-F) > > # ntpq -pn > remote refid st t when poll reach delay offset > jitter > ============================================================================ > == > *127.127.28.0 .SHM. 0 l 1 16 377 0.000 285.814 > 51.660 > +64.6.144.6 128.252.19.1 2 u 63 64 77 72.052 316.644 > 209.681 > +204.235.61.9 130.207.244.240 2 u 55 64 177 46.634 308.658 > 210.028 > +108.61.73.244 129.7.1.66 2 u 50 64 177 23.992 318.532 > 213.599 > +67.18.187.111 129.7.1.66 2 u 28 64 377 52.303 336.487 > 215.653 > > It is nice I can use the GPS now (thanks!); however, in your opinion could > there be an issue with the clock on this host as the offset+jitter seems > excessively high here?
Something's unhappy. I'd add "noselect" to the server 127.127.28.0 line so it uses only the network sources to steer the clock and see if eventually the offset and jitter for network sources comes down into the range you see on the other supermicro system. If it does and the jitter for the SHM driver settles down to better than the jitter from network sources, you can use the offset of the SHM driver to tweak your fudge and remove noselect to once again enable ntpd to steer the clock to match the SHM driver. Keep an eye out for repeated steps -- that's a sign your clock rate is off by more than 500 PPM. Good luck, Dave Hart _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
