[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
>> Patrick> jitter
>> 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
>> 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