[ntp:questions] why is my pool server's offset so bad
Danny Mayer
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
>>> http://www.pool.ntp.org/scores/70.184.242.241
>
>> 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 198.82.247.40 2 u 31h 64 0 17.908 -0.296 0.000
> ntp-4.cns.vt.ed 198.82.247.164 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.
Danny
More information about the questions
mailing list