Messages in this thread |  | | | Date | Sat, 16 Feb 2002 11:02:21 -0800 | | From | george anzinger <> | | Subject | Re: Missed jiffies |
| |
Alan Cox wrote: > > > My system looses about 8 seconds every 20 minutes. This is reported > > by ntp and verified by comparing 'date' to 'hwclock --show' and a wall > > clock. > > > > My system is a x86 Dell laptop with HZ=1024. > > > > I am quite certain that the issue is the System Management Interrupt > > (SMI). > > Possibly and if it is you can't really do much about it. > > > I don't know that there is a solution for all systems, however, at > > least on pentium systems it seems possible to use the TSC to catch > > Most vendor systems don't have SMI problems that bad, you can normally hit > the 100Hz or 1Khz tick quite reliably. > > > tsc_remainder += last_tsc_low-tsc_low; > > The tsc is not a constant on some laptops, and may not be present, or not > be reliable. > > > What strategies might be employed to prevent degraded system > > performance since this code is in a criticle path? > > Adding a time slew is a well understood problem - the NTP code and papers > cover some very efficient implementation techniques. If you can work out > the drift then drifting back is extremely efficient and the kernel already > implements the needed PLL. > > > Have I competely missed something, the kernel already takes care of > > this and I have the problem all wrong? > > You have it pretty much right. We have several time sources on a PC - > the rtc (variable rate, not always present), the cmos clock (low res and > on many modern machines horribly inaccurate due to the use of low grade > components), the acpi timers (on newer machines only, high resolution > constant rate, unknown accuracy).
I rather thought that since it runs at exactly 3 times the PIC clock rate that it used the same "rock". Andrew, any thoughts here? > > ACPI may help here but lots of vendors implement their ACPI subsystem using > I/O cycles to jump into SMM mode so its game over again. > > > This problem also comes up with IDE access with dma off and I've > > seen reports of it when using frame buffers. > > The frame buffer one is fixed for newer kernels. The IDE one is a physical > constraint on some older IDE controllers. See man hdparm. > > Alan > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/
-- George george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ Real time sched: http://sourceforge.net/projects/rtsched/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |