[Winpcap-users] Trying to handle a huge sniffed RTP packets traffic with winpcap

[DamioX]

Hello Guys,

  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).

  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.

  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.

  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.

  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) :(.

  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. From that point we are creating a couple of C#
objects in order to turn the unmanaged winpcap structures into C# managed
objects. After that, we are enqueueing these objects in an own circular
buffer and then another thread-pool is unbuffering this information. We have
figured out that our circular buffer is not discarding any packets.

  Our big concern is that currently we are experiencing Winpcap issues in
our application which has peaks of 25 concurrent calls, and if we think that
we might get peaks of 200 concurrent calls in the future, I'm not sure that
some application's performance improvement will make a big difference than
today's performance. We think that maybe a better approach would be to open
several times the sniffed interface and, for each one, sets the respective
IPAddresses and Ports' filter.

  Based on what I've told you, we want to know your opinion:

  a) Do you think the fact of opening several times the same interface and
setting better filters will be a good approach?
  b) How many concurrent winpcap handlers (for one interfaces) we may have
opened at the same time?
  c) We think that if we open the interface several times there will be
several winpcap kernel ring buffers. What size do you think would be the
best for each of these kernel ring buffers? If we think in having Kernel
ring buffers of 5 MBytes, and 200 concurrent calls, we would need 1 GByte of
memory dedicated to Kernel Ring Buffer. This memory requirement is not a
problem anyways.
  d) Do you think that we should concentrate our effort in trying to improve
our application's performance? We are just creating C# objects... That
shouldn't consume much time.


Thanks in advance for your help.
Damian Nardelli - C/C++/.NET Software Developer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.winpcap.org/pipermail/winpcap-users/attachments/20100818/6dada3b9/attachment.htm