lkml.org 
[lkml]   [1996]   [Mar]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: better resolution for getrusage()?
On Tue, 5 Mar 1996, Ben Wing wrote:
>
> How about some form of subdividing the system clock? i.e. Make the
> system clock fire at some (ideally controllable through a system call)
> multiple of 100 Hz, but have it pretend like it's running at 100 Hz
> for many parts of the kernel, e.g. device drivers that might depend
> on this.
I _like_ this idea, it's actually used in the pc-speaker sound driver (AIUI)
the problem is that it really screws up the free-run accuracy of the system
clock.

In fact I think there were actually very few locations that depend on the
clock being 100Hz, most of those have been removed by the Alpha port.

I think the best solution would be to combine _both_ clocks on the PC,
have the timer chip interrupt the system at a variable rate between 18Hz
and several thousand depending on system requirements.
Have HZ set to a fixed value (a variable one would be a BAD idea) for
the many 'tick' based users (kernel functions and user level).
Get the _real_ time by adjusting the interrupt time from the time on
the CMOS chip clock (adjusted for simple inaccuracies)

As I see it the only real problem would be the xntp daemon, I think
'all' you'd have to do is have a virtual timer that counts at the
1193180Hz rate of the timer chip and update it every real interrupt as
if the virtual chip were running at HZ (eg every 11931.81 +-20ppm!).
This would probably fix the free-run accuracy too, but not as well as
syncing to an adjusted CMOS would.

This does leave you with three clocks on the system, but has the
advantages of interrupts at _any_ rate and accurate time keeping
whatever the conditions...

--
Rob. (Robert de Bath <robert@mayday.compulink.co.uk>)



\
 
 \ /
  Last update: 2005-03-22 13:36    [from the cache]
©2003-2011 Jasper Spaans