Re: Missed jiffies

[george anzinger <george@mvista.com>]

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/