hi all:
i use the KeQueryPerformanceCounter() to get the current number of the ticks. can i convert this ticks to system time(UTC)?
Thanks!
Is there something wrong with KeQuerySystemTime?
On Dec 4, 2007 2:57 AM, wrote:
> hi all:
> i use the KeQueryPerformanceCounter() to get the current number of the
> ticks. can i convert this ticks to system time(UTC)?
>
> Thanks!
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
Mark Roddy
> i use the KeQueryPerformanceCounter() to get the current number of the
ticks. can i convert this ticks to system time(UTC)?
Not directly, no. Indirectly perhaps yes, within the limits of clock cycle
timing on the time base for the performance counter. On laptops that isn’t
great.
Why not use KeQuerySystemTime instead?
Thanks for Mark Roddy & Loren Wilton
I want to get a timestamp for every IRP passed my driver. When I use KeQuerySystemTime, I found the timestamp is not exactly. there maybe two or three IRPs have the same timestamp. so I want to use KeQueryPerformanceCounter to get a ticks and convert the ticks to system time. can you give me some advice?
Thanks!
> I want to get a timestamp for every IRP passed my driver. When I use
KeQuerySystemTime, I found the timestamp is not exactly. there maybe
two or three IRPs have the same timestamp. so I want to use
KeQueryPerformanceCounter to get a ticks and convert the ticks to system
time. can you give me some advice?
Are you working on server systems or laptops? Do you expect a lot of
thermal management to be happening on the processors your driver runs on?
On many recent generation processors thermal management will affect the
accuracy of the performance counter, or more exactly will affect the clock
rate that it counts at.
You basically need to know the frequency of the performance counter. From
that you can take a timestamp using BOTH the performance counter and system
time at some initial point in time. Then at a later time you can get the
performance counter value, take a difference from the initial value, convert
it to 100ns units, and add the difference to the initial value of system
time. This will give you your timestamp.
I’m too lazy to look it up now, but I believe KeQueryPerformanceCounter
returns two results. One is the performance counter value, and the other is
the performance counter nominal frequency. Dividing the performance counter
value by the frequency will produce a result in seconds from some arbitrary
start time. Appropriate scaling of the math operands will give you results
in 100ns units.
The accuracy of that depends on how accurately the performance counter
actually counts at the reported frequency. On a system with heavy thermal
management there may be significant differences between the reported and
actual count frequencies.
If you are coding for machine room servers, you can probably expect the
counter to count at very nearly the reported frequency. On a laptop you
can’t. From that you can decide how often you should get a new base
correlation between system time and performance counter value. Remember
that system time may be rounded to about 16ms, so you would like to only get
a new base infrequently to avoid problems with jitter in your base
correlation. On a machine room server I’d probably go for a new correlation
somewhere between once a day and once every 10 minutes or so. On a laptop
(where I have very little real experience) I’d probably get a new base
correlation about once a minute.
You can obviously check the accuracy of the performance counter frequency by
periodically getting both the system time and the performance counter, and
computing the system time from the performance counter value. If the
predicted and actual values differ by more than say 50ms, it would be time
to establish a new base correlation.
Note: An alternate approach is to use the processor timestamp counters,
which has much lower overhead. This is often the same counter that is used
for the performance counter. There is no guarantee that the timestamp
counters in each processor will have the same value at any point in time.
So you need an array of base values, one per processor, and you need to know
which processor you are running on when you take a timestamp measurement.
Loren
Thanks Loren
You give me some idea that i never think about. I never think that the thermal management will affect the performance counter. Maybe I will change my way. can you tell me you know on how to use the processor timestamp counters, thank you very much!
> can you tell me you know on how to use the processor timestamp counters,
thank you very much!
Sorry, I don’t understand your question. Try again?
Loren
Hi Loren. Thank you for your answer.
In your “Note”, you told me that " a alternate approach is to use the processor timestamp counters ". I don’t know how to get the processor timestamp counter, Can you tell me how to get it?
does it use the __asm RDTSC?
Thanks!
KeQueryPerformanceCounter doesn’t count “ticks,” at least not in the
sense that I think you mean. It counts clock cycles in whatever time
base is being used by the underlying HAL. This can’t be directly
converted into “ticks” or UTC time since the clocks used for
high-accuracy (or medium-accuracy) time stamps aren’t tied to the
clocks that track wall-clock time. You may get significant drift
between them.
- Jake Oshins
wrote in message news:xxxxx@ntdev…
> Thanks for Mark Roddy & Loren Wilton
> I want to get a timestamp for every IRP passed my driver. When I
> use KeQuerySystemTime, I found the timestamp is not exactly. there
> maybe two or three IRPs have the same timestamp. so I want to use
> KeQueryPerformanceCounter to get a ticks and convert the ticks to
> system time. can you give me some advice?
> Thanks!
>
>
> KeQueryPerformanceCounter doesn’t count “ticks,” at least not in the
sense that I think you mean. It counts clock cycles in whatever time
base is being used by the underlying HAL. This can’t be directly
converted into “ticks” or UTC time since the clocks used for
high-accuracy (or medium-accuracy) time stamps aren’t tied to the
clocks that track wall-clock time. You may get significant drift
between them.
- Jake Oshins
Hi Jake,
Can you comment on what conditions might be required such that the HPET
counter is used by the OS for some kernel timing API? My understanding is
the HPET was created to solve some of the ugly timstamping issues on modern
power managed SMP systems. Will KeQueryPerformanceCounter use the HPET timer
if the OS finds it? Can you comment on differences in HPET usage on W2k3,
Vista and W2k8? I’ve noticed many systems have HPET’s, but also many seem to
by default disable them in the BIOS. Is there any good reason for this?
Thanks.
Jan
Hi Jake
Thanks for your answer!
As I think, if I take a timestamp “BOTH the performance counter and system time at some initial point in time.” then when I want to get a system time in somewhere, i get the performance counter and convert it to system time ,which as Loren said. May I get significant drift between the converted system time and real UTC time?
I want to use the performance counter is only becase KeQuerySystemtime can not give me the exact system time. if this convert will bring me a significant drift. How can i get a exact system time?
Thanks!
> does it use the __asm RDTSC?
Yes, but better, use ReadTimestampCounter(). (I think that is defined for
both kernel and user, I’ve only used it in user mode).
You can’t use inline assembly in drivers these days.
Loren
> > does it use the __asm RDTSC?
Yes, but better, use ReadTimestampCounter(). (I think that is defined for
both kernel and user, I’ve only used it in user mode).
My understanding is the processor timestamp counter is not so useful anymore
as its processor local (each processor has a tsc and they are not guaranteed
to be in sync) and its speed goes up and down depending on things like
thermal management. The tsc is still useful if you want to raise IRQL to at
least DISPATCH_LEVEL (so you don’t get context switched to a different
processor with a different tsc) and want to measure a bounded block of
instructions over a short time span. It is very high resolution. If you
don’t somehow inhibit processor switches, it can “appear” to step backwards
(when your thread context switches to a processor with a tsc behind the
current processor tsc).
The HPET (see the Intel document on high performance event timer, also
sometimes known as the multimedia timer) on the other hand, has a single
instance across all processors and doesn’t change to handle thermal
management. I believe its sub microsecond resolution and as a memory mapped
device address is fairly efficient to read (although it’s still an external
bus cycle, so much slower than local cache latency). It’s also not
universally on every system; although most modern systems at my office seem
to have it if you just turn it on in the bios.
Jan
> My understanding is the processor timestamp counter is not so useful
anymore
as its processor local (each processor has a tsc and they are not
guaranteed
True
to be in sync) and its speed goes up and down depending on things like
thermal management. The tsc is still useful if you want to raise IRQL to
at
Also true.
least DISPATCH_LEVEL (so you don’t get context switched to a different
processor with a different tsc) and want to measure a bounded block of
instructions over a short time span. It is very high resolution. If you
don’t somehow inhibit processor switches, it can “appear” to step
backwards
(when your thread context switches to a processor with a tsc behind the
current processor tsc).
The trick is to either stick to one processor (somehow) or to at least know
which processors took the beginning and ending timestamps. Over short
periods of time (a few seconds) processors are likely to track fairly
closely in frequency, even with thermal management operating.
You can arrange with a bit of cleverness to get reasonably accurate base
timestamps from various processors at convenient and reasonably frequent
intervals, and map those timestamps back to some external counter, such as
system time. At that point it is a fairly trivial excercise to get time
differences, even across processors, that are reasonably accurate over a
short interval.
Having an accurate and fast external counter is often a better choice. Not
all systems have such a counter, and if they do the bus latency to get to it
can be a pain. However, RDTSC itself seems to be a fence instrution, at
least on some processors, so it can be amazingly slow all by itself in
comparison to a normal instruction flow.
It can often be a better choice on current systems to adjust the time
quantum and use the system timer with millisecond accuracy rather than
15.625 ms accuracy. That way you get a synchronized timestamp at fairly low
overhead, and don’t have to do (much of) anything that people might consider
evil.
Loren
On Wed, Dec 05, 2007 at 03:05:57AM -0500, Zeaphyr@126.com wrote:
Hi Jake
Thanks for your answer!
As I think, if I take a timestamp “BOTH the performance counter and
system time at some initial point in time.” then when I want to get a system
time in somewhere, i get the performance counter and convert it to system time
,which as Loren said. May I get significant drift between the converted system
time and real UTC time?
I want to use the performance counter is only becase KeQuerySystemtime
can not give me the exact system time. if this convert will bring me a
significant drift. How can i get a exact system time?
Thanks!
Somewhat related to this thread (dealing with the correlation between
performance counters and system time) but almost entirely unrelated to
kernel development…
I did some research a while back on the entropy sources used in GS
(GuardStack) cookies which are used to help mitigate the exploitation of
stack-based buffer overflows. One of the entropy sources used to generate a
GS cookie is performance counter state (QueryPerformanceCounter). I found
that it may be possible to recover a significant portion of the 64-bit
performance counter state that was used to contribute entropy to a GS cookie
by taking into account the system uptime when the GS cookie was being
created and the frequency at which the performance counter is updated
(QueryPerformanceFrequency). In limited testing, the end result was a
consistent recovery or biasing of all but the low 17 bits of the performance
counter state (which is still a significant entropic factor). A more
detailed description can be found here:
http://uninformed.org/index.cgi?v=7&a=2&p=13
To investigate how far off my estimates were based on the actual value of
the performance counter at the time that a cookie was generated, I created a
scatter plot showing the difference between the actual value and estimated
value across 5000 samples. There is an obvious trend that might make it
possible to better refine the approach taken to project the original value
of the performance counter:
http://uninformed.org/index.cgi?v=7&a=2&p=20
Anyway, slightly off topic, but some folks may find it interesting. I’m
aware of the potential for drift and other issues relating to thermal
management, but in at least some circumstances it appears that prior
performance counter state can be inferred from the uptime of the system in
relation to the performance frequency. If there are other things that might
be worth considering, feel free to follow-up with me off-list.
Matt
My memory is that Vista and later will use an HPET if the BIOS says
it’s there. My memory could be wrong.
I suppose that BIOSes are shipping with it turned off because BIOS
guys are usually terrified that some OS that they haven’t tested with
(and they never seem to test with the latest OS) will barf if they
turn on some new feature.
- Jake
“Jan Bottorff” wrote in message
news:xxxxx@ntdev…
>> KeQueryPerformanceCounter doesn’t count “ticks,” at least not in
>> the
>> sense that I think you mean. It counts clock cycles in whatever
>> time
>> base is being used by the underlying HAL. This can’t be directly
>> converted into “ticks” or UTC time since the clocks used for
>> high-accuracy (or medium-accuracy) time stamps aren’t tied to the
>> clocks that track wall-clock time. You may get significant drift
>> between them.
>>
>> - Jake Oshins
>
> Hi Jake,
>
> Can you comment on what conditions might be required such that the
> HPET
> counter is used by the OS for some kernel timing API? My
> understanding is
> the HPET was created to solve some of the ugly timstamping issues on
> modern
> power managed SMP systems. Will KeQueryPerformanceCounter use the
> HPET timer
> if the OS finds it? Can you comment on differences in HPET usage on
> W2k3,
> Vista and W2k8? I’ve noticed many systems have HPET’s, but also many
> seem to
> by default disable them in the BIOS. Is there any good reason for
> this?
>
> Thanks.
>
> Jan
>
>
Whether you get drift between system time and UTC time depends on the
quality of your motherboard and on whether you’ve configured the OS to
use a network time source. If a network time source is available, the
OS will make sure that they match up.
- Jake
wrote in message news:xxxxx@ntdev…
> Hi Jake
> Thanks for your answer!
> As I think, if I take a timestamp “BOTH the performance counter
> and system time at some initial point in time.” then when I want to
> get a system time in somewhere, i get the performance counter and
> convert it to system time ,which as Loren said. May I get
> significant drift between the converted system time and real UTC
> time?
> I want to use the performance counter is only becase
> KeQuerySystemtime can not give me the exact system time. if this
> convert will bring me a significant drift. How can i get a exact
> system time?
> Thanks!
>