Pete Heist <notifications@github.com> writes:<br>
<br>
> The `-n` and `-timeouts` parameters have been added to the client, and are documented in the usage. Quick examples:<br>
><br>
> ```<br>
> tron:~/src/github.com/peteheist/irtt:% ./irtt client -timeouts 250ms,500ms,1s,2s -n 127.0.0.2<br>
> [Connecting] connecting to 127.0.0.2<br>
> Error: no reply from server<br>
> tron:~/src/github.com/peteheist/irtt:% echo $?<br>
> 1<br>
> tron:~/src/github.com/peteheist/irtt:% ./irtt client -timeouts 250ms,500ms,1s,2s -n 127.0.0.1<br>
> [Connecting] connecting to 127.0.0.1<br>
> [Connected] connected to 127.0.0.1:2112<br>
> [NoTest] skipping test at user request<br>
> tron:~/src/github.com/peteheist/irtt:% echo $?                                               <br>
> 0<br>
> ```<br>
<br>
Awesome!<br>
<br>
> I don't know how aggressive you want to go on open packet timeouts,<br>
> but I set a minimum at 200ms so users won't be as tempted to abuse<br>
> public servers. Default Linux TCP syn timeout looks to be hardcoded at<br>
> 3s,6s,12s, etc. I think our default of 1s,2s,4s,8s is fine in this day<br>
> and age. In flent, I think 250ms,500ms,1s,2s would be one way of being<br>
> pretty sure whether a server is running or not in a reasonable amount<br>
> of time (3.75s), but I don't know what actual the time constraints<br>
> are.<br>
<br>
I don't want to spend more than one second probing, so 250ms,500ms will<br>
have to do.<br>
<br>
> I took a quick look at the irtt runner in flent. Looks good, my only<br>
> comment is that `-fill rand` and `-fillall` aren't necessary because<br>
> there's no payload (whose length would be specified with `-l`). Seeing<br>
> that though made me add a micro-optimization to not call Read with an<br>
> empty slice on the Filler when there's no payload requested. So if you<br>
> want to leave those params in anticipation of using `-l` later, it's<br>
> probably fine.<br>
<br>
Yeah, was mirroring what I'm doing with netperf. Haven't thought about<br>
adding knobs yet, but setting the lengths seems useful.<br>
<br>
> That makes me think, any reason we can't use irtt for the voip tests?<br>
> There could be tests simulating some different codecs with different<br>
> intervals and payload lengths, if we wanted:<br>
<br>
That would be awesome! D-ITG is awful to setup, so having a replacement<br>
for that would be good :)<br>
<br>
-Toke<br>


<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you commented.<br />Reply to this email directly, <a href="https://github.com/tohojo/flent/issues/106#issuecomment-345266203">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AerUv-7cqDZnLCltgXgVwAFUPFG9jv7Nks5s3Z76gaJpZM4MpJAm">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/AerUv-BF24gk7YPkQpoTX9Fm0UQlKIbyks5s3Z76gaJpZM4MpJAm.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-345266203"></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 The `-n` and `-timeouts` parameters have been added to the client, and are documented in the usage. Quick examples:\n\u003e\n\u003e ```\n\u003e tron:~/src/github.com/peteheist/irtt:% ./irtt client -timeouts 250ms,500ms,1s,2s -n 127.0.0.2\n\u003e [Connecting] connecting to 127.0.0.2\n\u003e Error: no reply from server\n\u003e tron:~/src/github.com/peteheist/irtt:% echo $?\n\u003e 1\n\u003e tron:~/src/github.com/peteheist/irtt:% ./irtt client -timeouts 250ms,500ms,1s,2s -n 127.0.0.1\n\u003e [Connecting] connecting to 127.0.0.1\n\u003e [Connected] connected to 127.0.0.1:2112\n\u003e [NoTest] skipping test at user request\n\u003e tron:~/src/github.com/peteheist/irtt:% echo $?                                               \n\u003e 0\n\u003e ```\n\nAwesome!\n\n\u003e I don't know how aggressive you want to go on open packet timeouts,\n\u003e but I set a minimum at 200ms so users won't be as tempted to abuse\n\u003e public servers. Default Linux TCP syn timeout looks to be hardcoded at\n\u003e 3s,6s,12s, etc. I think our default of 1s,2s,4s,8s is fine in this day\n\u003e and age. In flent, I think 250ms,500ms,1s,2s would be one way of being\n\u003e pretty sure whether a server is running or not in a reasonable amount\n\u003e of time (3.75s), but I don't know what actual the time constraints\n\u003e are.\n\nI don't want to spend more than one second probing, so 250ms,500ms will\nhave to do.\n\n\u003e I took a quick look at the irtt runner in flent. Looks good, my only\n\u003e comment is that `-fill rand` and `-fillall` aren't necessary because\n\u003e there's no payload (whose length would be specified with `-l`). Seeing\n\u003e that though made me add a micro-optimization to not call Read with an\n\u003e empty slice on the Filler when there's no payload requested. So if you\n\u003e want to leave those params in anticipation of using `-l` later, it's\n\u003e probably fine.\n\nYeah, was mirroring what I'm doing with netperf. Haven't thought about\nadding knobs yet, but setting the lengths seems useful.\n\n\u003e That makes me think, any reason we can't use irtt for the voip tests?\n\u003e There could be tests simulating some different codecs with different\n\u003e intervals and payload lengths, if we wanted:\n\nThat would be awesome! D-ITG is awful to setup, so having a replacement\nfor that would be good :)\n\n-Toke\n"}],"action":{"name":"View Issue","url":"https://github.com/tohojo/flent/issues/106#issuecomment-345266203"}}}</script>