Re: High resolution timer on kernel mode

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

No. You have misunderstood me. I do not call NDIS IM driver function from
the TDI driver. I'm just saying that if I want things done in a hurry in my
TDI driver I do it from my TDI driver dispatcher function. If I want things
done in a hurry in my NDIS IM driver I do it in my IM driver ptReceivePacket
function.

The two drivers are seperate! One does talk to the other via ioctrl, but
this has nothing to do with getting things done in a hurry!

If you have a driver in the system with hardware that can generate high res
interrupts then do your work in the interrupt handler ... just be careful
your code is not too expensive ... if it is running at such high res!

Mirage2k2.

"vs" wrote:

Really ! That is possible? To call a NDIS IM driver function from the
TDI driver. Will the TDI driver have access to the global data, spin
locks created by the NDIS IM driver. If this is possible then it will
make my life much simpler. I have a special driver guaranteed to be in
the system and the hardware controlled by this driver can generate
interrupts on demand at microsecond granularities...

mirage2k2 wrote:
Also, I have a TDI driver and its IOCTRL dispatch function gets called by
everyone at some rediculous frequency ... put one dbgprint in it and then
open DebugView and the system grinds to a halt ... it get called that often!

If I want anything done in a hurry then I call my function from inside this
dispatch function.

"mirage2k2" wrote:

OK. For me the situation is different. I dont necessarily need a high res
timer all of the time ... I just need my packet dequeue to keep pace with my
packet enqueue ... so I can always get rid of the packets as fast as I get
them, if I need to. So for me if the packets are coming in very slowly ...
it doesn't matter ... there may only be 5 packets per 300ms ... but thats ok
because I only need to dequeue them at 5 packets per 300ms. When packets
come in very fast ... say 5 packets per 1ms (60mbps) then I must dequeue them
at 5 packets per 1ms ... which is better than a timer will get me and I do
this off of the back of my ptReceivePacket function ... which is called by
the miniport driver ... probably in its interrupt ... which is not timer
generated but nic harware interrupt generated.

It was a few years ago that I really looked into all of the alternatives,
and from what I remember there is no way of getting a better than 10ms timer
... you can setup your timer to go off at about 5ms and sometimes it will go
off at 7ms, sometimes 10ms ... there is no guaranty. I even tried 2
staggered 10ms timers ... started the first, then waited 5ms and started the
second ... guess what? Both timers went off at the same time ... not 5ms
apart as I hoped.

You can have a thread running that just loops and measures time (using very
high res functions) and this thread can be used to generate your timer, i.e.
do your callback, at a much finer res ... but the functions you use to
measure the time are very expensive when you call them in a loop like this
and you may well bring the system to a halt!

You can use ExSetTimerResolution to change the resolution of the system
clock interrupt but this will affect the entire system and the help tells you
to use it with caution. You would probably use this function if, and only
if, this system does nothing at all except run your driver!

Good luck.
Mirage2k2

"vs" wrote:

Mirage,

Could you elaborate a bit more on the trick you used in the IM driver.
Does it also help for the single TCP connection case. High latencies
with single TCP connection scenario like a copy send seem to suffer
most...

ExSetTimerResolution seem to be prohibited by WHQL. There seem to be no
alternatives for NDIS drivers that are not NDIS-WDM. Also since IM
drivers cannot be WDM drivers. Are there any facilities to generate
high resolution timer callbacks (not measure time) for NDIS/NDIS IM
drivers?

regards
vs

Tim Roberts wrote:
Anand Choubey <AnandChoubey@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

Please suggest me kernel mode api for high resolution time.
I read that keQueryPerformanceCounter is high performance counter but it
disable interrupts.

It depends. On a uniprocessor machine, KeQueryPerformanceCounter uses the
motherboard countdown timer, which can take a couple of microseconds. I
find it extremely unlikely that having interrupts disabled for the length
of two port IN instructions will affect your application, unless you call
it a half million times a second.

On a multiprocessor machine, KeQPC uses the cycle counter, and interrupts
do not have to be disabled.
--
- Tim Roberts, timr@xxxxxxxxx
Providenza & Boekelheide, Inc.




.

Relevant Pages

  • Re: High resolution timer on kernel mode
    ... The problem I have is that this driver is ... interrupts then do your work in the interrupt handler ... ... timer all of the time ... ... So for me if the packets are coming in very slowly ... ...
    (microsoft.public.development.device.drivers)
  • Re: Timedirft between system clock and hwclock
    ... The timer mechanism stores only one pending ... if the clock interrupt occurs twice while some driver has ... clock rate from 100 interrupts per second to 250 or more. ... You may next want to try to identify which device driver is causing the troubles. ...
    (Fedora)
  • Re: device driver for the SGI system clock, mmtimer
    ... Here is the driver with the interrupt support "killed". ... The timer hardware was designed around the multimedia timer specification by ... +static int mmtimer_ioctl; ... * of the page where the registers are mapped) for the counter in question. ...
    (Linux-Kernel)
  • [PATCH] Remove if_watchdog use
    ... private timer to drive a stats timer and I merely hooked into that timer. ... other cases a new callout needed to be added to the driver. ... Hooks into the stat timer to drive the watchdog timer. ...
    (freebsd-current)
  • [PATCH] Remove if_watchdog use
    ... private timer to drive a stats timer and I merely hooked into that timer. ... other cases a new callout needed to be added to the driver. ... Hooks into the stat timer to drive the watchdog timer. ...
    (freebsd-net)