Hi All,
I am trying to figure out how much time a function inside my driver has spent executing.
I dnt want to use KeQueryPerformanceCounter as its not going to consider the time when my thread was swapped out.
From WDK i got this KeQueryRuntimeThread function which gives accumulated time thread has spent in User & Kernel Space.
Documentation says it outputs the time on clock ticks, but i am seeing a output number as ‘2’ for a approximately 200 milliseconds. I think this is the KernelTime member inside thread structure.
So can somebody help me in understanding if my assumptions are correct?
I am thinking that this function outputs the time as a UNIT of 100 Milliseconds.
I am trying to figure out how much time a function inside my driver has spent executing.
I dnt want to use KeQueryPerformanceCounter as its not going to consider the time when my thread was swapped out.
>From WDK i got this KeQueryRuntimeThread function which gives accumulated time thread has spent in User & Kernel Space.
Documentation says it outputs the time on clock ticks, but i am seeing a output number as ‘2’ for a approximately 200 milliseconds. I think this is the KernelTime member inside thread structure.
So can somebody help me in understanding if my assumptions are correct?
I am thinking that this function outputs the time as a UNIT of 100 Milliseconds.
No. You can find out the length of a clock tick by using
KeQueryTimeIncrement. The typical value is 10ms.
You have a driver process that takes 200ms? What on earth are you doing?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Tim Roberts[SMTP:xxxxx@probo.com]
Reply To: Windows System Software Devs Interest List
Sent: Tuesday, April 03, 2007 7:28 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] SI UNITS for KeQueryRuntimeThread
No. You can find out the length of a clock tick by using
KeQueryTimeIncrement. The typical value is 10ms.
Recently I checked it and at all systems (more than 10) I saw the value 15.625 ms. XP and Vista, both x86 and x64.
> Tim wrote:
> No. You can find out the length of a clock tick by using
> KeQueryTimeIncrement. The typical value is 10ms.
>
Recently I checked it and at all systems (more than 10) I saw the value 15.625 ms. XP and Vista, both x86 and x64.
Well, 15 is equal to 10, for very small values of 15…
I’ve read that the server systems (i.e. Windows 2003 Server) use a
different tick time, but I thought it was larger yet.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Thanks Tim, Michal,
I am working on graphics miniport driver which is taking too long to resume around 250 ms.
This time i’ve measured via PwrTest tool of MSFT.
Most of time spent is into saving and restoring huge memory blocks via memcpy or in loops.
So firstly i wanted to have a reliable way of measuring the time a thread is consuming inside some functions. I am not able to see any exposed API in WDK which gives good enf granualirity.
Is there any such way thru which i can profile the time a thread is been actually executing?
And what is the fastest way avialable today to do huge memory transfer operations.
I’ve tried SIMD instruction set and it shows improvement but is there any better way to do this.
I am working on graphics miniport driver which is taking too long to resume around 250 ms.
This time i’ve measured via PwrTest tool of MSFT.
Why is that too long?
Most of time spent is into saving and restoring huge memory blocks via memcpy or in loops.
So firstly i wanted to have a reliable way of measuring the time a thread is consuming inside some functions. I am not able to see any exposed API in WDK which gives good enf granualirity.
Is there any such way thru which i can profile the time a thread is been actually executing?
There are kernel profile tools, but they are invasive, and somewhat
difficult to use in real time. Personally, for that kind of one-off
instrumentation, I’d just use the cycle counter. Unless a function
takes more than a few milliseconds, it’s unlikely that you’ll be
context-switched in the middle.
And what is the fastest way avialable today to do huge memory transfer operations.
I’ve tried SIMD instruction set and it shows improvement but is there any better way to do this.
If you are transferring to/from graphics memory across a bus, then it’s
likely that the CPU instructions themselves are not the bottleneck.
It’s more likely the bus.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.