Pete Heist &lt;notifications@github.com&gt; writes:<br>
<br>
&gt;&gt; &gt; And this likely takes the mean value of all transactions and<br>
&gt;&gt; &gt; summarizes it at the end of the interval, then the calculated latency<br>
&gt;&gt; &gt; was what was plotted in flent?<br>
&gt;&gt; <br>
&gt;&gt; Yup, that&#39;s exactly it :)<br>
&gt;<br>
&gt; Ok, it’ll be interesting for me to look at the differences between the<br>
&gt; two going forward. Naturally doing it the udp_rr way would probably<br>
&gt; result in a smoother line. The other impacts on the test might be fun<br>
&gt; to explore.<br>
<br>
Well the obvious one is that the netperf measurement uses more bandwidth<br>
as the latency decreases. Have been meaning to add that to the Flent<br>
bandwidth graphs, but now I&#39;m not sure I&#39;ll even bother :P<br>
<br>
Also, the netperf measurement will stop at the first packet loss (later<br>
versions added in a timeout parameter that will restart it, but even<br>
with that we often see UDP latency graphs completely stopping after a<br>
few seconds of the RRUL test).<br>
<br>
-Toke<br>


<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">&mdash;<br />You are receiving this because you commented.<br />Reply to this email directly, <a href="https://github.com/tohojo/flent/issues/106#issuecomment-346269442">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AerUv0kcjqFa9T7Wu40jUrgf8IJnldnQks5s49HugaJpZM4MpJAm">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/AerUv6bPyTLBLVYWq_zmT6MCdCUjwkZCks5s49HugaJpZM4MpJAm.gif" width="1" /></p>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
  <link itemprop="url" href="https://github.com/tohojo/flent/issues/106#issuecomment-346269442"></link>
  <meta itemprop="name" content="View Issue"></meta>
</div>
<meta itemprop="description" content="View this Issue on GitHub"></meta>
</div>

<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/tohojo/flent","title":"tohojo/flent","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/tohojo/flent"}},"updates":{"snippets":[{"icon":"PERSON","message":"@tohojo in #106: Pete Heist \u003cnotifications@github.com\u003e writes:\n\n\u003e\u003e \u003e And this likely takes the mean value of all transactions and\n\u003e\u003e \u003e summarizes it at the end of the interval, then the calculated latency\n\u003e\u003e \u003e was what was plotted in flent?\n\u003e\u003e \n\u003e\u003e Yup, that's exactly it :)\n\u003e\n\u003e Ok, it’ll be interesting for me to look at the differences between the\n\u003e two going forward. Naturally doing it the udp_rr way would probably\n\u003e result in a smoother line. The other impacts on the test might be fun\n\u003e to explore.\n\nWell the obvious one is that the netperf measurement uses more bandwidth\nas the latency decreases. Have been meaning to add that to the Flent\nbandwidth graphs, but now I'm not sure I'll even bother :P\n\nAlso, the netperf measurement will stop at the first packet loss (later\nversions added in a timeout parameter that will restart it, but even\nwith that we often see UDP latency graphs completely stopping after a\nfew seconds of the RRUL test).\n\n-Toke\n"}],"action":{"name":"View Issue","url":"https://github.com/tohojo/flent/issues/106#issuecomment-346269442"}}}</script>