I have an application that is performing transparent bridging.  Absolute
minimum latency is required to keep the packet RTTs to a minimum.

One thread is dedicated to sniffing packets (based off of a filter) and
adding to a queue.  A separate thread removes packets from this queue,
encrypts, encapsulates and sends to the destination side of the bridge.

Currently, the average time for packets to get sniffed, encapsulated and
sent out is 100ms.  Minimum time is 30 ms, with a max of 400ms.  This makes
for unacceptable RTTs.

Profiling the code shows that a packet waits in the queue for an average of
10ms.  It takes less than 1 ms to add the packet to the queue, and 5 ms to
remove the packet from the queue, encrypt and encapsulate.  The remaining 84
ms (on average) is spent waiting for pcap_next_ex() to return a packet.

The kernel buffer is set to 1MB.  The mintocopy is 40 bytes. I have played
with read timeouts from 10ms to 200ms, with varying results. The numbers
above are from a read timeout of 20ms.  10ms to 50 ms seems to have the best
results for small traffic loads.  The picture becomes more murky on larger
loads.  CPU load is minimum for small or large traffic loads.

What are the minimum times that I can expect to see in the ideal case of a
minimal amount of traffic?  Should I scrap the pcap_next_ex() is favor of
pcap_read() with a callback function?  How will that scale up under heavier
traffic loads?  Can I expect to get much more performance from using the
PacketReceivePacket() directly, saving the two function calls to
pcap_next_ex() and pcap_read()?

I know this is a common application of winpcap - someone has created this
wheel before.   If anyone has any experience with this level of winpcap, I'd
appreciate any insight into what's going on.

Thanks - 
J.J.
[EMAIL PROTECTED]
   



==================================================================
 This is the WinPcap users list. It is archived at
 http://www.mail-archive.com/[EMAIL PROTECTED]/

 To unsubscribe use 
 mailto: [EMAIL PROTECTED]
==================================================================

Reply via email to