C++/VB - How do you set time-slicing for Windows XP

Asked By Vincent

08-Aug-08 03:55 AM

I know that Windows XP is not a RTOS. Just wondering if any experts around
knows how to set the time-slice of the scheduler to
maybe 5ms or so. I do know the approximate time-slice by default is around
10ms to 15ms per quantum depending on OS and no if processors. I have read
the API32 but couldn't find anything that can help.

Regards,
Vin

08-Aug-08 04:12 AM

Hi VincentO!

timeBeginPeriod(1);

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

08-Aug-08 10:35 AM

No, it will not. It just changes timer resolution. Timer tick != scheduler time
slice.

But if someone needs to change scheduler timeslice, he is doing something
wrong.

08-Aug-08 11:02 AM

Hi Alexander!

If I make a "Sleep(1)" without "timeBeginPeriod" I get a sleep of 12-15 ms

If I first call "timeBeginPeriod(1)" then I get a sleep of 2 ms...

Also if you look at the source-code, you will see that the


--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

08-Aug-08 11:55 AM

Jochen, have you looked at the source code of WinXP scheduler?
Wow,  what a  diligence :)

Certainly, time slice unit is based on resolution of the periodic timer tick
( it can not be less than the tick period?)
but these are two different things.

/* Linux can be configured  "tickless", but I haven't used this yet */

--PA

08-Aug-08 01:46 PM

Hi Pavel!


???

See comment in the documentation of "timeBeginPeriod":

This function affects a global Windows setting. Windows uses the lowest
value (that is, highest resolution) requested by any process. Setting a
higher resolution can improve the accuracy of time-out intervals in wait
functions. However, it can also reduce overall system performance,
because the thread scheduler switches tasks more often. High resolutions
can also prevent the CPU power management system from entering
power-saving modes. Setting a higher resolution does not improve the
accuracy of the high-resolution performance counter.

So setting "1" means, that the scheduler will be called much more than
normal.
This indicates that the reduction of the thread-quantum is done inside
*this* tick-counter. Which leads to the effect, that the
thread-switch-count will increase dramaticaly.


--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

08-Aug-08 04:24 PM

Not necessarily true



Calling timeBeginPeriod changes the system timer interrupt frequency and
since the schedule can only evaluate when a thread is ready to run on a
timer interrupt (and some other kernel calls) calls to Sleep() etc. behave
as you describe.  Specifically, on an idle system, a call to Sleep(1) will
result in a wait of 1 <= t <=2 ms (a wait of 1 ms with a resolution of 1
ms).  This happens because when the timer runs, it detects a thread ready to
run and a CPU it can run on; it pre-empts whatever it running on that CPU
(the system idle process) and schedules your thread.



This has nothing to do with the length of a thread's quantum.  The thread's
quantum is a time after which it must yield to a thread at the _same_
priority level.  This is not configurable in Windows and is hardware and
version dependent.



Look for information on thread scheduling and syncronization in MSDN.

08-Aug-08 04:28 PM

Agreed.


Still not sure that the thread quantum would become shorter if the timer
ticks more often.

--PA

08-Aug-08 09:31 PM

Time slice is time allotted for one thread to run until it gets switched to
another ready thread. It applies only to threads that are not waiting for
anything.

Thread switch doesn't have to happen on time slice boundary. A thread that
becomes ready will get processor immediately, if there is no other
contenders. This, Sleep(1) doesn't have to sleep for the whole time slice,
but it will end on a timer tick.

08-Aug-08 09:35 PM

Schedules runs every time any thread becomes ready, or the currently running
thread becomes non-ready. It's not related to the timer ticks.

Kernel timer queue items get retired on timer ticks. At those moments the
scheduler (dispatcher) can get invoked, too, if necessary. But scheduler
invocations don't happen exclusively on timer ticks.

09-Aug-08 02:41 AM

Hi Pavel!


The thread quantum is still the same, but it will be decremented faster...

For example, if you have two read-to run threads in the same prio (like

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

09-Aug-08 10:09 AM

That's very easy to test...

09-Aug-08 08:59 PM

For the purpose of a discussion of the significance of thread quantum
length, those 'other kernel calls', that constitute the most important
actions of the scheduler, are irrelevant.  If a thread is pre-empted by the
system to run a something else of any reason except the end of a quantum,
then it make no difference what the size of the quantum was.  It does serve
to remind one that the length of a quantum is not usually an important
factor in application performance.

10-Aug-08 05:47 PM

Nope.  I just tried it; it did not change.  The thread quantum is based on
TIME, not on "number of timer interrupts".
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

10-Aug-08 11:25 PM

Dear guys,

Just to clear somethings over here, the reason why I need to set the
time-slice is due
to my project requirement. Example I have many tasks running from 1ms to
100ms.
But I can only give 10ms each to every task to accomplish its work. Hence
there will be
some task that can't complete on time during each computation cycle
therefore the time-slice is use to ensure no task will attempt to hover the
CPU time. The time slice also serve
as a deterministic way of knowing how many cycles it needs to complete a
particular long
task.

As for the quantum, it stated in the tech article that 3 quantums equal 10ms
for single processor and 15ms for multi-processor.

so it means -> 3 quantums = 3 clock ticks
And this quantums depends on the hardware abstraction layer selected for the
PC.

I can't really agree the relationship between the timeBeginPeriod an the
clock tick because its 2 different thing. The quantims clock ticks is the
default settings for the scheduler and the timeBeginPeriod only attempts to
change the resolution for the system timer frequency.

Any guys can over come this challenge?

10-Aug-08 11:43 PM

I'm afraid you're confusing project implementation choice (10 ms time slice)
with "requirement" and going the wrong way. Are you creating a custom job
scheduler? Or a realtime runtime environment? OR you just have constrain on
reaction time? The actual requirement will help you to choose your
implementation, not your arbitrary "10 ms timeslice" requirement.

11-Aug-08 03:09 AM

I'm trying to run a simulation of a particular application thats ported from
a realtime environment OS over to windows XP. I do know that WinXP is not
made to do that, I have no choice because my top thinks it can be achieved
with some form of function calls to the kernel level just like some RTOS do.
Running the RT application on windows XP is a requirement.

I'm not customing any scheduler but I need to be able to set a different
quantum value to achieve a 10ms time-slice or even 6ms time-slice for each
thread program.

imagine a read time system needs to run a number of critical tasks in 1
cycle time maybe 100ms. Due to certain tasks that may take up more time to
compute hence we need the time-slice here to ensure all task gets even
timing. Calling a task at a different time interval is different for the
time-slice here.

The objective here is to see if anyone has achieve to modify the quantum
value or even the tick value associate with the quantum value. something like
3 quantum = 1 tick = 15ms. I hope to achieve 3 quantum = 1 tick = 10ms or via
way.

Hope u and the rest can help me with this.

11-Aug-08 05:45 AM

something like

The options you have are very limited. Contrary to what other have
wrote, I think there is some connection between time slice and
timeBeginPeriod (I think the fact Sleep behaviour is affected is enough
to prove this, as I think Sleep works based on time slices as well), but
it is definitely not true that with 1 ms timer you get 1 ms slice.

Other way to influence this is using system wide registry controls
PsForegroundQuantum and PsPrioritySeparation.

You might want to check following articles:

http://www.wideman-one.com/gw/tech/dataacq/skedgran/skedgran.htm

http://technet.microsoft.com/en-us/sysinternals/bb963889.aspx
http://web.archive.org/web/20050208085528/http://www.sysinternals.com/ntw2k/info/nt5.shtml

Still, I do not think this will give you what you wish, and that is
close to RT OS. You might be able to get somewhat close to RT OS by
running on a dual core machine, locking affinity of one Real Time
priority thread to one core, and implementing your own scheduling in
this thread, providing your scheduled threads will cooperate with the
scheduler and never exceed your selected maximum slice time. Perhaps if
you decide to write a driver, you might be able to implement even your
own pre-emptive scheduling with lower slice using some interrupts this
way, but this is just a wild idea, I have absolutely no experience with
driver development.

Ondrej

VincentO napsal(a):

11-Aug-08 10:11 AM

Is your realtime OS using time slicing? I don't think so. Is it running in
the same processor with the same speed? What's the purpose of the
application? Is it audio-video input/output, or equipment control, or what?

If you need a particular set of tasks to complete in 100 ms, you don't need
to timeslice them. Just run them sequentially, that would have the least
overhead. You can run their thread with elevated priority, to ensure they
get their necessary processor time.

If you want to run it on XP, learn to use multithreaded capabilities of XP.

11-Aug-08 04:06 PM

Hi Tim!


Yes, it seems that you are right...

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

11-Aug-08 07:40 PM

Use multiple threads?

11-Aug-08 09:44 PM

To David - I know what you mean but I don't have any choice.

To Ondrej - Thanx for articles will check on it.

To Alexander - my realtime OS is using time-slicing. Can't tell my
application but
its running critical tasks. My architecture involves alot of threading,
don't worry I
know how to use multi-threading.

12-Aug-08 09:29 PM

IMHO the key problem is that in your RTOS you do the time slicing whereas in
XP you must consign that task to the 'black box' OS scheduler.  Once you get
over that intellectual obstacle, you should be fine!



Things that are important should have high priority.  Things that aren't
shouldn't.  Some algorithms might have to be redesigned (spin wait loops
etc.) to work on XP though.

14-Aug-08 01:02 AM

I came to a conclusion that the only way to set the time slice is through the
setting of the Quantum value which either I get a 6 or 36. Anyway thanx m.