<div dir="ltr"><div><div><div><div><div>RE Queue disciplines: maybe this -&gt; &quot;The Ultimate Traffic Conditioner: Low Latency, Fast Up &amp; Downloads&quot; <a href="http://lartc.org/howto/lartc.cookbook.ultimate-tc.html">http://lartc.org/howto/lartc.cookbook.ultimate-tc.html</a><br><br>Jumping in a bit late here on the traffic analysis, but if you&#39;re router can generate netflow (ddwrt can, many others should) you can feed it to the netflow collector on cacti for a graphical view.<br><br></div>Scrutinizer is my go-to tool for analysing netflow graphically. You can get a free eval vm at <a href="https://www.plixer.com/Scrutinizer-Netflow-Sflow/scrutinizer-download.html">https://www.plixer.com/Scrutinizer-Netflow-Sflow/scrutinizer-download.html</a> that&#39;s more than capable for a small network.<br><br></div>The more light-weight and quick method for flow analysis is argus: <a href="http://qosient.com/argus/">http://qosient.com/argus/</a> It&#39;s an opensource flow analysis tool that has origins at CERN. You&#39;ll have to compile from source, then there are three tools that will be most useful: argus (collects flow data based on netflow or libpcap) ratop (for watching live data) ra (for reading argus records from a file). <br><br></div>Basically, depending on whether your router is sending you netflow, or collecting at a tap, you set different flags on argus to write these flow records to a file. The flow records consist of your Src/Dst IP, Src/Dst Port, Tcp Flags, Timing, Packet and Bit count, etc. Then these files can be summarized by &#39;ra&#39; to yield what you&#39;re looking for. Examples are here: <a href="http://qosient.com/argus/gettingstarted.shtml">http://qosient.com/argus/gettingstarted.shtml</a> and <a href="http://qosient.com/argus/howto.shtml">http://qosient.com/argus/howto.shtml</a><br><br></div>Let me know if you have questions with Argus. It can be a bit tricky on initial setup.<br></div>-George<br><div><div><br><br><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 12, 2015 at 9:19 PM, Michael Trausch <span dir="ltr">&lt;<a href="mailto:mike@trausch.us" target="_blank">mike@trausch.us</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I will try to find the link later, but the same doc explains the use of the tool to nix an uplink buffer to avoid the choked TCP download situation on very async pipes, also shows how to bump packets to the front of the line, have variable speed limits and so forth. Queue disciplines are to Ethernet what a line discipline is to a serial port channel driver.<br>
<br>
<br>
<br>
Sent from my iPhone<br>
<div class="HOEnZb"><div class="h5"><br>
&gt; On Aug 12, 2015, at 9:14 PM, Michael Trausch &lt;<a href="mailto:mike@trausch.us">mike@trausch.us</a>&gt; wrote:<br>
&gt;<br>
&gt; You&#39;ll want to read the huge TLDP doc on the subject. The tool you want is &#39;tc&#39;, unless you want to go one level lower and speak netlink with the kernel.<br>
&gt;<br>
&gt; Sent from my iPhone<br>
&gt;<br>
&gt;&gt; On Aug 12, 2015, at 3:44 PM, Jim Kinney &lt;<a href="mailto:jim.kinney@gmail.com">jim.kinney@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; You can set QoS rules somewhere. I&#39;ve never done that but have a hard need (teen and networked games WHILE watching netflix AND group skype call).<br>
<br>
_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" rel="noreferrer" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" rel="noreferrer" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
</div></div></blockquote></div><br></div>