On 2013-12-06, Bruce Evans <b...@besplex.bde.org> wrote: > In article <Zw6ou.573976$276.424...@fx07.iad>, unruh <un...@invalid.ca> > wrote: >>On 2013-12-05, antonio.marchese...@gmail.com >><antonio.marchese...@gmail.com> wrote: >>> >>> I understand and I apologise but I'm with a small netbook at the >>moment and I can't do better. I'm trying to clean the posts before >>posting them back. >>> >>> I'll see if I can fine an alternative. Thanks for your understanding >>in the meantime. >>>> >>>> -258 IS pretty high. On what kind of machine? What operating system? >>> >>> Same machine that was before! Supermicro motherboard, debian 5.0.7 >>>> >>>> The computer has to calibrate the timer interrupts on bootup. That >>>> calibration can be variable. For older versions of the Linux kernel that >>>> calibration was very variable, of the order that you are seeing. That >>>> seems to have been fixed on the more recent kernels. >>> >>> But I only restarted the ntp service, I did not reboot the server. >>> >>> As it's been said, I'm concerned that if the calibration can drift by >>200ppm I may end up over the 500ppm boundary. >>> >>> But I understand that the drift file will change between reboots, but >>it will then stabilise. Now the power saving is disabled I don't see the >>drift changing over time, which should be good? >> >>Yes, power saving is definitely a problem if your system clock is using >>tsc as the clock. The number of instructin cycles per secong changes >>under powersaving and thus the system clock rate changes by huge >>amounts. ( the powersaving could cause the cpu to go half as fast). The >>only thing to do is to use some other counter as the system clock (HPET >>should be better shouldn't it?-- I donot know how it behaves under >>powersaving). > > Starting 5-10 years ago, many x86 systems have a TSC that isn't affected > by power saving. I don't have such a system, but the only problems that > I know of on such systems are: > - the hardware to implements such invariance makes reading the TSC much > slower (up from about 10 cycles on old Athlons to 50-70 cycles). This > is still several times faster than reading an HPET and almost 100 times > faster than reading the ACPI timer. > - There may be problems with keeping the TSCs of several cores in sync. > The hardware doesn't do this so transparently, and if the software > handles it then it makes reading the TSC even slower. > > To handle the calibration varying across reboots, under FreeBSD I just > blow away the system calibration using a sysctl in an etc/rc file. > FreeBSD never had large variance in TSC calibration across reboots, > but I found the ones that it has annoying. Most versions have a jitter > of only a couple of parts per million (ppm), but some have a fixed > error of about 10 ppm due to a sloppy calibration algorithm. When > switching to a test or reference version with worse of just different > calibration, ntpd takes noticeably longer to sync, and syncing messes > up the driftfile for switching back.
Do you know how the system calibrates the TSC on bootup? _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions