Re: Reduce scheduling interval on Linux...

[Peter <peter@atterfjall.pp.se>]

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