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