On Aug 22, 2015, at 6:03 PM, barcaroller <barcarol...@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
