<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=text/html;charset=iso-8859-1 http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.7600.16588"></HEAD>
<BODY style="PADDING-LEFT: 10px; PADDING-RIGHT: 10px; PADDING-TOP: 15px"
id=MailContainerBody leftMargin=0 topMargin=0 CanvasTabStop="true"
name="Compose message area">
<DIV><FONT face=Calibri>Damian,</FONT></DIV>
<DIV><FONT face=Calibri></FONT> </DIV>
<DIV><FONT face=Calibri>a) can solve the problem in the short term, but you
still don't know why you are dropping the packets. And given the fact that
wireshark doesn't drop packets (and wireshark does dump packets to disk when
capturing), I think you are some non negligible bottleneck in your
code.</FONT></DIV>
<DIV><FONT face=Calibri>b) technically there is no limit. However I would
definitely avoid opening 25 (or worse, 200) capture instances at the same time,
one per RTP stream.</FONT></DIV>
<DIV><FONT face=Calibri>c) Again, I would definitely avoid that. The kernel
buffer memory is kernel non paged memory, which is a scarce resource, expecially
on a 32bit system (I think the limit on a 32bit system is a total of some
hundreds MB of non paged pool). I would definitely go with one single
capture instance and demultiplexing the packets in your application</FONT></DIV>
<DIV><FONT face=Calibri>d) Definitely. I think you should concentrate in
analyzing where the bottleneck is. Usually the bottleneck is in the marshalling
of the packet buffer into a managed object. What I would do is create a minimal
C# application that just receives the packets with your wrapper and counts them.
Do the same with a C application based on the native WinPcap APIs. And then
compare the packet drop rate *and* the CPU load in both the cases. You said "we
are just creating C# objects". I would be quite worried about that "just".
Suppose you receive 10k packets per second. You will create 10k objects every
second. It's true, memory allocation in a .NET application is extremely fast.
But eventually the GC will kick in to release those objects, maybe causing some
delays. Even if you are working with managed code, I would probably use a
preallocated pool of "packet objects".</FONT></DIV>
<DIV><FONT face=Calibri></FONT> </DIV>
<DIV><FONT face=Calibri>Just my two cents</FONT></DIV>
<DIV><FONT face=Calibri>GV</FONT></DIV>
<DIV style="FONT: 10pt Tahoma">
<DIV><FONT size=3 face=Calibri></FONT><FONT size=3
face=Calibri></FONT><BR></DIV>
<DIV style="BACKGROUND: #f5f5f5">
<DIV style="font-color: black"><B>From:</B> <A title=damiox@gmail.com
href="mailto:damiox@gmail.com">DamioX</A> </DIV>
<DIV><B>Sent:</B> Wednesday, August 18, 2010 8:03 AM</DIV>
<DIV><B>To:</B> <A title=winpcap-users@winpcap.org
href="mailto:winpcap-users@winpcap.org">winpcap-users@winpcap.org</A> </DIV>
<DIV><B>Subject:</B> [Winpcap-users] Trying to handle a huge sniffed RTP packets
trafficwith winpcap</DIV></DIV></DIV>
<DIV><FONT face=Calibri></FONT><FONT face=Calibri></FONT><BR></DIV>Hello
Guys,<BR><BR> We are using winpcap (4.1.0.1753) to handle a huge RTP
packets traffic being sniffed from an Audio Gateways of my company. Our
application has the ability to persist specific RTP packets to Hard-Disk (we get
the IP Addresses and Ports information to filter these data from our
application).<BR><BR> Our tests were executed in a Windows 2003 Standard
Edition x64 (64 Bits) server, Intel Xeon E5520 2.27 Ghz & 6.00 GB of
RAM.<BR><BR> We have noticied that we are getting peaks of RTP packets
traffic corresponding to 25 concurrent calls (G.711 codec) from this Audio
Gateway. Based on our notes, the current traffic being spanned is quite lower
than 1 MByte per second.<BR> <BR> Our application starts and opens
the interface which is getting the mentioned traffic and sets the interface's
filter as "udp". Later, we are filtering (from our application) the IP Addresses
and Ports needed to be persisted. In our current test, we are just saving one
call in the Hard-Disk (only two sniffed RTP packets flow) with a different
Thread-Pool. Thus, we are receiving peaks of 25 concurrent calls, but a
different application thread is saving just 1 call to Hard-Disk.<BR><BR>
The problem is that we are experiencing several packet losses of several seconds
each in this persisted call. We checked that Wireshark is not loosing so many
packets. Thus, we tried to increase our winpcap kernel buffer to 4 Mbytes, 10
Mbytes, 500 Mbytes. In all cases we detected a performance improvement, but we
are still having packet losses (2 seconds more or less sporadically with a
kernel buffer of 500 Mbytes) :(.<BR><BR> Our application is developed in
C# .NET 3.5 and wrapping the Winpcap APIs. Our application's piece we are
putting our eyes to is when Winpcap invokes the wrapped C# Callback.