[ntp:questions] why is my pool server's offset so bad
mayer at ntp.isc.org
Fri Feb 1 02:33:09 UTC 2008
Pat Farrell wrote:
> On Wed, 30 Jan 2008 23:40:17 -0500, Richard B. Gilbert wrote:
>>> But lately, the offsets are diving down. See
>> Sorry about that. How about supplying some USEFUL information
>> about your server! Knowing what O/S you are running on which hardware
>> platform, what version of ntpd
> I opened it up for general queries so you can ntpq -p and see.
> Its a debian Etch on a dual Xeon (intel 32) platform.
> ntpd 4.2.2p4
> Its got no real clocks, its just a load sharing device, getting good time
> from overworked upstream ntp servers and sharing it with the world
>> It might be helpful to start with the ntpq -p "banner".
> Don't know what you mean by 'banner'
> here is ntpq -p
> pfarrell at noise:/etc$ ntpq -p
> remote refid st t when poll reach delay offset jitter
> ntp-2.cns.vt.ed 22.214.171.124 2 u 31h 64 0 17.908 -0.296 0.000
> ntp-4.cns.vt.ed 126.96.36.199 2 u 31h 64 0 18.567 0.637 0.000
> ancalagon.cede. .INIT. 16 u - 1024 0 0.000 0.000 0.000
> prometheus.acm. .ï¿½ï¿½ï¿½ï¿½. 16 u 31h 64 0 0.000 0.000 0.000
> time-b.nist.gov .ACTS. 1 u 31h 64 0 13.555 6.162 0.000
You should at least upgrade to 4.2.4. The refid garbage on the line for
prometheus was fixed a long time ago.
>> It has been my experience that ntpd, when properly configured with good
>> servers and, optionally, a good ref clock, keeps time very well indeed.
> It was my experience that for four or five months, the server scored 20
> constantly. Recently, not so much.
Those numbers above and the ones I got when I queried your server are
excellent for most purposes. You don't want to see my numbers, though
admittedly I had hibernated my laptop and ntpd is still recovering right
now. My stationary systems are much more stable.
More information about the questions