Re: cpu usage by component

[Oliver Dain <omd1 () cornell edu>]

Thanks for your thoughts and suggestions.  In researching this I came across
the following paper which will be presented at RAID.  In the paper the
authors show that interupt handling time is significant although they don't
specify what NIC they used nor do they say what preprocessors were active.
Never-the-less its a pretty carefully done study and I thought somebody on
this list might find it interesting:

www.cse.nd.edu/~lambert/pdf/nids_raid03.pdf

I may do some profiling of my own since its not clear from the authors how
things break down inside the snort engine.  gprof is a good start, but it
won't give me any info about the time spent handling interupts and copy data
from kernel to user space.  Any ideas how to calculate that realistically?

On Thursday September 11 2003 12:28 am, Jeff Nathan wrote:
> On Tuesday, September 9, 2003, at 11:04 AM, Matt Kettler wrote:
> > I can't speak authoritatively, however based on my experience:
> >
> > conversation and portscan2 as a collective pair seem to use more
> > memory and CPU than anything else in snort by a factor of at least 4.
> > Based on what they do I can't quite understand why, but on low cpu
> > power systems these two cause extreme packet loss (>10%), even when
> > monitoring a mere 2mbit/sec link on a p-133 that was dedicated to
> > snort. Disabling those two caused the packet loss rate to drop by a
> > factor of 100 (from >10% to approximately 0.1%).
> >
> >
> > Based on what it does, I would venture to guess the stream4
> > preprocessor is about as much CPU time as a few case-insensitive
> > content searches. However, I would have expected the same of
> > conversation and portscan2 and clearly their usage is significantly
> > higher. However, stream4 doesn't seem to present a problem for low-end
> > hardware, so my expectations are probably within reason.
>
> An empirical way to measure the performance of Snort is to use gprof.
> Compile Snort with the profiling options and then let it run for a good
> log while.  Look at the call graph when you're done and you can see
> what Snort spends its time doing.
>
> > Getting packets from the NIC can be either easy or extremely painful
> > depending on your NIC design. However assuming you're using something
> > of reasonably efficient design (ie: not a realtek chipset) this
> > shouldn't be that much of the CPU time. Cross-overs from kernel to
> > user-space are a bit pricey, but the rule engine should be
> > considerably more expensive CPU wise.
>
> I/O is a major issue, but Snort can't do much about that in terms of
> running in userspace.
>
> > I know I'm not giving you any hard numbers, by my expectations would
> > be that the CPU usage would probably break down something along these
> > lines, ignoring conversation/portscan2 which would easily make these
> > numbers insignificant.
> >
> > rules engine - 70% (assuming a fair amount of content searching caused
> > by the traffic profile).
> > stream4 - 15% (assuming some processing an a memcopy to buffer the
> > data)
> > kernel copy to userspace - 10% (assuming most of the work is a memcopy
> > and a context switch)
> > nic management 5% (assuming that a double-copy isn't required due to
> > inefficient busmastering alignments)
>
> The call graphs will, of course, differ from operating system to
> operating system and across hardware platforms.

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



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
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