Snort mailing list archives
RE: 2.1.3rc1 Performance
From: Gary_Portnoy () itginc com
Date: Thu, 20 May 2004 14:53:34 -0400
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
Current thread:
- RE: 2.1.3rc1 Performance, (continued)
- RE: 2.1.3rc1 Performance Dirk Geschke (May 19)
- RE: 2.1.3rc1 Performance Gary_Portnoy (May 19)
- RE: 2.1.3rc1 Performance Darren Webb (May 19)
- RE: 2.1.3rc1 Performance Kreimendahl, Chad J (May 19)
- RE: 2.1.3rc1 Performance John Creegan (May 19)
- RE: 2.1.3rc1 Performance Kreimendahl, Chad J (May 19)
- RE: 2.1.3rc1 Performance Kreimendahl, Chad J (May 20)
- RE: 2.1.3rc1 Performance snort user (May 20)
- RE: 2.1.3rc1 Performance Gary_Portnoy (May 20)
- RE: 2.1.3rc1 Performance Kreimendahl, Chad J (May 20)
- RE: 2.1.3rc1 Performance Gary_Portnoy (May 20)