[Winpcap-users] Re: [Winpcap-team] High CPU Use Tracked to DPC Time

Gianluca Varenni gianluca.varenni at cacetech.com
Mon May 8 14:43:27 GMT 2006


I haven't tried to replicate the problem on my machines, but it seems quite strange to me that the DPC time goes to 50% (probably a HT/multicore/multiprocessor machine and 1 CPU is 100%!?!). 

Even if there's a wrap-around bug in WinPcap, I would expect a blue screen, no packets captured or packets completely dropped, but not a polling at DPC level (as you seem to be experiencing). As someone pointed out on the ddk newsgroup, it's possible that a buggy nic driver causes this effect by not properly acknowledging an interrupt and continuously scheduling DPCs on the system.

In any case, I'll try to reproduce the bug on one of my machines here.

Have a nice day

  ----- Original Message ----- 
  From: Ian Hawley 
  To: winpcap-team at winpcap.org ; winpcap-users at winpcap.org 
  Sent: Friday, May 05, 2006 9:27 AM
  Subject: [Winpcap-team] High CPU Use Tracked to DPC Time

  Hello Everyone, apologies if you receive this email twice!


  The company I work for has been using winpcap for some time now and we recently noticed an issue which we thought might be NIC related but could of course be WinPCap related as well and I thought I’d float it by the mailing list and see if anyone was aware of an issue.


  Basically we recording MPEG2 via a UDP packet stream from proprietary hardware and after a period of time the machine enters a state where the CPU usage is around 50+% and 50% if that usage is spent servicing DPC requests according to perfmon.exe.  We initially felt this might be the NIC we are using but we have since recreated this by bombarding a different NIC with UDP data through a test application and this has presented on that NIC also.  At present I am wondering whether it is an OS issue (we are running Windows 2000 Service Pack 4 on many boxes) but I am also concerned it might be our IBM Boxes and of course, our capture mechanism uses WinPCap and not Winsock.


  The curious thing about this collapse of CPU is that it appears to manifest around about the time when the host machine/application has received 2^32 packets.  Knowing the data rate we are sending to the box we are able to predict quite accurately as to when the machine will enter this state and it appears to suggest that some driver or piece of hardware or windows itself is wrapping a 32bit counter and not handling the wrap correctly.


  We are presently trying various other network cards, Windows XP and different PCs to see if we can get it to manifest but I wanted to ask the WinPCap community if there was something that might go pop with such a large volume of data?  By accident we are using an oldish beta of WinPCap 3.0 but one of our engineers hasn’t seen any evidence that the release version of 3.0 nor a subsequent version might fix this.  We are however going to set our test apps running on a similar box using WinPCap 3.1.


  Note again that we have detached our proprietary hardware from the PC and managed to generate the problem without using that hardware so we are very confident that this has nothing to do with the issue.  The curious thing is that once the CPU has jumped into this state it does not matter whether the data continues to be fed to the NIC; if you stop the application that is bombarding the NIC with data, the CPU continues to be stoically at the 50% mark.  Curiously the number DPCs queued/second appears to drop from what appears normal at circa 2000/second to around 40/second (this is while data is going into it, I have no metrics for when there is no data atm).  As strange is that if you unplug the NIC cable, then the CPU drops back to ostensibly zero and the PC is happy again.  Plug the cable back in however and the CPU shoots back to 50%.  Unplug the cable from the PC and plug it into a hub with nothing else attached and it is still at 50%.


  I would like to emphasize that the position we are in presently means that we do not know if it is the IBM PCs we are using, the 3COM NIC, some BIOS setting, the Operating System (Old systems are running 2K and we are trying to see if it presents on XP) or some setting we have incorrect somewhere, as unlikely as that might seem.  I am not saying it is definitely a WinPCap issue, but it would be very interesting if any of the winpcap team could think if a way that it might be.


  Any help would be greatly appreciated.


  Kind Regards

  Ian Hawley



  No virus found in this outgoing message.
  Checked by AVG Free Edition.
  Version: 7.1.392 / Virus Database: 268.5.4/332 - Release Date: 04/05/2006


  Winpcap-team mailing list
  Winpcap-team at winpcap.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.winpcap.org/pipermail/winpcap-users/attachments/20060508/b276250c/attachment.htm

More information about the Winpcap-users mailing list