Pete Heist &lt;notifications@github.com&gt; writes:<br>
<br>
&gt; Cool, the rrul_be_irtt test is working for me. I see what you mean,<br>
&gt; ideally it would just be the same test but you substitute the tool you<br>
&gt; want to use for a particular measurement.<br>
&gt;<br>
&gt; Maybe this is what you&#39;re saying, but could it be that you specify<br>
&gt; what tool you want to use for each particular measurement? In other<br>
&gt; words, the tool for &#39;TCP throughput&#39; is netperf as of now, and later<br>
&gt; could possibly be iperf. For &#39;UDP RTT&#39; it can be netperf or irtt. For<br>
&gt; &#39;ICMP RTT&#39; it can be ping or fping, etc.<br>
<br>
Yeah, something like that. For ping we already do this (default to fping<br>
and fall back to regular ping), but those are closer in functionality.<br>
But the idea is the same; the test should not specify &quot;use netperf&quot; but<br>
rather &quot;this is a UDP RR test&quot;. Then we pick irtt if it&#39;s available and<br>
use netperf as a fallback. Optionally with a command line switch to<br>
force fallback (probably a good idea at least until we get wider<br>
deployment of irtt).<br>
<br>
&gt; I&#39;m waving my arms here because there can be more than one measurement<br>
&gt; from a single tool. So maybe it should really be &#39;UDP RT&#39; because in<br>
&gt; the case of irtt it&#39;s doing a UDP round-trip and measuring several<br>
&gt; things from it at once: RTT, OWD, IPDV, etc. Since there isn&#39;t a<br>
&gt; one-to-one correspondence between the tool and measurement it returns,<br>
&gt; it&#39;s not clear to me yet how it should be specified, still thinking<br>
&gt; about it.<br>
&gt;<br>
&gt; I guess at some point there will be additional plots for OWD and IPDV.<br>
&gt; Is it a new situation for you that the plots available depend not only<br>
&gt; on the test but the tool used or even its settings?<br>
<br>
Meh, irtt&#39;s functionality is basically a superset of netperf&#39;s UDP_RR.<br>
So automatically picking irtt if available and a fallback is the right<br>
thing to do, I think. I&#39;d just add the plots everywhere, and if OWD data<br>
is not available, those plots would just be empty. Same thing we do for<br>
TCP window stats currently. Longer term, maybe hiding the plots entirely<br>
when there is no data is better, but for now empty plots are fine.<br>
<br>
&gt; Personally I don&#39;t think it&#39;s necessary to check for server-side<br>
&gt; support. If someone is specifying they want to use a particular tool,<br>
&gt; I think they&#39;re declaring that it&#39;s available, as it is today with<br>
&gt; netperf / netserver.<br>
<br>
Yes, but if we do automatic detection with a preference we could get<br>
into the situation where irtt exists on the client but the test is being<br>
run against a server that doesn&#39;t have it. This is especially likely to<br>
happen before the *.netperf.bufferbloat.net servers have irtt deployed.<br>
<br>
Could you be persuaded to add a &#39;check_server&#39; action to irtt? Something<br>
that just does the handshake and doesn&#39;t run any more tests other than<br>
that. Then we could have Flent call that to verify that irtt is<br>
usable...<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-344905911">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AerUv-pX5CVEH9mhRqXt47Y0O3E7rOgGks5s3CdxgaJpZM4MpJAm">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/AerUv4W4JMaBVurs5P9zOC7S4g7TshzPks5s3CdxgaJpZM4MpJAm.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-344905911"></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 Cool, the rrul_be_irtt test is working for me. I see what you mean,\n\u003e ideally it would just be the same test but you substitute the tool you\n\u003e want to use for a particular measurement.\n\u003e\n\u003e Maybe this is what you're saying, but could it be that you specify\n\u003e what tool you want to use for each particular measurement? In other\n\u003e words, the tool for 'TCP throughput' is netperf as of now, and later\n\u003e could possibly be iperf. For 'UDP RTT' it can be netperf or irtt. For\n\u003e 'ICMP RTT' it can be ping or fping, etc.\n\nYeah, something like that. For ping we already do this (default to fping\nand fall back to regular ping), but those are closer in functionality.\nBut the idea is the same; the test should not specify \"use netperf\" but\nrather \"this is a UDP RR test\". Then we pick irtt if it's available and\nuse netperf as a fallback. Optionally with a command line switch to\nforce fallback (probably a good idea at least until we get wider\ndeployment of irtt).\n\n\u003e I'm waving my arms here because there can be more than one measurement\n\u003e from a single tool. So maybe it should really be 'UDP RT' because in\n\u003e the case of irtt it's doing a UDP round-trip and measuring several\n\u003e things from it at once: RTT, OWD, IPDV, etc. Since there isn't a\n\u003e one-to-one correspondence between the tool and measurement it returns,\n\u003e it's not clear to me yet how it should be specified, still thinking\n\u003e about it.\n\u003e\n\u003e I guess at some point there will be additional plots for OWD and IPDV.\n\u003e Is it a new situation for you that the plots available depend not only\n\u003e on the test but the tool used or even its settings?\n\nMeh, irtt's functionality is basically a superset of netperf's UDP_RR.\nSo automatically picking irtt if available and a fallback is the right\nthing to do, I think. I'd just add the plots everywhere, and if OWD data\nis not available, those plots would just be empty. Same thing we do for\nTCP window stats currently. Longer term, maybe hiding the plots entirely\nwhen there is no data is better, but for now empty plots are fine.\n\n\u003e Personally I don't think it's necessary to check for server-side\n\u003e support. If someone is specifying they want to use a particular tool,\n\u003e I think they're declaring that it's available, as it is today with\n\u003e netperf / netserver.\n\nYes, but if we do automatic detection with a preference we could get\ninto the situation where irtt exists on the client but the test is being\nrun against a server that doesn't have it. This is especially likely to\nhappen before the *.netperf.bufferbloat.net servers have irtt deployed.\n\nCould you be persuaded to add a 'check_server' action to irtt? Something\nthat just does the handshake and doesn't run any more tests other than\nthat. Then we could have Flent call that to verify that irtt is\nusable...\n\n-Toke\n"}],"action":{"name":"View Issue","url":"https://github.com/tohojo/flent/issues/106#issuecomment-344905911"}}}</script>