How do you set time-slicing for Windows XP
VincentO
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
Jochen Kalmbach [MVP]
timeBeginPeriod(1);
--
Greetings
Jochen
My blog about Win32 and .NET
http://blog.kalmbachnet.de/
Alexander Grigoriev
slice.
But if someone needs to change scheduler timeslice, he's doing something
wrong.
"Jochen Kalmbach [MVP]" <nospam-Joch...@holzma.de> wrote in message
news:%23JT295S%23IHA...@TK2MSFTNGP03.phx.gbl...
Jochen Kalmbach [MVP]
> No, it won't. It just changes timer resolution. Timer tick != scheduler time
> slice.
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
"timer-resolution" is used for scheduling... or am I wrong?
Pavel A.
> Hi Alexander!
>> No, it won't. It just changes timer resolution. Timer tick != scheduler
>> time slice.
>
> 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
> "timer-resolution" is used for scheduling... or am I wrong?
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
Jochen Kalmbach [MVP]
> 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.
???
See comment in the documentation of "timeBeginPeriod":
<quote>
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.
</quote>
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.
m
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.
"Jochen Kalmbach [MVP]" <nospam-Joch...@holzma.de> wrote in message
news:OIkh96X%23IHA...@TK2MSFTNGP05.phx.gbl...
Pavel A.
> Hi Pavel!
>
>> 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.
>
> ???
>
> See comment in the documentation of "timeBeginPeriod":
>
> <quote>
> 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.
> </quote>
>
> So setting "1" means, that the scheduler will be called much more than
> normal.
Agreed.
> 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.
Still not sure that the thread quantum would become shorter if the timer
ticks more often.
--PA
Alexander Grigoriev
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.
"Jochen Kalmbach [MVP]" <nospam-Joch...@holzma.de> wrote in message
news:OcYD9eW%23IHA...@TK2MSFTNGP05.phx.gbl...
Alexander Grigoriev
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.
"m" <m@b.c> wrote in message news:OIa45SZ%23IH...@TK2MSFTNGP06.phx.gbl...
Jochen Kalmbach [MVP]
>> 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.
>
> Still not sure that the thread quantum would become shorter if the timer
> ticks more often.
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
"while(1);"), the thread switch count will be much more with
"timeBeginPeriod(1)" than without...
Alexander Grigoriev
"Jochen Kalmbach [MVP]" <nospam-Joch...@holzma.de> wrote in message
news:%23oTvFse%23IHA...@TK2MSFTNGP04.phx.gbl...
m
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.
"Alexander Grigoriev" <al...@earthlink.net> wrote in message
news:OdOQsAc%23IHA...@TK2MSFTNGP02.phx.gbl...
Tim Roberts
>
>>> 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.
>>
>> Still not sure that the thread quantum would become shorter if the timer
>> ticks more often.
>
>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
>"while(1);"), the thread switch count will be much more with
>"timeBeginPeriod(1)" than without...
Nope. I just tried it; it didn't change. The thread quantum is based on
TIME, not on "number of timer interrupts".
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
VincentO
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?
Alexander Grigoriev
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.
"VincentO" <Vinc...@discussions.microsoft.com> wrote in message
news:DE486651-DC32-4C7D...@microsoft.com...
VincentO
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.
David Craig
add a few million more to get the rights to release your own Windows - if
you can. I suspect if you offer enough money you can, but would it be worth
it? Remember the old saying: "You can't put a 10 gallon head in a 5 gallon
hat".
"VincentO" <Vinc...@discussions.microsoft.com> wrote in message
news:719DF381-7344-4141...@microsoft.com...
Ondrej Spanel
> value or even the tick value associate with the quantum value.
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):
Alexander Grigoriev
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.
"VincentO" <Vinc...@discussions.microsoft.com> wrote in message
news:719DF381-7344-4141...@microsoft.com...
Jochen Kalmbach [MVP]
Hi Tim!
> Nope. I just tried it; it didn't change. The thread quantum is based on
> TIME, not on "number of timer interrupts".
Yes, it seems that you are right...
m
"VincentO" <Vinc...@discussions.microsoft.com> wrote in message
news:719DF381-7344-4141...@microsoft.com...
VincentO
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.
m
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.
"VincentO" <Vinc...@discussions.microsoft.com> wrote in message
news:5DFEFBEA-5CDA-47A7...@microsoft.com...
VincentO
setting of the Quantum value which either I get a 6 or 36. Anyway thanx m.