I am using the KeWaitForSingleObject() to do delay in my kernel mode driver like following:
LARGE_INTEGER nWaitTime;
nWaitTime = RtlConvertLongToLargeInteger(-1000 * 10);// I need 0.001sec
KeSetTimer(&fdoData->kTimer, nWaitTime, NULL);
KeWaitForSingleObject(&fdoData->kTimer, Executive, KernelMode, FALSE, NULL);
But when I use DbgView to catch the actual delay, I found that it can only reach 0.01second at most and cannot satisfy my requirement, 0.001sec.
Any comment is appreaciated.
I am afraid you should start looking for some other OS if you are so concerned about precision - Windows NT has never been a real-time system. The maximal *theoretically* possible precision that you can get under Windows NT is that of a clock tick (i.e. 10-15 ms, depending on the kernel and HAL version - the system has no notion of time in between two clock ticks). You can get this precision only if the system has absolutely nothing to do at the moment - in practical terms, unless you do it in context of real-time priority thread, the results are going to be much less precise, depending on how busy the system is , as well as on priority of the target thread against other threads in the system. Furthermore, even if your thread is of the highest-possible thread priority of 32, it still has the lowest hardware CPU priority, because you can wait only at IRQL< DISPATCH_LEVEL. Therefore, if interrupts occur and/or DPCs have to be processed, you are going to wait untill they all get processed, no matter how high the priority of your thread is…
The bottom line - don’t expect Windows NT to act like RTOS. It is not the one,and, apparently, will never become the one…
Anton Bassov
See KeQueryTimeIncrement for the current timer resolution on the platform. KeDelayExecutionThread would appear to be a much simpler mechanism to delay for a clock tick. If you really want to screw a system up, look at ExSetTimerResolution.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-288099-
xxxxx@lists.osr.com] On Behalf Of xxxxx@accton.com.cn
Sent: Monday, May 28, 2007 2:34 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] KeWaitForSingleObject() can only reach 0.01sec timeoutI am using the KeWaitForSingleObject() to do delay in my kernel mode
driver like following:
LARGE_INTEGER nWaitTime;nWaitTime = RtlConvertLongToLargeInteger(-1000 * 10);// I need
0.001sec
KeSetTimer(&fdoData->kTimer, nWaitTime, NULL);
KeWaitForSingleObject(&fdoData->kTimer, Executive, KernelMode,
FALSE, NULL);But when I use DbgView to catch the actual delay, I found that it can
only reach 0.01second at most and cannot satisfy my requirement,
0.001sec.Any comment is appreaciated.
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Please, don’t send the same letter for me.
Thank you very much.
On 5/28/07, xxxxx@accton.com.cn wrote:
>
> I am using the KeWaitForSingleObject() to do delay in my kernel mode
> driver like following:
> LARGE_INTEGER nWaitTime;
>
> nWaitTime = RtlConvertLongToLargeInteger(-1000 * 10);// I need
> 0.001sec
> KeSetTimer(&fdoData->kTimer, nWaitTime, NULL);
> KeWaitForSingleObject(&fdoData->kTimer, Executive, KernelMode,
> FALSE, NULL);
>
> But when I use DbgView to catch the actual delay, I found that it can only
> reach 0.01second at most and cannot satisfy my requirement, 0.001sec.
>
> Any comment is appreaciated.
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> If you really want to screw a system up, look at ExSetTimerResolution.
To be honest, I did not even dare mentioning ExSetTimerResolution() in order to avoid outraged replies to my post…
However, once you mentioned it anyway, I will say a little bit more about it
The only thing you may achieve this way is to make sure that the thread will wake up at more precise time (if you want to make any use of ExSetTimerResolution(), apart from screwing up the system, you have to set the thread priority to the highest possible level immediately before calling ExSetTimerResolution() that has to be called immediately before entering the wait state and immediately after thread resumes execution - the first call will change resolution and the second one has to restore defaults). This part can get done.
However, what are you going to do when it comes to the actual operation that you want to be started at some precise time? If you restore the thread priority, then it can get pre - empted throughout the operation and and spend unspecified period of time in standby state, and, hence, you will be unable to to accomplish your operation within strict time constaraints (i.e. something what the OP is, apparently, so desperate to do) anyway. Unless the operation is very, very brief, leaving the thread priority at the highest possible level may have quite negative consequnced for the system performance. Furthermore, you are still not protected against interrupts, and, hence, even at the highest possible level of thread priority your operation may get interrupted, which will also
decrease the precision. Certainly, you could raise IRQL to CLOCK2_LEVEL, but this should not be done for anything that requires just few instructions and no access to non-paged memory…
To summarize, I think the OP should just stop expecting real-time results from Windows NT - this system has not been designed for this purpose…
PS. The funniest thing here is that the OP has asked this question in 2 newsgroups and under different names - he appears as “Liang Junming” here and as “Kevin” in ‘drivers’ MSFT NG…
Anton Bassov
Try KeStallExecutionProcessor for such a short period of time
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@accton.com.cn
Sent: Sunday, May 27, 2007 11:34 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] KeWaitForSingleObject() can only reach 0.01sec timeout
I am using the KeWaitForSingleObject() to do delay in my kernel mode
driver like following:
LARGE_INTEGER nWaitTime;
nWaitTime = RtlConvertLongToLargeInteger(-1000 * 10);// I need
0.001sec
KeSetTimer(&fdoData->kTimer, nWaitTime, NULL);
KeWaitForSingleObject(&fdoData->kTimer, Executive, KernelMode,
FALSE, NULL);
But when I use DbgView to catch the actual delay, I found that it can
only reach 0.01second at most and cannot satisfy my requirement,
0.001sec.
Any comment is appreaciated.
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Anton Bassov wrote:
PS. The funniest thing here is that the OP has asked this
question in 2 newsgroups and under different names - he
appears as “Liang Junming” here and as “Kevin” in ‘drivers’
MSFT NG…
Happens all the time. I wonder if these outsourcing places have some training session where they say, “always post your mailing list questions with an American-sounding name”.
If so, I wonder why they bother giving this advice, since it’s always obvious from the post contents when someone is not from the USA…and a quick check of the headers can always confirm it.
A number of years ago I commented I did not like answering questions from
people using hotmail and similar accounts, I got a plea for help from the
poster an employee of an oversea’s outsourcing firm, stating “My company
has a policy against allowing us to ask questions on newsgroups about
drivers, since we are supposed to be driver experts, but none of us have
ever done a driver for Windows”. The poster then through out his questions
which involved the fact that he had 4 weeks to produce and test a file
system filter driver!
I still curse the oversea’s firms, but I realize that I should be cursing
the idiots who recomend or hire these firms based on fancy buildings and
marketing, without checking their competance for the work that is needed.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
wrote in message news:xxxxx@ntdev…
> Anton Bassov wrote:
>
>> PS. The funniest thing here is that the OP has asked this
>> question in 2 newsgroups and under different names - he
>> appears as “Liang Junming” here and as “Kevin” in ‘drivers’
>> MSFT NG…
>
> Happens all the time. I wonder if these outsourcing places have some
> training session where they say, “always post your mailing list questions
> with an American-sounding name”.
>
> If so, I wonder why they bother giving this advice, since it’s always
> obvious from the post contents when someone is not from the USA…and a
> quick check of the headers can always confirm it.
>
Don,
I still curse the oversea’s firms, but I realize that I should be cursing
the idiots who recomend or hire these firms based on fancy buildings and
marketing, without checking their competance for the work that is needed.
As we have already established on another thread, they are attracted by supposedly low costs…
and then find themselves paying a fortune for the code that does not work and cannot be fixed
in any way, other than completely rewriting it from the scratch. There is a saying in Russian that
“tightfist always pays the double”. According to your story about FS driver that job was given to some outsourcing company and not to you, “double” may a gross underestimation when it comes to outsourcing…
Anton Bassov
Hello Kevin
It seems you want something like “wait for no more than” when all you can
have is something like “wait for no less than”. So quid pro quo, the group
has answered your question, so please tell us the reason you have this
requirement. So often with these sorts of so-called requirements these are
not the real requirements and there is an alternative approach that at least
has a chance to work.
Best Wishes
Lyndon
wrote in message news:xxxxx@ntdev…
>I am using the KeWaitForSingleObject() to do delay in my kernel mode driver
>like following:
> LARGE_INTEGER nWaitTime;
>
> nWaitTime = RtlConvertLongToLargeInteger(-1000 * 10);// I need
> 0.001sec
> KeSetTimer(&fdoData->kTimer, nWaitTime, NULL);
> KeWaitForSingleObject(&fdoData->kTimer, Executive, KernelMode, FALSE,
> NULL);
>
> But when I use DbgView to catch the actual delay, I found that it can only
> reach 0.01second at most and cannot satisfy my requirement, 0.001sec.
>
> Any comment is appreaciated.
>
Appreciate for all of your help. It makes me understand the relative kernel behavior more.
I am now tuning my driver’s performance, which is a kernel mode driver based on TDI. I need to minimize the delay time within my kernel mode driver. BUT at the other side, I need to also minimize the CPU consuming. When I use the KeWaitForSingleObject(), the performance is not good enough, while when I don’t use KeWaitForSingleObject() and only have a while() loop, the CPU usage is very high. So I just want to find a solution to have a balance between these two sides.
If you have any comment, I would appreaciate for that very much.
Just to reinforce my earlier point, 1mS is not such a short time nowadays,
when you can get say 300,000 CPU clocks x N cores in that time!
Could the Windows designers consider some more modern schedule periods for a
future release? A uSleep() in microseconds for user mode apps would be very
useful and conceptually simple.
Changing process swaps from o(10mS) to o(10uS) is going to happen in the
next decade, surely.
M
----- Original Message -----
From: Doron Holan
To: Windows System Software Devs Interest List
Sent: Monday, May 28, 2007 6:01 PM
Subject: RE: [ntdev] KeWaitForSingleObject() can only reach 0.01sec timeout
Try KeStallExecutionProcessor for such a short period of time
d
> Could the Windows designers consider some more modern schedule periods for a
future release?
Mike, it is not that simple…
If timer interrupt starts firing all over the place, you may get an overall system performance degradation - pretty much depends on such factor as overall system overload. In practical terms, it means that impact on overall system performance may be different in different situations, let alone on different hardware architectures. The default setting were, apparently, chosen after a lot of testing as *generally* optimal settings (although they may be not optimal in some particular situation - this is why the system exports ExSetTimerResolution(), although it does not allow to set
frequency of timer interrupt to anything below 1 ms)
A uSleep() in microseconds for user mode apps would be very useful and conceptually simple.
To begin with, tick frequency is meaningfull only for real-time priority threads. For example, if you have specified 30 ms (i.e 2 ticks) in a Sleep() call that is made by normal-priority thread, it may well happen that execution will resume in, say, 150 ms(i.e. 10 ticks) - it depends on how busy the system is.
Furthermore, even for real-time priority threads things are not that simple. Once you cannot sleep for less that a clock tick, in order to allow to sleep in microseconds they will have to allow setting the frequency of timer interrupt in microseconds, which, in vast majority of cases, would be just a disaster for overall system performance - the system will hardly be able to do anything, apart from processing timer interrupt. Normally when you enter the waiting state you expect something to happen meanwhile. However, nothing is going to happen if the system has no chance to do anything, apart from processing timer interrupt, which just defeats the purpose of sleeping/waiting in microseconds
Anton Bassov
In TDI as in most any NT driver, it is far better to design your solution to
work asyncronously using event callbacks and completion routines and *not*
(generally) a thread based polling loop. If you are ‘tuning’ your solution
by inserting what amounts to be a ‘sleep’ into a loop you likely have the
wrong design for the work-load.
There are always exceptions, of course, and perhaps your situation is one of
them. Usually a thread based polling system is polling a very low priority
activity with realtively long poll times to prevent CPU waste.
What are you processing in the while() loop between calls to
KeWaitForSingleObject()? Are you processing packets (TDUs) from TDI?
Regards,
-dave
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@accton.com.cn
Sent: Monday, May 28, 2007 10:55 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] KeWaitForSingleObject() can only reach 0.01sec timeout
Appreciate for all of your help. It makes me understand the relative kernel
behavior more.
I am now tuning my driver’s performance, which is a kernel mode driver based
on TDI. I need to minimize the delay time within my kernel mode driver. BUT
at the other side, I need to also minimize the CPU consuming. When I use the
KeWaitForSingleObject(), the performance is not good enough, while when I
don’t use KeWaitForSingleObject() and only have a while() loop, the CPU
usage is very high. So I just want to find a solution to have a balance
between these two sides.
If you have any comment, I would appreaciate for that very much.
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
> Could the Windows designers consider some more modern schedule periods for a
future release? A uSleep() in microseconds for user mode apps would be very
useful and conceptually simple.
But KeStallExecutionProcessor is equivalent to uSleep. True, it is not exactly a sleep because the thread is in a busy loop. But this is also true for most uSleep implementations. The only difference is that some uSleep implementations are “smart”, and combine a thread sleep with a busy loop when the waiting period is long enough. Something that you could easy achieve in Windows combining KeStallExecutionProcessor with KeDelayExecutionThread.
You can get similar functional from user space by combining Sleep with a busy loop polling QueryPerformanceCounter. It is a popular technique for semi/seudo real-time behavior.
>> Could the Windows designers consider some more modern schedule periods for a
> future release?
Mike, it is not that simple…
If timer interrupt starts firing all over the place
You don’t need higher frecuency interrupts for getting more accurate timing resolution.
Vista supports HPET, it is required for a Vista logo, and you will be hard pressed to find a Vista capable PC that doesn’t have HPET. With HPET aperiodic interrupt timers, the system could easily implement uSleep both at the kernel and user level.
>You can get similar functional from user space by combining Sleep with a
busy loop polling >QueryPerformanceCounter. It is a popular technique for
semi/seudo real-time behavior.
Yes, I do and it works. The problem is the user sees 100% CPU usage and
thinks the app is broken, even though it is fully yielding.
So we’re back to where I came in!
But I bet MS and Intel are already designing a future system to bring
context switching forward from the 1980’s to this century. I imagine that in
5 years all our current apps will be running in a virtual legacy machine so
they can continue to work so slow, while our next apps will cruise along in
the fast lane, perhap with a nS of processing here and there when they
really need it…
(oh and driver kernel support that runs at an untrusted level to keep the
machine safe but driver enabled, and - but sorry, time to wake up… the VS
SP1 has finally downloaded!)
M
----- Original Message -----
From: xxxxx@rahul.net
To: Windows System Software Devs Interest List
Sent: Tuesday, May 29, 2007 5:15 PM
Subject: RE:[ntdev] KeWaitForSingleObject() can only reach 0.01sec timeout
Could the Windows designers consider some more modern schedule periods for
a
future release? A uSleep() in microseconds for user mode apps would be
very
useful and conceptually simple.
But KeStallExecutionProcessor is equivalent to uSleep. True, it is not
exactly a sleep because the thread is in a busy loop. But this is also true
for most uSleep implementations. The only difference is that some uSleep
implementations are “smart”, and combine a thread sleep with a busy loop
when the waiting period is long enough. Something that you could easy
achieve in Windows combining KeStallExecutionProcessor with
KeDelayExecutionThread.
You can get similar functional from user space by combining Sleep with a
busy loop polling QueryPerformanceCounter. It is a popular technique for
semi/seudo real-time behavior.
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Mike Kemp wrote:
Just to reinforce my earlier point, 1mS is not such a short time
nowadays, when you can get say 300,000 CPU clocks x N cores in that time!Could the Windows designers consider some more modern schedule periods
for a future release? A uSleep() in microseconds for user mode apps
would be very useful and conceptually simple.
It’s not “very useful”. It might be useful in certain rather specific
situations, but a reliance on them often indicates a misunderstanding of
the problem, or an attempt to work around buggy hardware that should
probably be hidden in a kernel driver anyway.
Also, I’m not sure what you mean by “more modern schedule periods”.
Linux also uses 10ms ticks. Linux does have usleep for user-mode apps
and nanosleep for kernel mode, but they’re implemented by spin stalls.
Changing process swaps from o(10mS) to o(10uS) is going to happen in
the next decade, surely.
I’m not convinced of that. After decades of meteoric rises, the
evidence suggests that clock speeds may have reached a physical
limitation. The first 3 GHz processors hit the market in 2002. That
was 5 years ago, and we still have not seen a 4 GHz processor. That’s a
significant stall in what had been a very steady exponential graph…
We’re packing more stuff on the same die, but we’re not ramping up the
clocks.
Plus, as processors get more complicated, the cost of a task switch
increases as well. That’s really the balance; you want the scheduling
period to be long enough that the cost of task switching is amortized
over the time each process has to do useful work.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Mike Kemp wrote:
But I bet MS and Intel are already designing a future system to bring
context switching forward from the 1980’s to this century. I imagine
that in 5 years all our current apps will be running in a virtual
legacy machine so they can continue to work so slow, while our next
apps will cruise along in the fast lane, perhap with a nS of
processing here and there when they really need it…
I think your VM vision is likely, but I’m not sure the context switching
revolution you envision will EVER happen. We’re talking about a
mechanism to make the user think that his computer is doing 100 things
at once. Human reaction times have not changed since the 1980s, and are
unlikely to change significantly in the foreseeable future. Indeed, a
more likely 10-year scenario is a computer with 100 processors, each one
executing a single process without EVER yielding the CPU.
(oh and driver kernel support that runs at an untrusted level to keep
the machine safe but driver enabled, and - but sorry, time to wake
up… the VS SP1 has finally downloaded!)
Be aware that it is not universally agreed that VS SP1 actually
represents an improvement to VS2005.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> But KeStallExecutionProcessor is equivalent to uSleep.
KeStallExecutionProcessor(), in actuality, does not really stall execution, as MSDN claims…
KeStallExecutionProcessor() is based upon infinite loop that makes RDTSC instruction - execution breaks out of this loop when the requested interval elapses. KeStallExecutionProcessor() does not either disable interupts or affect CPU’s Task Priority Register. Therefore, interrupts (unless this call is made at IRQL==CLOCK2_LEVEL) and context switches(unless thread has highest possible priority) may occur while this loop runs. There is no guarantee that KeStallExecutionProcessor() will return strictly after the requested interval elapses- some delays are possible…
In order to make KeStallExecutionProcessor() work the way MSDN describes it maskable interrupts have to be disabled. It looks like MSFT “forgot” this part…
Anton Bassov