[ntp:questions] Severe time drift for Undisciplined Local Clock

David Woolley david at djwhome.demon.co.uk
Thu Mar 29 21:25:57 UTC 2007

In article <20070328173834.9usevzm8gc8osk0w at webmail.nulan.co.za>,
deon at nulan.co.za wrote:

> made the Time Server. It uses as it's reference the on-board hardware  
> clock (computer motherboard hardware clock, Real Time Clock (RTC)). In  

There is no driver for the RTC in the standard distribution of ntpd,
and it would not be a very good choice because it would have a precision
of 2^0, which would pretty much disqualify as a time source due to 
the excessive root dispersion.

> NTP terminology this referred to as the Undisciplined local clock.

What is called this in ntpd is the software maintained clock.

> synchronised to the hardware clock yet experiences upto 1 hour  
> timedrift per month!

1 hour / month ~= 120/86400 ~= 1/720, which is worse than 500ppm.
ntpd cannot capture when the relative error to the server exceeds this.
If you use a real time source, this represents 500ppm relative to UTC.
As you are using the software clocks, you have to budget for 250ms error
on both client and server.

I would advise finding the non-NTP reason why you have such a high
frequency error and fixing it.  For errors less than about 200ppm, 
and for this one if you are desperate, you can calibrate the clock
and then set the drift file accordingly.

> but why would that matter if the source is a piece of external  
> hardware? Further, it seems that the kernel is adjusting the RTC since  

By selecting the "local clock" you are not using external hardware,
even in the weak sense that the RTC doesn't mind lost interrupts, so
is more external the CTC.

> when you get the time from the RTC, it's the same as the System Clock.  
> I have checked that the kernel is not in in "11 minute mode" by using   

If the clock is not in 11 minutes mode, ntpd is not synchronised and
will not serve time.

> fudge stratum 0

Please DO NOT do this.  Undisciplined local clocks should be at the
highest stratum consistent with not quite exceeding stratum 15 in your
private time network.   Even the default acknowledges that an externally
synchronised software clock (yours isn't) is not as reliable as one
synchronised by ntpd.

More information about the questions mailing list