Rajko M. wrote:
> 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.
>
>   

FWIW I always recompile the suse kernel source with HZ=1000 on my gaming
machine.

Seriously, I get more frags, and get fragged less, that way...

Joe


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to