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 both? 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" <[EMAIL PROTECTED]> schreef in bericht news:[EMAIL PROTECTED] > In article <[EMAIL PROTECTED]>, > Harlan Stenn <[EMAIL PROTECTED]> wrote: > >>>> In article <[EMAIL PROTECTED]>, Patrick Nolan >>>> <[EMAIL PROTECTED]> 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.) _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
