No subject

Thu Nov 23 16:36:19 EST 2017

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.


--- Original Message ---
From: "snort user" <snortuser at ...125...>
To: snort-users at
Subject: RE: [Snort-users] 2.1.3rc1 Performance
Date: Wed, 19 May 2004 22:11:50 +0000


I use the .0.8.x branch of lipcap so Im not sure if this applies to 
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 
get on the devel list.
The stats are being reported inaccurately in the util.c file. Heres part 
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 
more than 200 Mb/s without dropping packets unless you really limit your 
rules and remove preprocessors such as stream4 and frag2. There really 
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

More information about the Snort-users mailing list