Re: fixed time slices?


"m" <m@xxx>:
"Jan Bruns":

What I meant with reliability was, if I can count on that the minimum
time a sleep(n) might take is really (n+m+k) ms, where m is the least
valid value passed to timeBeginPeriod(m) and k is some oberhead
value less than m.

No; assuming no clock skew, the minimum duration of Sleep(n) is (n + (n % m)
+ k)

By (n % m) yu mean the remainder of n/m?

That's clear. But it also says:

| If a higher-priority thread becomes available to run, the system
| ceases to execute the lower-priority thread (without allowing it
| to finish using its time slice), and assigns a full time slice
| to the higher-priority thread.

The key here is that a thread becomes ready to run. A thread can only
become ready to run, and be scheduled on a CPU, when the scheduler is
running and decides that it is ready to run. The scheduler only runs in
response to a timer interrupt or a call to a wait function (maybe other
kernel entry points also), so the precision of pre-emption timing is always
bounded by the system timer frequency (by the case, on a UP machine, where
the running thread executes all user mode code for its entire time slice).

But the scheduler would also have the chance to let the hardware generate
a timer-IRQ within wahtevr delay is desired. So it could put the CPU on
a ready low-priority thread for as long as a higher priority thread is
known to be unrunnable.

In old MS-DOS days, the precision of the programmable intervall timer
(an extra chip for this purpose?) AFAIR was better then 1/10MHz. At
least it was possible to sync it to a screen's scanline
(60Hz*480scanlines)=28800Hz -> timer resolution better than 35e-6 s.

Maybe I should have said a noticeable performance cost to increasing
the timer frequency.

Not on my computer. I've tried this using a CPU-intensive working
process, and another high priority process, that effectively does
nothing but sleep(2) (measured).
The working process slowed down about 2%. 500 sleep instructions,
each resulting in about 4 CPU-task switches -> 2000 Task-swithes
per second might really eat 2% of CPU, when the intermediate
sheduler-task also takes some overhead. That's fully in the
range I expected.

PROCEDURE bute_force_sleep(ms : dword);

This depends on how frequently you would need to use bute_force_sleep.

It's near to always*somwhat_lesser.

Given that you are planning a standalone application, I doubt you will have
a problem either way. As long as you know that you don't play nice in the
sandbox, you can do whatever you like ;)

#(o;

Gruss

Jan Bruns

.

Relevant Pages

  • Re: Blocking read() policy?
    ... >> It doesn't require any particular advanced scheduler. ... Especially if pgms demanding short latency ... that a CPU intensive process would ... starts over with the shortest possible time slice. ...
    (comp.os.linux.development.system)
  • Re: [ANNOUNCE][RFC] PlugSched-6.3.1 for 2.6.16-rc5
    ... problem is that it uses a smaller time slice for the first time slice ... full 120 msecs at that high priority they can hose the system. ... shorter first time slice gives the scheduler a chance to reassess the ... This is supposed to represent the task with the highest CPU usage rate per share and is used to determine how fairly CPU is being distributed among the currently active tasks. ...
    (Linux-Kernel)
  • Re: OpenGL driver consumes 100% CPU
    ... This is because you have given the computer a time slice that is too ... scheduler is of the order 10-100 msec. ... context switch is /much/ smaller - typically only a few microseconds. ... 60Hz will inevitably hog the CPU because that rate of context ...
    (comp.programming.threads)
  • One minute delay when booting 2.6.24.1
    ... Switched to high resolution mode on CPU 1 ... io scheduler anticipatory registered ... # Infrared-port device drivers ...
    (Linux-Kernel)
  • [RFC][PATCH] O(1) Entitlement Based Scheduler
    ... This patch is a modification of the Oscheduler that introduces ... _entitlement_ to CPU resources that is determined by the number of _shares_ ... This patch provides both soft and hard CPU usage rate caps per ... one getting the most can be given a better priority, ...
    (Linux-Kernel)