<div dir="ltr">Sean, thanks for this. I think I had actually googled up your paper before. :) This memory calculator is very nice.<div><br></div><div>I noticed that when I squashed rss queue to 1 on a 4.12 kernel, I went from less than .05% packet loss to ~9% packet loss. Any idea why that might have occured? I have read some conflicting things about rss queues depending on kernel version, namely this bit:</div><div><br></div><div><span style="color:rgb(51,51,51);font-family:Verdana,sans-serif;font-size:12px">AF_PACKET: 1 RSS queue and stay on kernel <=4.2 or make sure you have >=4.4.16, >=4.6.5 or >=4.7. Exception: if RSS is symmetric cluster-type 'cluster_qm' can be used to bind Suricata to the RSS queues. Disable NIC offloading except the rx/tx csum.</span><br></div><div><span style="color:rgb(51,51,51);font-family:Verdana,sans-serif;font-size:12px"><br></span></div><div><span style="color:rgb(51,51,51);font-family:Verdana,sans-serif;font-size:12px">from </span><font color="#333333" face="Verdana, sans-serif"><span style="font-size:12px"><a href="https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Packet_Capture">https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Packet_Capture</a></span></font></div><div><font color="#333333" face="Verdana, sans-serif"><span style="font-size:12px"><br></span></font></div><div><font color="#333333" face="Verdana, sans-serif"><span style="font-size:12px">Thank you for all the help tuning out memory issues suri. My goal is to try and get packet loss below .01%. Heres for trying!</span></font></div><div><font color="#333333" face="Verdana, sans-serif"><span style="font-size:12px"><br></span></font></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 14, 2017 at 9:23 AM, Cloherty, Sean E <span dir="ltr"><<a href="mailto:scloherty@mitre.org" target="_blank">scloherty@mitre.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="m_-2993377868821851190WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">I’ve post this earlier and hope that this can be useful.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><u></u> <u></u></span></p>
<p class="m_-2993377868821851190MsoPlainText">If you are using AF-PACKET (and why wouldn't you), the attached spreadsheet may help.  It is derived from Peter Manev's highly detailed review of various configuration options and their affect on memory utilization. 
<a href="http://pevma.blogspot.com/2015/10/suricata-with-afpacket-memory-of-it-all.html" target="_blank">
http://pevma.blogspot.com/<wbr>2015/10/suricata-with-<wbr>afpacket-memory-of-it-all.html</a><u></u><u></u></p>
<p class="m_-2993377868821851190MsoPlainText"><u></u> <u></u></p>
<p class="m_-2993377868821851190MsoPlainText">I began creating this during a Suricata training class so I could save time when testing different configurations.  Peter has reviewed it for accuracy and correct nomenclature.  I hope that it will be of some use to the community.<u></u><u></u></p>
<p class="m_-2993377868821851190MsoPlainText"><u></u> <u></u></p>
<p class="m_-2993377868821851190MsoPlainText">Sean Cloherty <u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Oisf-users [mailto:<a href="mailto:oisf-users-bounces@lists.openinfosecfoundation.org" target="_blank">oisf-users-bounces@<wbr>lists.openinfosecfoundation.<wbr>org</a>]
<b>On Behalf Of </b>erik clark<br>
<b>Sent:</b> Thursday, July 13, 2017 07:58 AM<br>
<b>To:</b> Open Information Security Foundation <<a href="mailto:oisf-users@lists.openinfosecfoundation.org" target="_blank">oisf-users@lists.<wbr>openinfosecfoundation.org</a>><br>
<b>Subject:</b> Re: [Oisf-users] SEPTun and memory usage<u></u><u></u></span></p><span class="">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">All, trying to find out who has worked with the SEPTun document that can provide some insight into how much memory they are using to sniff traffic.<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">We (were) using 8 threads with 200 gigs of ram on a 2.5 Gb/s link. Until earlier this week, our drop rate was ~2%. I just moved up to 16 threads, still at 200 gigs of ram, since our throughput moved up a bit to ~3.1Gb/s and saw a 12% drop
 rate.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">We have 72 cores to work with, and 200 gigs of ram, and just moved to a 4.4 kernel from a modified 3.10 kernel. What seems reasonable on this kind of hardware? We are limited to an 82598 ixgbe interface with a single link.<u></u><u></u></p>
</div>
</div>
</span></div>
</div>

</blockquote></div><br></div>