Re: Changing the clock speed

Hi Andy,

Andrew Valencia wrote:
>
> >Has anyone got an opinion about changing the value of HZ to 100 from 20?
>
> A couple of observations.

That's why I asked :-)

> First, increasing clock frequency to improve timer resolution is the wrong
> way to go. As was noted, if you need better resolution, you should use an
> interval timer in conjunction with your system clock.

Quite true - I did things this way 'cos it was quick and easy to do. I'm
now looking at using the interval timer instead, although it means some of
the clock code will be inlined from the mach dir instead of all living in
the kern directory. Something does ring bells with me about problems with
the interval timer for this sort of activity, but I guess we'll see how it
goes.

> Second, increasing clock frequency to reduce latency between context
> switches generally indicates that you should fix your preemption code
> instead. With the current kernel, we will preempt immediately (that is, not

Well there was never really any intention to move to preempting faster (4 Hz
just sounds nicer than 3.33 :-)) Realistically I want to look at some of
the queue handling to cope with these sorts of issues (I've seen some great
priority inversions with some of my test code).

> With these two aspects covered (plus or minus a bug fix and tweaking!), are
> there any other aspects of system performance which really call for us to up
> the clock frequency? As Dave measured, there is a real overhead cost in
> taking more interrupts--we should do so only when the alternatives have been
> exhausted.

I can't now see any need for a change. In fact I've now realised there's
another optimisation I can do for the clock handler which will make things
even faster :-)

                                Regards,
                                Dave
Received on Wed Feb 15 05:58:56 1995