The only thing that I can say is that you can't assume any latency limit when capturing or sending packets with WinPcap. As you already did, you can play with the mintocopy and the buffer size, however the number of factors that play a role when capturing a packet is high (I can mention for example interrupt processing cost and number of context switches) and many of them are not under the control of the capture driver and the application. I add that the winpcap driver is engineered for best capture performance, this involves that its optimizations are conceived to loose the minimum amount of packets under heavy network loads and not to obtain low latency. If you have really strict latency requirements, the most effective thing to do is writing kernel code, modifying the NPF driver for your needs.
Loris > 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] > ================================================================== > ================================================================== This is the WinPcap users list. It is archived at http://www.mail-archive.com/[EMAIL PROTECTED]/ To unsubscribe use mailto: [EMAIL PROTECTED] ==================================================================
