On Wednesday 05 December 2007 06:03:54 pm Carlos E. R. wrote: > The Wednesday 2007-12-05 at 22:48 +0100, Theo v. Werkhoven wrote: > > don't know where you got that from, but ever since the IBM AT, PC's have > > had a hardware clock on the mainboard, independent of the OS or user > > programs. > > The only thing that can make those thing fail is an empty battery or > > broken crystal. > > > > The crystals that make these hardware clocks tick aren't the best in > > terms of stability or accuracy of course, but with ntp for a daily > > dosage of 'realtime', there's nothing wrong with the basic concept. > > Er... > > However, that's not the clock the operating system uses when you ask for > the time: not in Linux, not in msdos. Not in a X86 type PC, regardless of > the operating system. > > There are two clocks on a PC. One is the CMOS clock, that runs out of > battery, independent of system load, on an external chip somewhere in the > mainboard (it is actually the same chip that holds the bios configuration > data). However, the resolution of this clock is small, a second I think, > and is slow to read. It can not be used as the system clock. > > This clock is only read once, when the system boots up, in order to set up > the system clock. > > The system clock run originally as a timer or oscillator chip that > interrupted the CPU about 19.2 times a second, and the CPU simply counted > those interrupts, updating the "system clock". Today there are variations > of this method, but the basis is the same. > > Suse programs this clock (in the kernel) to interrupt 250 times per > second. Other possible settings are 100, 300 and 1000Hz. The kernel has > been known to loose clock interrupts at the fast settings, specially the > 1000 Hz one if a reiserfs is also used (because it dissable interrupts in > some critical sections that last too long). This is known and documented; > you can find references to this problem in the ntp bugzilla. > > > Therefore, yes, a busy cpu can make the clock go slow. This is a fact. The > kernel should compensate, though. > > However, my problem is often worse when the cpu is not busy at all.
It seems that you can try to compile kernel with HZ enabled and set for instance to 250 Hz and see if that helps. This is current status with all 10.3 kernels: ~> grep HZ /boot/config-2.6.22.13-0.3-default CONFIG_NO_HZ=y # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set CONFIG_HZ=250 BTW, with current computer clocks in GHz range, 1000 Hz system clock rate shouldn't be a problem (one tick on every few millions cycles), and so far I know it is even recommended for desktop systems, although I'm not sure is there any recent evaluation of gain. I don't have it in this installation, but I did it 2 times before to give enough ticks to my obsolete scanner, and all that happened is scanner worked fine without need for high priority (niceness) for the driver. -- Regards, Rajko -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
