Tuning HZ for semi-realtime applications

[Daniel Eischen]

On Tue, 5 Aug 2003, David Schultz wrote:

> On Tue, Aug 05, 2003, Roderick van Domburg wrote:
> > There's this Linux kernel patch that allows for timeslice tuning. It's 
> > got the following rules of the thumb:
> > 
> > * The optimal setting is your CPU's speed in MHz's / 2
> > * ...but there is no point in going above 1000 Hz
> > * ...and be sure to use multiples of 100 Hz
> > 
> > I am everything but an expert at scheduling, but somehow this makes 
> > sense: i.e. one jiffy for the scheduler and one jiffy for the process.
> > 
> > Does all of this make any sense or is it just a load of hooey?
> 
> There might be some rationale behind that suggestion, but my first
> guess would be that someone pulled those numbers out of a hat.  In
> general, doing a context switch has negative cache effects, in
> addition to the overhead that you pay up front.  For optimum
> throughput, you want to set HZ to the smallest number that still
> gives acceptable resolution.  100 Hz works just fine for
> interactive jobs; humans can't tell the difference.[1]  For many
> real-time applications, a higher value is needed.
> 
> 
> [1] In terms of overhead, I think 100 Hz is well into the noise
>     these days, so bumping that up a little bit would result in
>     negligible difference.  I measured 100 vs. 500 a little while
>     ago, and couldn't find a realistic benchmark that was negatively
>     impacted by the higher frequency.

I used to run my old Pentium I (200MHz) laptop at 1000Hz without
any problems.  I ran it this way for years until I retired it a
few months ago.  I'd support raising our default rate from 100Hz
to 1000Hz.

-- 
Dan Eischen