[cgl_discussion] requirements for configurable Round Robin quantum and 1 ms tick

George Anzinger george at mvista.com
Wed Aug 20 21:56:11 PDT 2003

Eric.Chacron at alcatel.fr wrote:
> Today some applications need to use Real Time process with Round Robin
> policy.
> Today the quantum seems to be defined by a constant value as 20 x the tick
> value.

Which "today"?  In the O(1) scheduler the slice (in ticks) is define
something like this:

#define MIN 10*HZ/1000
#define MAX 300*HZ/1000

slice = MIN + (MAX - MIN) * (MAX_PRIO-1-(p->static_prio))/(MAXUSER_PRI-1);

(say that 10 times quickly :)

The key is that p->static_prio is set by the nice call, so it is not a
fixed interval at all, AND it seems to be independent of the actual

I haven't done all the math, but, it seems clear that the min. slice
is 10ms.  If MAX is right, it would seem that the max is 200ms.

What, I think, needs to be exported is some info on just what slice
you get given a particular nice value.

> Then if i use a 10ms tick the quantum is equal to 200 ms. This seems too
> large.
> A second requirement could be to enable a 1 ms tick period for the timer
> interrupt on Intel Pentium architectures.

The 2.6 kernel is doing this.  It is not an easy thing to do if its to
be done correctly.  There are very real issues with the PIT interrupt
source not being able to hit the 1ms mark with enough precision to
satisfy ntp requirements.

> Is'it compatible with kernel maximum latency ? ( remenber that some
> application runs whithout any disk and without
> related sources of latency like fork+ exec ...)

I suspect that it has little to do with latency, save for the effect
on the cache of the interrupts.
> I would like to have the feed-back from everyone who's interrested in the
> question and also from Montavista
> as ther could be some link with low latency and RT scheduler for the second
> point.

George Anzinger   george at mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

More information about the cgl_discussion mailing list