High performance counter in kernel mode

[Anand Choubey]

Hi

I am writing NIDS IM driver. It assigns a time stamp to every packet and
driver wroks on 500 to 800 Mbps. Which kernal method or alogorithm should be
used for it? It read KeQueryPerformance counter method having some problem
about time jumping. NdisGetCurrentSystemTime will change if system time is
changed.

Please me suggest me what should I do for it?
--
With regards
thanks
Anand Choubey

[Stephan Wolf [MVP]]

NdisGetCurrentSystemTime() is only updated once every system tick, so
its update frequency is quite low (as opposed to its granularity -
don't confuse these two).

KeQueryPerformanceCounter() should be fine. Note, however, that NDIS
drivers should usually only use Ndis...() routines. This is a must for
miniports, but really required not for protocols. Since an IM
implements both a miniport and a protocol, you can call non-NDIS
routines here (I usually prefer to avoid these).

Stephan
---

[Stephan Wolf [MVP]]

Anand Choubey wrote:
> It read KeQueryPerformance counter method having some problem
> about time jumping. NdisGetCurrentSystemTime will change if system time is
> changed.

AFAIK, this counter is derived from the CPU's clock count, so it is
completely independent of the "system time".

Stephan

[Anand Choubey]

Hi
Thanks for reply.
Yes, KeQueryPerformanceCounter is independent from System clock but it can
generate wrong time and NdisGetCurrentSystemTime is totally based on system
time.

But What methods should be used? Is it KeQueryTickCount useful?

--
With regards
thanks
Anand Choubey

[Stephan Wolf [MVP]]

AFAIK, KeQueryTickCount() and NdisGetCurrentSystemTime() are both
updated at the same time intervals. It is just that KeQueryTickCount()
simply counts timer interrupts since system start whereas
NdisGetCurrentSystemTime() returns the current system time. But the
time between two updates of this system time is excatly the time
between two incerements of the tick count. Plus the system time can be
adjusted by the user.

I never used KeQueryInterruptTime() but that seems to be an option.

Also, I guess what you can do is use NdisGetCurrentSystemTime() as a
basis for the receive or send time you want to set in an NDIS_PACKET
via NDIS_SET_PACKET_TIME_TO_SEND() and NDIS_SET_PACKET_TIME_RECEIVED(),
respectively. Then use KeQueryPerformanceCounter() to adjust this time
stamp.

If you see the same return value for two consecutive calls to
NdisGetCurrentSystemTime(), simply call KeQueryPerformanceCounter() and
use the difference between the current and last call to
KeQueryPerformanceCounter() to adjust NdisGetCurrentSystemTime() by a
maximum of KeQueryTimeIncrement().

This is probably most useful under heavy load where
NdisGetCurrentSystemTime() returns the same value for a whole bunch
(say 100) of received packets. It should be clear that
KeQueryPerformanceCounter() will still return different values, which
you can use to measure the time elapsed since the last call to
NdisGetCurrentSystemTime().

Check the DDK docs on all these functions for more information.

Stephan
---
Anand Choubey wrote:

[Anand Choubey]

Hi Stephan,

Thanks for prompt reply.

About keQueryPerformanceCounter, msdn writes:
"Use this routine as infrequently as possible. Depending on the platform,
KeQueryPerformanceCounter can disable system-wide interrupts for a minimal
interval. Consequently, calling this routine frequently, as in an iteration,
defeats its purpose of returning very fine-grained, running time-stamp
information. Calling this routine too frequently can degrade I/O performance
for the calling driver and for the system as a whole."

And I read on net that KeQueryPerformanceCounter can generate wrong time. Is
there any kernel method for getting time at good precision at micro second
level? Apart from KeQPC and NdisGetCurrentSystemTime.

--
With regards
thanks
Anand Choubey

[Pavel A.]

"Anand Choubey" wrote:
...

> And I read on net that KeQueryPerformanceCounter can generate wrong time.

KeQueryPerformanceCounter is _the_ API to use.
If it gives wrong results, there might be a problem with Windows setup on the
machine - it's not your problem.

Regards,
--PA

[Maxim S. Shatskih]

> And I read on net that KeQueryPerformanceCounter can generate wrong time.

IIRC it is mapped to RDTSC, and this instruction return the number of CPU clock
cycles since CPU startup.

With Intel's power management feature of slowing the CPU down to save the
laptop batteries, RDTSC starts to be not so reliable, the only guaranteed fact
is that it grows, and grows very fast.

Also on SMP these counters are not synchronized across CPUs.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
ma...@storagecraft.com
http://www.storagecraft.com

[Pavel A.]

"Maxim S. Shatskih" <ma...@storagecraft.com> wrote in message news:eO91S7Ph...@TK2MSFTNGP05.phx.gbl...

>> And I read on net that KeQueryPerformanceCounter can generate wrong time.
>
> IIRC it is mapped to RDTSC, and this instruction return the number of CPU clock
> cycles since CPU startup.

No, not on all platforms - especially the new ones that have High Performance Timers.

--PA