[ntp:questions] Can a clock drift be too big for ntpd?

Jos van de Ven jos at notavailable.nl
Sat Oct 20 13:48:28 UTC 2007

After OP posted the start of this thread, I wanted to know more about this, 
but as I dig deeper it becomes more confusing to me.

My server runs fine (I think) on a 2.6.9- kernel. I read that 2.6 kernels 
have 1000 Hz as default and you can not change that in config files. At 
least I don't see anything related to HZ or HERTZ in my config files.

My relative frequency is stable at about -148 ppm, so my system clock runs 
too fast due to 1000 Hz setting as I understand. I read that -148 ppm is not 
a good clock; should be no more than absolute 50 ppm. Is it the kernel 
that's making my clock bad or just also bad hardware or a combination of 
What if I do a tickadj, so the frequency is stable at about 0 ppm, do I have 
a better clock then? I don't think so, but other people querying my server, 
may think it is very reliable.

Jos van de Ven

"David Woolley" <david at ex.djwhome.demon.co.uk.invalid> schreef in bericht 
news:4719d8c0$0$511$5a6aecb4 at news.aaisp.net.uk...
> In article <ywn91wbqaa39.fsf at ntp1.isc.org>,
> Harlan Stenn <stenn at ntp.org> wrote:
>>>> In article <slrnfhg0ap.vl7.pln at glast2.Stanford.EDU>, Patrick Nolan 
>>>> <pln at glast2.Stanford.EDU> writes:
> Patrick> 6-10 minutes per day, well over the 500 ppm limit.
>> As others have noted, ntpd cannot help in this situation, if it cannot be
> If it is systematic, it can be pre-corrected using tickadj; however, a
> static error this large due to the clock hardware would suggest the need
> for a new motherboard, and one due to lost interrupts will vary with
> system loading, and, at best, will result in the severe hunting of the
> time, and may result in the difference between quiet and busy period
> exceeding the ~900 ppm that you can cover by pre-compensating for the
> centre of the error band.  If the uncertainty in the daily, open loop,
> drift really is 10 - 6 = 4 minutes, you almost certainly do have a
> lost interrupts problem and pre-compensating will not be enough.
>> Yes, but be sure to rule out hardware *and* OS issues first.  See above.
> A bad clock frequency is a hardware issue!
>> Patrick> ntpq -p says this: remote refid st t when poll reach delay 
>> offset
>> Patrick> jitter
>> Patrick> 
>> ==============================================================================
>> Patrick> grandfather.Sta .GPS.  1 u 49 64 375 0.243 2833.49 1139.84
>> grandfather is not sync'd - you will not be able to sync to it while it 
>> is
>> like this.
> grandfather is synced (stratum 1).  It has lost its * because the
> offset is more than 128ms and ntpd is in the reconfirming offset state.
> It does seem to have lost one query, suggesting that, especially if
> it is on the LAN, the network is overloaded (wide area networks are
> designed to lose the occasional packet).  However the delay is very low,
> so it is unlikely that even severe network congestion will result in
> clock steps.  (Alternatively, you just lost a large number of consecutive
> clock interrupts, and the real delay is much larger - but then the lost
> interrupts would be the primary issue.) 

More information about the questions mailing list