Re: pcap_next_ex() and pcap_dump() performance decreases over time...

[Guy Harris <guy () alum mit edu>]

On Aug 22, 2015, at 6:03 PM, barcaroller <barcaroller () gmail com> wrote:

> Using the Boost timer functions.  I could be wrong but I think they are based on gettimeofday().

So probably real-time.

That means that, *if* there are other processes on the machine, some of the time *could* be due to other processes 
having all the cores, but, with 8 cores, that's unlikely unless your test programs are lighting up all 8 cores.

> Minutes.  If I run my test programs for two minutes, the average rates are great.  If I run them for 15 minutes, the 
> average rates drop dramatically.
>
> I also keep track of the maximum times for individual pcap_next_ex() and pcap_dump() calls.  For the two minute test, 
> the maximum (not average) for both functions is <10 microseconds.  For the 15 minute test, the maximum (not average) 
> for both functions can be as high as 2,000,000 microseconds (2 seconds).

pcap_dump() is pretty simple - just a couple of fwrite() calls.  fwrite() is probably just copying stuff into the FILE 
*'s buffer and, eventually, write()ing it out.

I don't know whether you could use strace to see how long whatever write() calls it makes take, but, with plenty of 
free disk space and files only getting to 100MB, I don't see what would cause write() calls to take up to 2 seconds.

> Currently the test programs read and write, but not at the same time.  The first phase writes out the packets; the 
> second phase reads them in.

So, during phase 1, it captures packets and writes them out with pcap_dump(), and, during phase 2, it reads from the 
file it just wrote?

When capturing packets, are you using libpcap()?  If so, are you using pcap_next_ex() both when capturing-and-writing 
and when reading?  If so, does the slowdown in pcap_next_ex() happen in both phases?

> > > Does anyone know how to explain this?
> > Not without at least knowing on what OS you're doing this.  Those routines make system calls, so there might be a 
> > *kernel* resource involved.
>
> CentOs 6.5, 8 cores, 16GB RAM, lots of free disk space

I.e. Linux, and on a machine not starved for resources.
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers