Re: PCAP performance

[sthaug () nethelp no]

> > > Now I have noticed that about every 3 minutes and 15 seconds the Program
> > > uses 100 % of the CPU.
> > > After about 45 sec the program works normal again and uses only 10% of
> > the
> > > CPU time.
> > > The program is running on a 300 MHz Celeron with 128 MB RAM under
> > Slackware
> > > 8.1. 
> >
> > If you're running it from a terminal window, try typing the quit
> > character at it (control-backslash, unless you or the Slackware folks or
> > Linux distributions in general change it from the traditional UN*X
> > default) when it's running at 100%; that should cause it to dump core. 
> > Then use gdb to see what the program was doing at that time.
> I have tried it, but it didn`t help me very much. The program was in a
> normal state in which it processed a packet.
> I realized now that just before my program uses all CPU time the system
> starts to use the CPU more.
> The System uses about 30 % of the CPU and then my program starts to burn CPU
> power. 
> I think there is something happening in the kernel... ?

Yes, I think you definitely  need to look at your kernel. I tried an
experiment somewhat similar to yours:

- 366 MHz Celeron, FreeBSD 4.9-STABLE, 384 MByte memory. tcpdump 3.7.2
and libpcap 0.7, which is what comes with FreeBSD 4.9-STABLE.
- Long filter, 200 (src addr, dst port) pairs which would all have to
be evaluated for every packet.
- Sending full sized (1500 byte) packets with hping2, 100 pps.
- Receiving the full 1500 bytes and writing them to file with tcpdump:

tcpdump -nps 1500 -w tcpdump.hping -F /tmp/filter

- Logging the processor utilization with vmstat (vmstat 5).

On this system, which performance-wise is similar to yours, this tcpdump
session used between 1 and 2 percent CPU time, according to vmstat. The
difference between a short filter (1 src addr, dst port pair) and a long
filter was not noticeable. No hint of any problems after a specific time.
I had the hping2 session running for 10 minutes (60.000 packets) and it
all ran smoothly the whole time.

Note that I had to recompile the kernel and change BPF_MAXINSNS to 2048
in order to use such a large (200 pairs) filter.

My conclusion is that neither libpcap nor tcpdump by themselves are
responsible for the high CPU time you are seeing.

Steinar Haug, Nethelp consulting, sthaug () nethelp no
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.