I've been playing around with Phil Wood's mmap'ed libpcap, and before I
started doing any snort benchmarking with it I thought I'd do some tcpdump
benchmarking with it. The results seem a bit odd to me, and I'm wondering
how trustworthy the statistics it's generating are.
FYI, I'm running linux 2.6.5, compiled with CONFIG_PACKET=y and
CONFIG_PACKET_MMAP=y, using Phil Wood's libpcap (libpcap-1.0.20041001) and
tcpdump version 3.8.3 on an Intel Corp. 82547EI Gigabit Ethernet Controller
connected back-to-back with another machine. The machine is a single
processor hyperthreaded PentiumIV 2.8GHz with 2GB ram. I'm generating
high-data-rate traffic by doing a netcat-to-netcat copy (actually
bash-to-netcat) of an approximately one gigabyte file from one machine to
the other, while running tcpdump with the following variables:
PCAP_STATS=0x21fff PCAP_VERBOSE=1 PCAP_FRAMES=max PCAP_PERIOD=1000
and a command line of:
tcpdump -nl -i eth0 -s 1550 -w /dev/null
The statistics show that it's dropping a lot of packets. But I'm starting
to have some misgivings about the statistics. For instance, one period
shows:
S:1104424579 105432 124051 229376 0 229340 245289582 112388288 86 14612
52256 1 1 0
The numbers that disturb me here (besides the 124K dropped packets) are the
fact that the bytes seen by the device are 245289582, or 1,962,316,656 bits
in one second. Although the link *is* full duplex, the only traffic going
out *should* be acks, and probably not too many of those. I doubt that I'm
actually getting 1.8 gigabits/sec throughput on a single gigabit ethernet
adaptor.
What are the chances that I'm overrunning a counter somewhere, and those
statistics really aren't acurate?
BTW, if you're interested, the full output of the dump is:
# PCAP_STATS=0x21fff PCAP_VERBOSE=1 PCAP_FRAMES=max PCAP_PERIOD=1000
tcpdump -nl -i eth0 -s 1550 -w /dev/null
libpcap version: 1.0
Kernel filter, Protocol 0300, MMAP mode (32760 frames, snapshot 1550),
socket type: Raw
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 1550
bytes
S:1104424560.546902 5 0 6 0 6 612 490 3 5 2 0 000000001.999415 0
S:1104424563.546088 6 0 6 0 6 612 588 4 11 2 1 000000002.000414 0
S:1104424567.547916 8 0 8 0 8 816 784 6 19 2 1 000000001.999415 0
S:1104424573.563900 95735 36458 157913 0 157939 169099026 103808790 6103
30234 34023 1 000000001.000021 0
S:1104424574.563921 83591 0 57996 0 57997 60128382 86743150 0 15545 83591 0
000000001.000011 0
S:1104424575.568316 120302 0 124601 0 124614 129166068 124217412 797 4807
95722 1 000000001.000035 0
S:1104424576.568351 118027 0 141841 0 141825 147048574 121900342 0 24554
118027 0 000000001.000013 0
S:1104424577.568364 113946 2508 120859 0 120874 125489772 117706956 0 7460
113946 0 000000001.000018 0
S:1104424579.006888 105432 124051 229376 0 229340 245289582 112388288 86
14612 52256 1 000000001.000000 0
S:1104424580.006888 29618 0 5654 0 5665 6092528 31727884 0 11470 29618 0
000000001.000632 0
S:1104424581.184533 92437 0 83867 0 83904 91238226 100061026 3802 5627 30830
1 000000001.000000 0
S:1104424582.184533 93410 14956 109340 0 109289 115767926 98966684 6475 757
41597 0 000000001.000428 0
853494 packets captured
1031467 packets received by filter
177973 packets dropped by kernel
S:0.184961 977 0 0 0 0 0 1051546 8 1734 977 0 000000000.3807635573 0
Or is this just what I'm getting?
-Joe Patterson, CCNP, CISSP
Senior Security Engineer
SteelCloud, Inc.
(954)318-3200x105
jpatterson@asgardgroup.com
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Snort-users mailing list
Snort-users@lists.sourceforge.net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users
