Re: High DPC Use and a Method to Reboot a network card?

Hi Stephan

Thanks for your input.

We are sending UDP packets with a payload of 1028 bytes but I am talking
about quantity of packets; we are recording CBR MPEG2 constantly and the
system grinds to a half at a time which would coincide roughly with having
received 2^32 packets.

I am not familiar with how drivers work and so I don't know how the winpcap
driver interacts with the NIC or whether it could influence time spent in a
DPC.

Are you saying that it is impossible for winpcap to influence the DPC time
in any way? In which case this almost certainly appears to be driver
related and I am talking with 3Com about this at present.

I was figuring that the IC on the NIC performing the brains of the operation
could be reset in some way (or so our hardware genius here suggests as it's
the case with the ICs he is working with) so I hoped we could ask the driver
to reboot it; clearly it's a little more complicated than that however. I'm
already investigating the SetupDi commands to see what happens there...

Thanks for your help with this
Ian

"Stephan Wolf [MVP]" <stewo68@xxxxxxxxxxx> wrote in message
news:1146734079.236074.40750@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Are you saying you are sending 2^32 = ~4 billion *packets*, or are you
talking about the amount of *data* sent?

In either case, the amount of packets and/or data sent should of course
never cause such (or any other) problems.

Now what do you mean by "the NIC or WinPCap [..] becomes unstable"? I
don't think any protocol driver has a DPR, so it's most likely the
NIC's *driver* (not the NIC itself) that keeps spending time in DPCs.

In any event, you should try to get an updated driver.

A NIC driver cannot "reboot", but you can unload and reload it either
manually in the network configuration dialogue or in device manager or
by using SetupDi functions. For the latter see the DevCon sample source
code in the DDK.

Stephan
---
IMH wrote:
Hi All

I am using a 3COM 3C2000 NIC to capture MPEG from proprietry hardware.
After we have sent the NIC 2^32 packets of data the NIC or WinPCap which
we
are using to perform the capture becomes unstable, spending 50% of the
CPU
time servicing DPCs. This is very bad as on some machines these DPCs all
schedule on the same processor (it's a hyperthreaded box) and this makes
the
machine unusable.

I was hoping to be able to reboot the NIC in case that is the thing at
fault
but thus far I've had no success and cannot find anyt IOCTL commands that
might achieve this for me.

Can anyone help or advise on a newsgroup more appropriate for this
subject?

Thanks a lot
Cheers




.

Relevant Pages

  • Re: Filter Hook
    ... the callback routine is been invoked at DISPATCH_LEVEL. ... If you really have to keep such a queue for the packets, then the IP filter driver is not suitable for your needs since you have to process all the packets in the callback routine without any wait actionand return it to the tcpip driver immediately when the callback routine returns. ... What IRQL are you running at when you crash, ...
    (microsoft.public.development.device.drivers)
  • Re: High DPC Use and a Method to Reboot a network card?
    ... the amount of packets and/or data sent should of course ... NIC's *driver* that keeps spending time in DPCs. ...
    (microsoft.public.development.device.drivers)
  • Re: MAC bridging and sniffing packets with specific Ethertype
    ... That is, the Ethernet adapters are bound to the Mbridge driver (which, since ... Mbridge handles the bridging of packets between the adapters. ...
    (microsoft.public.windowsce.embedded)
  • Re: Degradation of TCP connection
    ... and running ifconfigon the target does indeed show ... the huge number of dropped Rx packets, ... RX stall (possibly due to mishandled RX overrun in the driver) ... RX interrupts have stopped firing ...
    (comp.os.vxworks)
  • Re: Degradation of TCP connection
    ... "Each of our boards will have an ethernet driver specific ... once you get a target into a failed state, ... when the VxWorks box stops ACKing packets sent from the Windows box. ...
    (comp.os.vxworks)