To WinPcap developers,

I read your paper titled: Profiling and Optimization of Software-Based
Network-Analysis Applications.   I built the version of npf.sys with the
rdtsc timestamp.      Although I  did not repeat the test many times, I
did not see a significant improvement in reliability.   

Note: To rebuild the npf.sys I had to use the Windows 2003 DDK even
though my test system is running Windows XP Pro.  When npf.sys was built
with the Windows XP sp1 DDK it blue screened.

It seems to me either Windows XP is not giving sufficient priority to
moving the packets from the NIC buffer to the Kernel buffer or it is not
moving the data from the Kernel buffer to the application buffer.  We
are dropping packets even when the CPU does not appear to be fully
utilized.  It seems like there must be an unnecessary awkwardness
somewhere.  

In our application we are in trouble if we loose more than a few
packets.   I plan to investigate Linux to see if it will work better.
If you have any ideas that can improve the reliability let me know and I
will test them.

Regards, 

Robert Thornthwaite
Input/Output, Inc.
phone:  281 879 2112
email:   [EMAIL PROTECTED] 
web:     http://www.i-o.com/


-----Original Message-----
From: Robert Thornthwaite 
Sent: Wednesday, February 04, 2004 7:06 PM
To: [EMAIL PROTECTED]
Cc: Mike Dawn
Subject: Sustained gigabit throughput performance with WinPcap.


Hi Loris,

I hope you do not mind if I ask for your advice on some performance
testing that I am doing.

The testing is to see what kind of sustained performance can be achieved
using the WinPcap software with Gigabit NICs.

The equipment involved: two PCs with Intel Pro/1000 MT NICs, WinPcap 3.1
beta, Windows XP PRO, and modified versions of the example programs
TestApp and TG.

TestApp just counts the packets and verifies the contents.

TG has been modified to accept two additional parameters.   The first
additional parameter is an interval in ms between periodic bursts of
packets.   The second additional parameter is the number of bursts of
packets that are to be transmitted.

An experiment I have done many times is:

On the sending PC:

Z:\t\io\bin\common>TG2 -i
\Device\NPF_{0D0261C1-4424-4C64-BB25-0AA9688DFAEE} -n 12000 -s 508 -p
320 -c 100 Traffic Generator v 0.9999 Copyright 1999 Loris Degioanni
([EMAIL PROTECTED]) Sends a set of packets to the network.
Generating 12000 packets every 320 ms period for 100 periods ... Elapsed
time: 32.469 Total packets generated = 1200000 Total bytes generated =
638400000 Total bits generated = 812232704 Average packets per second =
36958 Average bytes per second = 19661830 Average bits per second =
25015635


On the receiving PC:


Z:\t\io\bin\common>testapp
Packet.dll test application. Library version:3.0.1 alpha Adapters
installed:

1- \Device\NPF_{DEEC6B87-3FC3-4F87-BE5F-608B8C538BCC}
2- \Device\NPF_{D634A721-A389-40F6-91C3-AF2F102C6E09}
3- \Device\NPF_{6462A919-7BEA-418F-A8A8-ECB546D4F3F5}

Select the number of the adapter to open : 3


1200000 packets received.
47537 packets lost.
1152463 packets captured.
0 incorrect packets received.
1152463 packets received and verified

--------------------------------------------------------------

This is a typical result.   About 1 in 50 times all the packets are
received and verified.   My questions are:  Why do so many packets get
lost?   Should it be possible to consistently get good results?   If so
how?

I have tried adjusting parameters for the NIC and for WinPcap but I have
not been able to consistently get better results.   I have also tried
increasing the priority of the TestApp process.

The NIC parameters have adjusted are:

Adaptive Inter-frame Spacing 
Flow Control
Interrupt Moderation Rate
Receive Descriptors (set to 2048, nothing else tried.)

Changing these NIC parameters did not have a significant effect.

The Winpcap parameters I have adjusted are:

PacketSetMinToCopy size ( works best when set high, currently at
12800000 ) Application buffer size ( also set to 12800000 )
PacketSetMinToCopy size ( tried 640000, 64000, 6400 ), no significant
effect. PacketSetReadTimeout ( tried 1000, 500, 50 ), no significant
effect.  

If you have any ideas I would like to hear them.  I can supply the
modified example programs on request.

Thank you for your attention.

  
Regards,

Bob



Robert Thornthwaite
Input/Output, Inc.
phone:  281 879 2112
email:   [EMAIL PROTECTED] 
web:     http://www.i-o.com/


================================================================= 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