<br><br><div class="gmail_quote">On Fri, Aug 26, 2011 at 1:54 AM, Victor Julien <span dir="ltr"><<a href="mailto:victor@inliniac.net">victor@inliniac.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 08/25/2011 08:18 PM, Gene Albin wrote:<br>
> Victor,<br>
>   Thanks for the explanation.  So do I understand correctly that for reading<br>
> pcap files I'm limited to only a single packet reader thread?  So at some<br>
> point my performance bottleneck would become the packet reading thread,<br>
> regardless of where the pcap file is stored?  If that's the case I could<br>
> probably use tcpreplay to resend the traffic through the interface and<br>
> pfring (thought I haven't begun to work with pfring yet).<br>
<br>
</div>Correct. I don't think there is a sane way to have more pcap file<br>
readers. Replaying seems to be your best option.<br>
<font color="#888888"><br></font></blockquote><div><br></div><div>I'm going to crawl out on a limb here.... Feel free to join me 8-).</div><div><br></div><div>I'll venture that reading a pcap is, for all practical purposes, limited by the I/O to the pcap file. If you're reading the pcap from memory (either from the cache or a RAM disk), you can probably read it at 1+gigabytes/sec, assuming a modern machine with modern memory.</div>
<div><br></div><div>FWIW, the following is from a fairly elderly 8 cpu 3GHz Core2 machine, with a 12 disk RAID6 array on a 4 port, 3Gbit/sec SAS backplane and modern LSI PCiE controller:</div><div><br></div><div><div>space2:/y/pcaps # time dd if=tcpdump-2007-02-16-08-02 of=/dev/null bs=256k</div>
<div>2861036+1 records in</div><div>2861036+1 records out</div><div>750003609600 bytes (750 GB) copied, 994.034 s, 755 MB/s</div><div><br></div><div>real    16m34.051s</div><div>user    0m0.720s</div><div>sys     8m12.135s</div>
<div>space2:/y/pcaps # time tcpdump -nnr tcpdump-2007-02-16-08-02 -s0 -w /dev/null</div><div>reading from file tcpdump-2007-02-16-08-02, link-type EN10MB (Ethernet)</div><div>tcpdump: pcap_loop: truncated dump file; tried to read 106 captured bytes, only got 93</div>
<div><br></div><div>real    19m34.546s</div><div>user    5m46.591s</div><div>sys     9m31.326s</div><div>space2:/y/pcaps # ll tcpdump-2007-02-16-08-02</div><div>-rw-r--r-- 1 root root 750003609600 Mar 26  2007 tcpdump-2007-02-16-08-02</div>
</div><div><br></div><div> So, this system can read a pcap from disk and write it (pcap formatted) to /dev/null (tcpdump is single threaded) at</div></div><div>638MBytes/sec. Which is about 5Gbits/sec.</div><div><br></div>
<div>Chances are pretty good that a RAM drive would do better, but I don't have enough memory to do that with this pcap (yet).</div><div><br></div><div>I haven't seen either snort or suricata process this pcap at anything approaching this rate on this machine yet (using an actual fairly modern rule set, I mean).</div>
<div><br></div><div>If Gene is still reading from a RAM drive, I wouldn't think that he's "limited to only a single packet reader thread", pcap-read-performance-wise, unless his pcap library was compiled without optimization.</div>
<div><br></div><div>YMMV...</div><div>(And welcome back from vacation, Victor!)</div><div><br></div><div>Dave</div><div><br></div>-- <br>"Of course, someone who knows more about this will correct me if I'm<br>wron g, and someone who knows less will correct me if I'm right." <br>
David Palmer (<a href="mailto:palmer@tybalt.caltech.edu">palmer@tybalt.caltech.edu</a>)<br><br>