Re: cpu usage by component

[Jeff Nathan <jeff () snort org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Thursday, September 11, 2003, at 11:52 AM, Matt Kettler wrote:

> At 12:28 AM 9/11/2003 -0400, Jeff Nathan wrote:
> > 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.
>
> Agreed. However, I'm lazy so I was only offering educated ball-park 
> guesses :) However your suggestion is a good one, I often forget that 
> not everyone knows that profilers exist. :)

My response was so high brow that even Dennis Miller would respond with 
a funny look. :)
> > > 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.
>
> True. It's outside of snort's control entirely, but it also relevant 
> to be aware of when trying to find ways of tuning a snort box. It's 
> almost completely pointless to try to tune snort's settings if your 
> nic is an ancient 8bit ISA card that requires CPU driven I/O 
> (non-mastering), because 99% of the cpu time will be the OS 
> spoon-feeding the NIC.
>
> On the other hand a very nice PCI busmastering NIC with flexible 
> memory alignment requirements and efficient PCI bus usage could do 
> this all with relatively little CPU involvement, mostly dominated by a 
> single memcpy and a context switch.

Absolutely, but there are two I/O issues Snort faces.  One is DMA from 
the NIC to the kernel, accomplished with a hard interrupt and a soft 
interrupt on i386 unix systems.  The other is making multiple copies of 
that packet once it's entered the kernel.  Pcap is the culprit in the 
latter case, causing at least one additional copy of a packet to be 
made.

> Of course, that's an extreme example, but it does illustrate that at 
> some level the biggest blockage might be your NIC, and in other 
> configurations it's less of an issue.

I completely agree.  Making the right choice in a network card is 
important if the drivers available for your particular operating system 
make use of advanced NIC chipset features.  Some newer chipsets attempt 
to prevent generating an abundance of interrupt requests by coalescing 
data before indicating there's data to be read from the NIC.

> Certainly, and also dependant on how your HOME_NET and EXTERNAL_NET 
> are set and what your traffic load looks like.

You're absolutely right.

> There's a lot of variables that could make those numbers vary wildly. 
> They are strictly a wild guess based on a large number of very, very 
> gross assumptions, and little knowledge of the snort code itself.

There is certainly the possibility of skewing the data by introducing 
logic that can alter the flow of data through the system.

I'm going to publish a write-up on profiling Snort in the not so 
distant future.

- -Jeff
- --
http://cerberus.sourcefire.com/~jeff       (gpg key available)
"Problems cannot be solved at the same level of awareness that
created them."   - Albert Einstein

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Darwin)

iD4DBQE/YUJ5Eqr8+Gkj0/0RAtW9AJiJKzuGJMSS0O1jeqImiGdCNa93AJ9GDcTo
KHePhA/pF/L0RLKNjbAwlA==
=glLB
-----END PGP SIGNATURE-----



-------------------------------------------------------
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