Re: fixed time slices?

See Inline:

"Jan Bruns" <testzugang_janbruns@xxxxxxxx> wrote in message
news:467ff475$0$6392$9b4e6d93@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

"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?

yes - modulus of n and 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.

AFAIK the scheduler does not behave this way but if the scheduler planed a
timer interrupt for a specific delay for the purpose of changing tasks
pre-emptivly, then that is just the end of the low-priority thread's time
slice. In this case, the scheduler would not detect that a higher priority
thread was ready to run, but would _know_ that said thread would be ready to
run and adjusted the time slices of other threads accordingly.



This example only makes sense in the case of simple Sleep(n) calls because
the scheduler can only _know_ when a thread will become ready to run if
there is a fixed or known delay. Since even the relatively simple call
SleepEx(n, true) does not have a fixed or known delay, the scheduler cannot
make any assumptions about how best to optimize the timer interrupts.
Combine this complexity with thousands of threads using tens of thousands of
wait objects in much more complex ways than sleep (like WFMO and Semaphores,
GQCS & IOCP, or Timer Queues) and it is easy to see why a fixed timer
interrupt interval would be the implementation of choice.


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.

A 2% decrease in throughput can be considered significant.


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: fixed time slices?
    ... a timer-IRQ within wahtevr delay is desired. ... the scheduler would not detect that a higher priority ... make any assumptions about how best to optimize the timer interrupts. ...
    (microsoft.public.win32.programmer.kernel)
  • summary (Re: [patch] prefer TSC over PM Timer)
    ... and attempted to summarize the ... if timer_pm is fixed to read the PM timer only once on non-broken systems ... until/unless C3 and deeper resync tsc then it's best not to default to tsc ... can't be shared with scheduler if we add variable scheduler ticks ...
    (Linux-Kernel)
  • Re: fixed time slices?
    ... high resolution timer(timeBeginPeriod), check ... to WFSO using an event that gets signaled just *after* WFSO ... NEVERTHELESS, as soon as a higher priority thread becomes ready to run, ... AFAIK the scheduler does not behave this way but if the scheduler planed ...
    (microsoft.public.win32.programmer.kernel)
  • Re: fixed time slices?
    ... to WFSO using an event that gets signaled just *after* WFSO ... NEVERTHELESS, as soon as a higher priority thread becomes ready to run, it ... Scheduler "ticks" only ... systems may also provide high-resolition interval timer, ...
    (microsoft.public.win32.programmer.kernel)
  • Re: [ANNOUNCE][RFC] PlugSched-6.3.1 for 2.6.16-rc5
    ... But anyway, based on the evidence, I think the problem is caused by the fact that the eatm tasks are running to completion in less than one time slice without sleeping and this means that they never have their priorities reassessed. ... The reason that it does this is that it gives newly forked processes a fairly high priority and if they're left to run for a full 120 msecs at that high priority they can hose the system. ... Having a shorter first time slice gives the scheduler a chance to reassess the task's priority before it does much damage. ...
    (Linux-Kernel)