> > > 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, [EMAIL PROTECTED] - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
