RE: 2.1.3rc1 Performance

[Gary_Portnoy () itginc com]

I looked at the code in util.c and the only difference between 2.1.1rc1 
and 2.1.3rc1 is that they changed the output from signed to unsigned 
integers.  So the problem really lies in libpcap and more importantly the 
ps_drop function.

> From libpcap 0.8.3 pcap_dlci.c, i think this is Solaris specific (relevant 
portions upper-case):

         * "ps_recv" counts packets handed to the filter, not packets
         * that passed the filter.  As filtering is done in userland,
         * this DOES NOT INCLUDE packets dropped because we ran out
         * of buffer space.
         *
         * "ps_drop" counts packets dropped inside the DLPI service
         * provider device device because of flow control requirements
         * or resource exhaustion; it doesn't count packets dropped by
         * the interface driver, or packets dropped upstream.  As
         * filtering is done in userland, it counts packets regardless
         * of whether they would've passed the filter.

So, ps_drop/(ps_recv + ps_drop) is accurate for Solaris, at least as far 
as the calculation goes....

> From libpcap 0.8.3 pcap_linux.c, obviously Linux specific (relevant 
portions upper-case):

         *      "ps_recv" counts only packets that *passed* the filter,
         *      not packets that didn't pass the filter.  This INCLUDES
         *      packets later dropped because we ran out of buffer space.
         *
         *      "ps_drop" counts packets dropped because we ran out of
         *      buffer space.  It doesn't count packets dropped by the
         *      interface driver.  It counts only packets that passed
         *      the filter.

In Linux it seems ps_recv already contains the number dropped, so adding 
ps_drop to them could increase the counter.

At least that's what I am getting from all of this.  I am way out of my 
depth at this point, and have to admit that I could be totally off base.

-Gary-

--- Original Message ---
From: "snort user" <snortuser () hotmail com>
To: snort-users () lists sourceforge net
Subject: RE: [Snort-users] 2.1.3rc1 Performance
Date: Wed, 19 May 2004 22:11:50 +0000

Hi,

I use the .0.8.x branch of lipcap so Im not sure if this applies to 
earlier 
branches but all the following has been verified for this branch.

I actually noticed this a long time ago and a few other bugs maybe I 
should 
get on the devel list.
The stats are being reported inaccurately in the util.c file. Heres part 
of 
the problem

-- code snip --
"Snort analyzed %u out of %u packets, ",
                    ps.ps_recv, ps.ps_recv+ps.ps_drop);
- end snip--

ps_recv is the total packet recevied (meaning recieved and dropped)
ps_drop is the total dropped

So this is an inaccurate reading. The reallly bad thing is that whatever 
packet loss it tells you is actually worse since it uses 
(packets_dropped/(total_packet+packet_dropped)). Which is increasing the 
total packets it thinks its see. So if you seeing 40% packet loss is more 
like 66%.

Ive been doing extensive tests with snort lately and ive determined that 
even on a linux system with very high perfomance hardware you can really 
get 
more than 200 Mb/s without dropping packets unless you really limit your 
rules and remove preprocessors such as stream4 and frag2. There really 
needs 
to be a better pattern matching and optimization for snort to not drop so 
many packets.

Id be interested in hearing any schemes or ideas  people have tried for 
improving the performance of snort on linux.






-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
This message is for the named person's use only. This communication is for 
informational purposes only and has been obtained from sources believed to 
be reliable, but it is not necessarily complete and its accuracy cannot be 
guaranteed. It is not intended as an offer or solicitation for the purchase
or sale of any financial instrument or as an official confirmation of any
transaction. Moreover, this material should not be construed to contain any
recommendation regarding, or opinion concerning, any security. It may
contain confidential, proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission. If
you receive this message in error, please immediately delete it and all
copies of it from your system, destroy any hard copies of it and notify the
sender. You must not, directly or indirectly, use, disclose, distribute, 
print, or copy any part of this message if you are not the intended 
recipient.  Any views expressed in this message are those of the individual
sender, except where the message states otherwise and the sender is 
authorized to state them to be the views of any such entity.

ITG Inc. reserves the right to monitor and archive all electronic 
communications through its network. 

ITG Inc. Member NASD, SIPC
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
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