I’m developing an NDIS driver on Windows 2000. The hardware I’m working
with is a development platform working 10 times slower than my real
hardware. As a result I cannot inform the hardware every time a new packet
from NDIS arrives and I have the option of notifying it in the ISR routine
for my network device or the DPC I’m creating for handling interrupts.
I’ve noticed an interesting phenomena where when you put the notification
of a bulk of frames waiting on the host inside the DPC pings run at a
slower rate then when I put it into the ISR that issues the DPC. Also,when
moving some windows around the pings start running faster. The change is a
factor of more then 20. (40 ms vs 800 ms for a ping to go back and forth).
It seems that I have a DPC rate which is much slower than ISR rate.
Does anyone have an explanation for this?
Thanks,
Arik Halperin
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
This may or may not be related to your problem:
NDIS has a bug that when you call NdisMSendComplete() form *within*
MiniportSend() context (ie. *before* MiniportSend() actually returns
NDIS_STATUS_PENDING), the DPC will be delayed for about the interval
time of the MiniportCheckForHang() function.
[I know this problem has been reported to MS several times (starting
in 1998!) but AFAIK it has not been fixed yet.]
Thus, if you have a MiniportSend() instead of a MiniportSendPackets()
handler AND you call NdisMSendComplete() form *within* MiniportSend()
context, this is the explanation.
TEST: If you set the ‘CheckForHangTimeInSeconds’ to let’s say 10
seconds in your call to NdisMSetAttributesEx(), the PING delay should
also be around 10 seconds.
Stephan
On Wed, 13 Feb 2002 4:25:30, “arik halperin” wrote:
>
>I’m developing an NDIS driver on Windows 2000. The hardware I’m working
>with is a development platform working 10 times slower than my real
>hardware. As a result I cannot inform the hardware every time a new packet
>from NDIS arrives and I have the option of notifying it in the ISR routine
>for my network device or the DPC I’m creating for handling interrupts.
>I’ve noticed an interesting phenomena where when you put the notification
>of a bulk of frames waiting on the host inside the DPC pings run at a
>slower rate then when I put it into the ISR that issues the DPC. Also,when
>moving some windows around the pings start running faster. The change is a
>factor of more then 20. (40 ms vs 800 ms for a ping to go back and forth).
>
>It seems that I have a DPC rate which is much slower than ISR rate.
>
>Does anyone have an explanation for this?
>
>Thanks,
>Arik Halperin
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Thanks for the tip,
But I’m using MiniportSendPackets. Also due to hardware limitation I allways
copy the packet to a continuos buffer,so I dont have to do the send before
doing NdisMSendComplete(This copying is one hell of a suspect though…).
Arik
-----Original Message-----
From: xxxxx@hotmail.com [mailto:xxxxx@hotmail.com]
Sent: Wednesday, February 13, 2002 1:28 PM
To: NT Developers Interest List
Subject: [ntdev] Re: NDIS driver is influenced by windows GDI
This may or may not be related to your problem:
NDIS has a bug that when you call NdisMSendComplete() form *within*
MiniportSend() context (ie. *before* MiniportSend() actually returns
NDIS_STATUS_PENDING), the DPC will be delayed for about the interval
time of the MiniportCheckForHang() function.
[I know this problem has been reported to MS several times (starting
in 1998!) but AFAIK it has not been fixed yet.]
Thus, if you have a MiniportSend() instead of a MiniportSendPackets()
handler AND you call NdisMSendComplete() form *within* MiniportSend()
context, this is the explanation.
TEST: If you set the ‘CheckForHangTimeInSeconds’ to let’s say 10
seconds in your call to NdisMSetAttributesEx(), the PING delay should
also be around 10 seconds.
Stephan
On Wed, 13 Feb 2002 4:25:30, “arik halperin” wrote:
>
>I’m developing an NDIS driver on Windows 2000. The hardware I’m working
>with is a development platform working 10 times slower than my real
>hardware. As a result I cannot inform the hardware every time a new packet
>from NDIS arrives and I have the option of notifying it in the ISR routine
>for my network device or the DPC I’m creating for handling interrupts.
>I’ve noticed an interesting phenomena where when you put the notification
>of a bulk of frames waiting on the host inside the DPC pings run at a
>slower rate then when I put it into the ISR that issues the DPC. Also,when
>moving some windows around the pings start running faster. The change is a
>factor of more then 20. (40 ms vs 800 ms for a ping to go back and forth).
>
>It seems that I have a DPC rate which is much slower than ISR rate.
>
>Does anyone have an explanation for this?
>
>Thanks,
>Arik Halperin
—
You are currently subscribed to ntdev as: xxxxx@envara.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Comnpleting a send packet to NDIS before actually sending it is called
“lying sends” and should normally not cause any problems.
For sure “lying sends” do not cause the problems you describe *if* you
actually send out the packet(s) in your next DPC.
Stephan
On Wed, 13 Feb 2002 16:31:46 +0200, Arik Halperin
wrote:
>
>Thanks for the tip,
>But I’m using MiniportSendPackets. Also due to hardware limitation I allways
>copy the packet to a continuos buffer,so I dont have to do the send before
>doing NdisMSendComplete(This copying is one hell of a suspect though…).
>
>Arik
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com