Messages in this thread | | | Date | Sat, 9 Mar 1996 14:48:44 +0000 (GMT) | From | Robert de Bath <> | Subject | Re: 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>)
| |