Reduce scheduling interval on Linux...

Reduce scheduling interval on Linux...

[Peter]

On Red Hat linux a delay 0.0; would mean that process (thread) will be 
out of processing for 10 (ms) by default. This is a kernel 
configuration, and a good value in many cases. For my application I 
would like to reduce this time to maybe 1 (ms), or try to optimise it to 
the perfect value for the application. Yes, I know I am trying to make a 
RTOS of something that is not, but this is really the only thing 
missing, and the advantages of having a full system at least for 
development makes me rather accept 10 (ms) that to have to cross compile 
all the time.

Has anyone been changing this and could point me in the right direction. 
Tried to do this once on Red Hat 7.0....but only got confused by the 
parameter names and the comments around them in the kernel.... Are you 
aware of any other full systems, beeing it Linux, BSD or whatever were 
this value is lower or easily could be changed ?

( Yes I am aware I will take away lots of machine power with this short 
scheduling times, but power is not yet an issue)

Thank you for any help on this

Peter Atterfj�ll     @Home
peter@atterfjall.pp.se

Re: Reduce scheduling interval on Linux...

[Simon Wright]

Peter <peter@atterfjall.pp.se> writes:

> On Red Hat linux a delay 0.0; would mean that process (thread) will be
> out of processing for 10 (ms) by default. This is a kernel
> configuration, and a good value in many cases. For my application I
> would like to reduce this time to maybe 1 (ms), or try to optimise it
> to the perfect value for the application. Yes, I know I am trying to
> make a RTOS of something that is not, but this is really the only
> thing missing, and the advantages of having a full system at least for
> development makes me rather accept 10 (ms) that to have to cross
> compile all the time.
> 
> Has anyone been changing this and could point me in the right
> direction. Tried to do this once on Red Hat 7.0....but only got
> confused by the parameter names and the comments around them in the
> kernel.... Are you aware of any other full systems, beeing it Linux,
> BSD or whatever were this value is lower or easily could be changed ?

I don't have the source installed at the moment, but on the 2.0
kernels you could change the tick time by altering include/asm/param.h
to set HZ to 1000.

I think you also have to change kernel/sched.c in sys_nanosleep() --
there's a busy wait for sleeps (as root) of 2 mS or less.

Then (just) rebuild and go!

We had machines that stayed up for (a few) weeks with this setting.

NB1: if you have a loop with a delay, the maximum repetion rate you
will get is half the jiffy frequency -- HZ=1000 gives 500 loops/sec.

NB2: the real reason stock Linux isn't a RTOS isn't the 10 mS clock --
VxWorks has a 60 Hz clock out of the box -- rather, it's the
unpredictability of kernel scheduling.

Re: Reduce scheduling interval on Linux...

[Peter]

Peter <peter@atterfjall.pp.se> writes:


>> On Red Hat linux a delay 0.0; would mean that process (thread) will be
>> out of processing for 10 (ms) by default. This is a kernel
>> configuration, and a good value in many cases. For my application I
>> would like to reduce this time to maybe 1 (ms), or try to optimise it
>> to the perfect value for the application. Yes, I know I am trying to
>> make a RTOS of something that is not, but this is really the only
>> thing missing, and the advantages of having a full system at least for
>> development makes me rather accept 10 (ms) that to have to cross
>> compile all the time.
>> 
>> Has anyone been changing this and could point me in the right
>> direction. Tried to do this once on Red Hat 7.0....but only got
>> confused by the parameter names and the comments around them in the
>> kernel.... Are you aware of any other full systems, beeing it Linux,
>> BSD or whatever were this value is lower or easily could be changed ?
>  
>

Simon Wright <simon@pushface.org> answers:

I don't have the source installed at the moment, but on the 2.0
kernels you could change the tick time by altering include/asm/param.h
to set HZ to 1000.

I think you also have to change kernel/sched.c in sys_nanosleep() --
there's a busy wait for sleeps (as root) of 2 mS or less.

Then (just) rebuild and go!

We had machines that stayed up for (a few) weeks with this setting.

NB1: if you have a loop with a delay, the maximum repetion rate you
will get is half the jiffy frequency -- HZ=1000 gives 500 loops/sec.

NB2: the real reason stock Linux isn't a RTOS isn't the 10 mS clock --
VxWorks has a 60 Hz clock out of the box -- rather, it's the
unpredictability of kernel scheduling.

Peter <peter@atterfjall.pp.se> comments:

Thank you for your reply. I will have a look at this later this week. 

My comment about RTOS was a bit clumsy. I have been using pSOS and VRTX for many embedded systems, so I am aware of the differences. I just wanted to put in a comment to avoid the 'easy way out' comments like; run anoth OS. If I at any time in the future will make this software into a product I will most likely look in that direction, but at this point predictability is not an issue, as long as response stays within a few ms (will add gitter to the IP traffic). With my solution today I add a gitter up +0 -- +10 ms, plus a delay of a few up to several hundred ms (depending on configured queue depth, and traffic class). Reducing the gitter down to ~1 ms will make me fully in charge of deciding the behaviour of the system (in some cases I might still choose to have higher gitter because of better total performace of the system).

Thank you again for your reply. If I am successfull I will let you know.

Regards

Peter Atterfj�ll