[ntp:questions] Re: ntpd server on Linux/Debian with SPARC Sun Blade 100

David Woolley david at djwhome.demon.co.uk
Thu Oct 19 20:33:51 UTC 2006

In article <20061019141410.GH12952 at puck.ch>,
Olivier.Bornet at puck.ch (Olivier Bornet) wrote:
> On Thu, Oct 19, 2006 at 01:23:36PM +0200, Uwe Klein wrote:
> > i had a similar problem the other way round ( clock gaining) while your
> > clock seems to be loosing.

Gaining can happen for the other two reasons mentioned below, but it
excludes lost interrupts.

> I have manually check without ntpd, and after 2 hours, the system has
> loose about 6 seconds. So, about 2 seconds per hour seems to be too much
> for ntpd.

That's correct.  The maximum theoretically correctable error is one
second in every 2,000, however that means the control loop is non-linear
in one direction, so you really need an error that's maybe 10% less.

> Right. I hope that the solution suggested by the other emails to set HZ
> to 100 instead of 250 or 1000, or adjust the drift will correct the
> problem. If not, I will look in the interrupts direction.

Adjusting the drift file only speeds up the convergence process, it cannot
apply total corrections of more than the same 500ppm mentioned above.
Moreover, a system which needs such a correction is broken to the point
where it needs fixing first.  If you are loosing clock interrupts, you
will prevent the control loop going into its accurate mode and you will
have semi random steps in the time.  If the oscillator is out by this 
amount, the crystal is either dying or has died, and the clock is running
as an LC oscillator.  If the software is scaling by the wrong factor, it
needs to be fixed to scale by the correct one.

Note there is a parameter, which allows you to modify the assumed length
of a tick in microsecond step, which can be used to provide coarse correction,
but, as noted above, the system is probably broken if you need to use it
on modern systems (some older systems didn't have a full 500ppm correction
range, and I've observed crystals that seem to have been out by 100 to 
200 ppm).

One other thing that will give continued steps in the same direction is
having something else trying to set the software clock.  This will happen
with "out of the box" SunOS and SCO OpenServer systems.

More information about the questions mailing list