[tcpdump-workers] BPF questions...
This may not be the right group, but I have a few BPF questions that I hope you can answer: * What is the maximum size of a BPF expression that can be passed to tcpdump and pcap_compile()? Some of the BPF expressions I've observed are over 1024 characters and I wonder what the limt is (if any)? * What is the maximum level of nesting for BPF expressions for tcpdump and pcap_compile()? Currently, I'm observing nesting levels of 10 or more. * Are there BPF expressions for "nested" vlans? Thanks much. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] BPF for non-nested vlans...
BPF for non-nested vlans... BPF for non-nested vlans... BPF for non-nested vlans... User-Agent: Unison/2.1.5 What is the correct BPF for packets that have a vlan tag of either 100 or 200? A BPF like "vlan 100 or vlan 200" would not work (as the manpage clearly explains). Thanks much. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] pcap_next_ex() and pcap_dump() performance decreases over time...
I've been running performance tests against pcap_next_ex() and pcap_dump(). I've placed micro-second timers around both functions and sent millions of packets to my test programs. Both functions performed admirably over a short period of time (up to 8 Gbits/sec) but, as time progressed, both functions became increasingly slower until the data rate dropped to 200 Mbits/sec. Please note that the two functions become slower even when I read/wrote new pcap files (i.e. I would close a pcap file and start reading/writing a new PCAP file, but the performance still remained low). At no time did the size of these pcap files exceed 100MB. Only when I re-started the test programs did the performance go up again. It's as if there is a process-wide global resource, independent of the pcap files, that gets used up by pcap_next_ex() and pcap_dump() as the process is running. Does anyone know how to explain this? ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] pcap_next_ex() and pcap_dump() performance decreases over time...
On 2015-08-22 23:21:55 +, Guy Harris said: I've been running performance tests against pcap_next_ex() and pcap_dump(). I've placed micro-second timers around both functions So those are presumably real-time timers rather than CPU timers. Using the Boost timer functions. I could be wrong but I think they are based on gettimeofday(). and sent millions of packets to my test programs. Both functions performed admirably over a short period of time (up to 8 Gbits/sec) but, as time progressed, both functions became increasingly slower until the data rate dropped to 200 Mbits/sec. How short is "short"? Tens of seconds? Minutes? 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). Please note that the two functions become slower even when I read/wrote new pcap files (i.e. I would close a pcap file and start reading/writing a new PCAP file, but the performance still remained low). What happens if you have a test program that doesn't write the packets out? 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. 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 ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] pcap_next_ex() and pcap_dump() performance decreases over time...
On 2015-08-23 01:42:30 +, Guy Harris said: 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. That's correct; my test programs are the only programs running. 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. It has puzzled me too. Keep in mind that I am making millions of these pcap calls; only one of them could be taking 2 seconds. 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? I actually read the packets from a pcap file (not part of the test), store the packets in memory (e.g. 50,000 packets), then write them in a loop to disk (e.g. 50,000 x 1,000) using multiple pcap files (none greater than 100MB); this is phase 1. I then read all packets (e.g. 50,000 x 1,000) in chunks and destroy each chunk before reading the next; this is phase 2. I.e. Linux, and on a machine not starved for resources. Right. But something in the process is making pcap_next_ex() and pcap_dump() slower with time. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] pcap_next_ex() and pcap_dump() performance decreases over time...
On 2015-08-23 03:13:50 +, Guy Harris said: It has puzzled me too. Keep in mind that I am making millions of these pcap calls; only one of them could be taking 2 seconds. Then the average might be more interesting than the maximum. Yes, but the average was only about 20 times higher, which corresponds to the data rate dropping from 8GBits/sec to 200 MBits/sec. I actually read the packets from a pcap file (not part of the test), store the packets in memory (e.g. 50,000 packets), then write them in a loop to disk (e.g. 50,000 x 1,000) using multiple pcap files (none greater than 100MB); this is phase 1. So does "50,000 x 1,000" mean that it writes out each packet 1,000 times? Yes, but to different pcap files. At any given time, I have only one pcap file open for writing. So the reading of the file in phase 1 isn't being tested, so the pcap_next_ex() calls being performance-tested are in phase 2? That's correct. I then read all packets (e.g. 50,000 x 1,000) in chunks and destroy each chunk before reading the next; this is phase 2. "In chunks" meaning that you have a loop that reads a chunk worth of packets, with each packet read with pcap_next_ex(), and then free all the packets in the chunk before reading the next chunk? That's correct. Right. But something in the process is making pcap_next_ex() and pcap_dump() slower with time. Something *somewhere* is. Are there any numbers that you think would be useful in analyzing this problem? ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] pcap_next_ex() and pcap_dump() performance decreases over time...
On 2015-08-23 09:39:19 +, Ander Juaristi said: Have you completely discarded algorithmical issues? This looks like something is being constantly doubled. Probably in logarithmic time. The timers are wrapped around the pcap functions: timer before_dump; pcap_dump(); timer after_dump; duration_dump = after_dump - before_dump; timer before_next; pcap_next_ex(); timer after_next; duration_next = after_next - before_next; // Now calculate total, average, maximum, and minimum durations No matter what the rest of the code does, I would expect the durations above to be relatively constant. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
